jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: build problems
Date Mon, 11 Jul 2005 08:26:58 GMT
hi jukka,

On 7/10/05, Jukka Zitting <jz@yukatan.fi> wrote:
> 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.

+1

> 
> * 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.

in general +1; however, if the subprojects were to be included in the
top level multiproject it should still be possible to build 'just' jackrabbit
without the subprojects. i am a little worried that work on core could 
be hampered otherwise. there's still the possibility of necessary
major changes in the core that could break some subprojects.

> 
> * 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.

+1

> 
> * 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.

+1 

> 
> 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).

+1

> 
> 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.

+1 

> 
> 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.

+1

> 
> 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.

+1 

btw: great job, thanks for taking the lead on this task!

cheers
stefan
> 
> BR,
> 
> Jukka Zitting
>

Mime
View raw message