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
