jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting ...@yukatan.fi>
Subject Re: build problems
Date Sun, 10 Jul 2005 08:00:23 GMT
Hi,

Some more ideas after thinking about the build issues a bit more.

Directory layout
----------------

Roy is right in that the directory layout could do with some cleaning 
up. A proposal:

jackrabbit/
          ./api
          ./commons
          ./core
          ./applications
          ./xdocs
          ./subprojects
                  ./jcr-rmi
                  ./jcr-server
                  ./orm-persistence
                  ...
          ./contrib
                  ./examples
                  ./jcr-commands
                  ./jcr-ext
                  ./jcrtaglib
                  ./phpcr
                  ./tck-webapp
                  ./textfilters
                  ./vfs
                  ...

Commentary:

* We'd keep the main Jackrabbit components (api, commons, and core) at 
the top level as they are now. They can be built and managed using a 
Maven multiproject setup at the top level Jackrabbit directory.

* The mature subprojects (like jcr-server) would be placed in 
./subprojects and managed as independent entities. It might be useful to 
include also them in the top level multiproject setup. At least they 
should be included in the site build. The same level of commit 
discipline (little or no failing builds) would be required as for the 
main components.

* The contrib projects would remain in ./contrib. They'd not be included 
in any of the top level builds, but (if made possible by the main site 
build script) contrib authors could commit their site builds to 
site/contrib to publish information about the contrib projects on the 
Jackrabbit web site.

* The ./application and ./xdocs directories remain as they are. I'm not 
totally happy with the current use of the ./application/test repository 
directory (it would be nicer to have it inside ./target), but that's 
another discussion.

Top-level build
---------------

As proposed by Roy, we should use the Maven Multi-Project plugin to 
manage builds at the top level. The maven.multiproject.includes property 
should be either the default (include only the main modules) or 
"*/project.xml,subprojects/*/project.xml" (include also the mature 
subprojects).

Additionally, to avoid dependency problems like the recent "maven clean" 
issue, we should change the "-dev" suffix to the Maven-standard 
"-SNAPSHOT" and start publishing periodic binary snapshots either on the 
Day repository or at Ibiblio. This would be nice for other purposes as well.

Web site navigation
-------------------

Following the above directory layout proposal, we could divide the web 
site like this:

     Apache Jackrabbit
         [the current documentation]
     Jackrabbit components
         Jackrabbit API
         Jackrabbit Commons
         Jackrabbit Core
     Jackrabbit subprojects
         JCR-RMI
         JCR Server
         ORM Persistence
         ...
     Jackrabbit contributions
         ...

The new sections would contain pointers to the individual subsites 
generated by multiproject. General documentation would remain at the top 
level, and the technical details (generated javadocs, developer 
instructions, TODOs, etc.) would be included in the subsites.

IDE and tool support
--------------------

It would be nicer for IDEs and various tools if the current main modules 
would _not_ extend the top level project.xml. For example at the moment 
you cannot just grab jackrabbit/commons and build it. Instead you need 
to get the whole Jackrabbit source tree to do this. As the top level 
project.xml contains mostly just descriptive information not directly 
used in building the sources, I'd propose removing this dependency. It 
would remove the contributor and mailing list information from the 
module projects, but I think we could manage with having that 
information only at the top level.

BR,

Jukka Zitting

Mime
View raw message