Hi, On Wed, Dec 3, 2008 at 9:13 AM, Angela Schreiber <[EMAIL PROTECTED]> wrote: >> Note that the webdav component is a bit special in that it actually >> doesn't have much to do with JCR, so eventually it might be useful to >> find a good home for it for example in Apache HttpComponents. > > that has been discussed in the past and honestly i don't > want to start that discussion again.
OK, that's fine. > regarding jcr-server: > i think we should address JCR-417 first instead of > putting the complete jcr-server to a commons project, > since i have the feeling the server part of the jcr-remoting > doesn't really belong to the commons. We could keep jcr-server with the core for now and decide later if or when it should be moved to the commons. > apart i don't have any strong feelings regarding the > commons stuff unless i can run a single mvn call to > built and test all of jackrabbit-core and the various spi > projects with the latest version of jackrabbit commons > and without having to touch the pom. That should still be possible, though with one caveat: the latest version of jcr-commons in the build would now be the latest _released_ version. Similarly, in jcr-server the latest version of the webdav component would be the latest webdav release. Is this a problem? If yes, then we could keep such upstream dependencies with the core for now, only moving those components that aren't really related to changes in core components. That would leave us with: * jackrabbit-jcr-tests * jackrabbit-jcr-benchmark * jackrabbit-jcr-rmi * jackrabbit-jcr-servlet * jackrabbit-classloader * jackrabbit-ocm * jackrabbit-ocm-nodemanagement BR, Jukka Zitting
