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 >
