jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Reintroducing the great split
Date Wed, 25 Oct 2006 19:20:28 GMT

Last year we tried reorganizing the Jackrabbit core into separate
"core", "api", and "commons" compontents (see JCR-157), but that
change was finally reverted due to problems with the Maven-generated
web site. Since then we've moved the entire core project down one
level (JCR-227), upgraded a number of subprojects from contrib, and
simplified the Maven-generated site by removing the source reports.
The "api" and "commons" components are now constructed using Maven
tricks within the modules subdirectory. The jcr-server subproject also
contains four sub-subprojects. Thus, the project structure and build
environment has evolved quite a lot since last year.

As a part of the Maven 2 upgrade (JCR-332), I'd now like to
reintroduce the idea of splitting the core project as a part of a more
general component-level restructuring of Jackrabbit. The restructuring
would consist of the following changes:

1. Create a Jackrabbit "super-project" (artifactId: jackrabbit) in trunk/
2. Use the super-project POM as the parent of all Jackrabbit component POMs
3. Move the contents of trunk/jackrabbit/src/site directly to
trunk/src/site, and use the super-project to generate the web site
4. Create independent subprojects for the the jackrabbit-api and
jackrabbit-commons components, moving the the corresponding parts of
the source tree
5. Move the jcr-server subprojects on level up
6. Rename the subproject directories to match their artifactIds

Main benefits of this change would be:

* Shared parent POM for the component projects
* Uniform project structure
* Simplified build environment
* Better granularity

The main drawback I can think of is that checking out just a single
component like jackrabbit-core wouldn't necessarily give you all the
sources needed to build a component. This could be solved either by
using a daily snapshot repository, by documenting which components you
need to checkout and build, by restricting inter-component
dependencies to released versions, or by grouping related components
using an extra subdirectory like the current jcr-server.



Jukka Zitting

View raw message