You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Scott Wilson <sc...@gmail.com> on 2011/05/25 14:50:19 UTC
[PROPOSAL] Move JCR implementation out of Wookie "core"
Hi everyone,
I propose moving the JCR implementation out of the core server and into a separate module that isn't built by default, but which can be included by adding the module to Ivy.xml and configuring as usual using build.properties.
The justification being:
- most implementations use the JPA persistence manager
- the JCR implementation brings in a lot of extra dependencies
- the JCR implementation isn't as well tested as the JPA implementation
In practice what I am proposing is:
- remove the org.apache.wookie.beans.jcr package from /src
- create a new modules/jcr subproject with its own ivy.xml and build.xml and LICENSE files
- remove JCR dependencies from /ivy.xml
- add a "Module loader" for getting JPA and JCR implementations dynamically for Start.java.
- create documentation page for using Wookie with JCR
One issue in doing this is that there is a two-way dependency:
- JCR relies on the core org.apache.wookie.beans classes in its classpath
- to build and deploy Wookie with the JCR module in Ivy.xml means the JCR module has to be already built and published
I'm not sure how to resolve this one, other than needing to build and publish JCR first, then add the dependency to Wookie, then build Wookie. Any other suggestions?
S
Re: [PROPOSAL] Move JCR implementation out of Wookie "core"
Posted by Kris Popat <kj...@gmail.com>.
On 25 May 2011, at 13:50, Scott Wilson wrote:
> Hi everyone,
>
> I propose moving the JCR implementation out of the core server and into a separate module that isn't built by default, but which can be included by adding the module to Ivy.xml and configuring as usual using build.properties.
+1
>
> The justification being:
>
> - most implementations use the JPA persistence manager
> - the JCR implementation brings in a lot of extra dependencies
> - the JCR implementation isn't as well tested as the JPA implementation
>
> In practice what I am proposing is:
>
> - remove the org.apache.wookie.beans.jcr package from /src
> - create a new modules/jcr subproject with its own ivy.xml and build.xml and LICENSE files
> - remove JCR dependencies from /ivy.xml
> - add a "Module loader" for getting JPA and JCR implementations dynamically for Start.java.
> - create documentation page for using Wookie with JCR
>
> One issue in doing this is that there is a two-way dependency:
>
> - JCR relies on the core org.apache.wookie.beans classes in its classpath
> - to build and deploy Wookie with the JCR module in Ivy.xml means the JCR module has to be already built and published
>
> I'm not sure how to resolve this one, other than needing to build and publish JCR first, then add the dependency to Wookie, then build Wookie. Any other suggestions?
>
> S
Re: [PROPOSAL] Move JCR implementation out of Wookie "core"
Posted by Scott Wilson <sc...@gmail.com>.
On 25 May 2011, at 15:35, Ate Douma wrote:
> On 05/25/2011 02:50 PM, Scott Wilson wrote:
>> Hi everyone,
>>
>> I propose moving the JCR implementation out of the core server and into a separate module that isn't built by default, but which can be included by adding the module to Ivy.xml and configuring as usual using build.properties.
>>
> +1
>
>> The justification being:
>>
>> - most implementations use the JPA persistence manager
>> - the JCR implementation brings in a lot of extra dependencies
>> - the JCR implementation isn't as well tested as the JPA implementation
> +1
>
>>
>> In practice what I am proposing is:
>>
>> - remove the org.apache.wookie.beans.jcr package from /src
>> - create a new modules/jcr subproject with its own ivy.xml and build.xml and LICENSE files
>> - remove JCR dependencies from /ivy.xml
>> - add a "Module loader" for getting JPA and JCR implementations dynamically for Start.java.
>> - create documentation page for using Wookie with JCR
>>
>> One issue in doing this is that there is a two-way dependency:
>>
>> - JCR relies on the core org.apache.wookie.beans classes in its classpath
>> - to build and deploy Wookie with the JCR module in Ivy.xml means the JCR module has to be already built and published
>>
>> I'm not sure how to resolve this one, other than needing to build and publish JCR first, then add the dependency to Wookie, then build Wookie. Any other suggestions?
>
> I just checked the jcr implementation again under o.a.w.beans.jcr and AFAIK there is only (Wookie) dependencies on the o.a.w.beans.* and oa.w.beans.util.* interfaces (and 1 exception class). Good job :)
>
> Seems pretty easy to solve then IMO by also moving these o.a.w.beans.* and o.a.w.util.* in their own separate module (Wookie Persistence API).
> That way the jcr module only needs a (build time) dependency on the Persistence API module and the two-way dependency issue should be resolved.
Good idea - thanks Ate.
>
> Regards, Ate
>
>>
>> S
>
Re: [PROPOSAL] Move JCR implementation out of Wookie "core"
Posted by Ate Douma <at...@douma.nu>.
On 05/25/2011 02:50 PM, Scott Wilson wrote:
> Hi everyone,
>
> I propose moving the JCR implementation out of the core server and into a separate module that isn't built by default, but which can be included by adding the module to Ivy.xml and configuring as usual using build.properties.
>
+1
> The justification being:
>
> - most implementations use the JPA persistence manager
> - the JCR implementation brings in a lot of extra dependencies
> - the JCR implementation isn't as well tested as the JPA implementation
+1
>
> In practice what I am proposing is:
>
> - remove the org.apache.wookie.beans.jcr package from /src
> - create a new modules/jcr subproject with its own ivy.xml and build.xml and LICENSE files
> - remove JCR dependencies from /ivy.xml
> - add a "Module loader" for getting JPA and JCR implementations dynamically for Start.java.
> - create documentation page for using Wookie with JCR
>
> One issue in doing this is that there is a two-way dependency:
>
> - JCR relies on the core org.apache.wookie.beans classes in its classpath
> - to build and deploy Wookie with the JCR module in Ivy.xml means the JCR module has to be already built and published
>
> I'm not sure how to resolve this one, other than needing to build and publish JCR first, then add the dependency to Wookie, then build Wookie. Any other suggestions?
I just checked the jcr implementation again under o.a.w.beans.jcr and AFAIK
there is only (Wookie) dependencies on the o.a.w.beans.* and oa.w.beans.util.*
interfaces (and 1 exception class). Good job :)
Seems pretty easy to solve then IMO by also moving these o.a.w.beans.* and
o.a.w.util.* in their own separate module (Wookie Persistence API).
That way the jcr module only needs a (build time) dependency on the Persistence
API module and the two-way dependency issue should be resolved.
Regards, Ate
>
> S
Re: [PROPOSAL] Move JCR implementation out of Wookie "core"
Posted by Scott Wilson <sc...@gmail.com>.
Thanks everyone.
I'll make the change in two stages - first I'll separate the JCR module. I've already made the changes locally so will push these to svn now.
In the second stage I'll implement Ate's suggestion of using a common persistence module to make a better integrated build process.
S
On 25 May 2011, at 16:08, Ross Gardler wrote:
> On 25/05/2011 13:50, Scott Wilson wrote:
>> Hi everyone,
>>
>> I propose moving the JCR implementation out of the core server and
>> into a separate module that isn't built by default, but which can be
>> included by adding the module to Ivy.xml and configuring as usual
>> using build.properties.
>
> +1
>
> Ross
>
>>
>> The justification being:
>>
>> - most implementations use the JPA persistence manager - the JCR
>> implementation brings in a lot of extra dependencies - the JCR
>> implementation isn't as well tested as the JPA implementation
>>
>> In practice what I am proposing is:
>>
>> - remove the org.apache.wookie.beans.jcr package from /src - create a
>> new modules/jcr subproject with its own ivy.xml and build.xml and
>> LICENSE files - remove JCR dependencies from /ivy.xml - add a "Module
>> loader" for getting JPA and JCR implementations dynamically for
>> Start.java. - create documentation page for using Wookie with JCR
>>
>> One issue in doing this is that there is a two-way dependency:
>>
>> - JCR relies on the core org.apache.wookie.beans classes in its
>> classpath - to build and deploy Wookie with the JCR module in Ivy.xml
>> means the JCR module has to be already built and published
>>
>> I'm not sure how to resolve this one, other than needing to build and
>> publish JCR first, then add the dependency to Wookie, then build
>> Wookie. Any other suggestions?
>>
>> S
>
Re: [PROPOSAL] Move JCR implementation out of Wookie "core"
Posted by Ross Gardler <rg...@apache.org>.
On 25/05/2011 13:50, Scott Wilson wrote:
> Hi everyone,
>
> I propose moving the JCR implementation out of the core server and
> into a separate module that isn't built by default, but which can be
> included by adding the module to Ivy.xml and configuring as usual
> using build.properties.
+1
Ross
>
> The justification being:
>
> - most implementations use the JPA persistence manager - the JCR
> implementation brings in a lot of extra dependencies - the JCR
> implementation isn't as well tested as the JPA implementation
>
> In practice what I am proposing is:
>
> - remove the org.apache.wookie.beans.jcr package from /src - create a
> new modules/jcr subproject with its own ivy.xml and build.xml and
> LICENSE files - remove JCR dependencies from /ivy.xml - add a "Module
> loader" for getting JPA and JCR implementations dynamically for
> Start.java. - create documentation page for using Wookie with JCR
>
> One issue in doing this is that there is a two-way dependency:
>
> - JCR relies on the core org.apache.wookie.beans classes in its
> classpath - to build and deploy Wookie with the JCR module in Ivy.xml
> means the JCR module has to be already built and published
>
> I'm not sure how to resolve this one, other than needing to build and
> publish JCR first, then add the dependency to Wookie, then build
> Wookie. Any other suggestions?
>
> S
Re: [PROPOSAL] Move JCR implementation out of Wookie "core"
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 25/05/2011 13:50, Scott Wilson wrote:
> Hi everyone,
>
> I propose moving the JCR implementation out of the core server and into a separate module that isn't built by default, but which can be included by adding the module to Ivy.xml and configuring as usual using build.properties.
>
> The justification being:
>
> - most implementations use the JPA persistence manager
> - the JCR implementation brings in a lot of extra dependencies
> - the JCR implementation isn't as well tested as the JPA implementation
>
> In practice what I am proposing is:
>
> - remove the org.apache.wookie.beans.jcr package from /src
> - create a new modules/jcr subproject with its own ivy.xml and build.xml and LICENSE files
> - remove JCR dependencies from /ivy.xml
> - add a "Module loader" for getting JPA and JCR implementations dynamically for Start.java.
> - create documentation page for using Wookie with JCR
>
+1
> One issue in doing this is that there is a two-way dependency:
>
> - JCR relies on the core org.apache.wookie.beans classes in its classpath
> - to build and deploy Wookie with the JCR module in Ivy.xml means the JCR module has to be already built and published
>
> I'm not sure how to resolve this one, other than needing to build and publish JCR first, then add the dependency to Wookie, then build Wookie. Any other suggestions?
>
I guess this is not a big problem if it is documented somewhere.
> S