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 >
