jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tobias.stras...@gmail.com>
Subject Re: Rethinking the great split
Date Wed, 03 Aug 2005 13:25:28 GMT
hi jukka,

> * Managing the current Jackrabbit build environment is relatively hard
> even with the multiproject plugin being used.
> * There is no longer a single Jackrabbit jar with an associated set of
> dependencies, leading to more complex documentation and deployment issues.
> * There is no obvious way to avoid navigational issues across the
> component sites generated by the current multiproject setup.
> * The unit test, checkstyle, and other reports are split over the
> component projects
> * The component structure points the way towards an even more fragmented
> project structure with separate component projects for example for
> individual persistence managers (see the recent "build problems" thread)

i totally agree, that multiproject support is not solved very
sophisticated in maven (at least in 1.0, i don't know about 2.0). for
our own product, we use maven, but only to manage the build process.
none of mavens site generation, unittest, etc. are used. we get the
best overview of our modules / (sub)projects using eclipse or idea.

> Even though I greatly appreciate the benefits of the restructuring
> (especially the commons library that I'm already using in a few other
> projects) I've come to feel that the problems outweight the benefits.
> 
> So, I'd like to propose to partially undo the changes related to
> JCR-157. Instead of the full api, commons, and core subprojects, I'd
> propose using package naming and design conventions to manage these
> components. We could have o.a.j.{api,commons,core} packages within a
> top-level ./src/main/java source directory. Additional component
> packages (like o.a.j.rmi) could be used if major contrib projects were
> to be fully integrated with Jackrabbit. The design constraints (like  no
> Jackrabbit dependencies in commons) could be enforced either manually or
> with some custom Checkstyle checks. The separate api and commons jar
> files could still be generated by a Maven postGoal rule. This change
> would solve above problems while still providing at least some of the
> original benefits.

well, i can't see another nice way of doing this. so maybe a common
source directory would be the easiest solution. however, we should
also check the new features of maven 2.0 in respect of multiproject
capabilities:

http://maven.apache.org/maven2/about.html#features
[...]
- Superior dependency management including automatic updating, dependency 
  closures (also known as transitive dependencies)
- Able to easily work with multiple projects at a time
[...]

i will give it a try and see if maven 2.0 would offer the needs we are
looking for.
cheers, tobi

-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97 
-----------------------------------------------< http://www.day.com >---

Mime
View raw message