You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Tobias Bocanegra <to...@gmail.com> on 2005/08/03 15:25:28 UTC
Re: Rethinking the great split
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 >---
Re: Rethinking the great split
Posted by Jérôme BENOIS <be...@argia-engineering.fr>.
I totally agree, Maven is good project but limited to manage
multiproject.
I had a same problems and now i am a Core-Developper of A.B.S. (Advanced
Build System). It's an ant tasks generator (all tasks are generated (on
the fly) by POM representation equivalent), see
http://abs.open-model.org.
ABS manage 2 concepts :
-> components : reusable source tree
-> projects : it's is an assembly of components
You can manage external libraries dependencies with 2 ant tasks :
dep:add.bin Add a new dependency to a binary component
dep:ls.bin List all binary dependencies
You can manage source dependencies (components dependencies) with 2 ant
tasks :
dep:add.src Add a new dependency to a source component
dep:ls.src List all source dependencies
And run unit tests or many others tasks :
test:java.all Run local Unit tests local and dependent components
test:java.local Run local Unit tests
...
For information, it's a young project but reactive (look the
changeLog ;-)) and a user guide is in the course of drafting !
And i could write news tasks for you ...
Jérôme.
--
The ABS team.
« Given enough eyeballs, all bugs are shallow »
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ABS ~ Advanced Build System ~
~ Next Generation Build System ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, 2005-08-03 at 15:25 +0200, Tobias Bocanegra wrote:
> 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
Re: Rethinking the great split
Posted by Jérôme BENOIS <be...@argia-engineering.fr>.
Hi,
On Wed, 2005-08-03 at 19:21 +0300, Jukka Zitting wrote:
> Hi,
>
> Tobias wrote:
> > 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:
>
> The Maven 2.0 option sounds interesting. Great if you can take some time
> to experiment with it. If it works out fine, I'd be happy to go along,
> otherwise we can fall back to the old model.
>
> About the ABS proposal: While the project seems interesting, it seems to
> be too premature for our needs. Even if Maven hasn't got a good answer
> to all our needs, it still covers many of them most excellently. In my
> opinion the multiproject problem is nowhere near grave enough to warrant
> considering a switch from Maven.
OK, I understand you but ABS isn't a premature project, ABS is based on
Jakarta Ant, and Ant is very stable ;-)
Thanks for your response,
Jérôme.
>
> BR,
>
> Jukka Zitting
>
--
The ABS team.
« Given enough eyeballs, all bugs are shallow »
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ABS ~ Advanced Build System ~
~ Next Generation Build System ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Rethinking the great split
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Tobias wrote:
> 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:
The Maven 2.0 option sounds interesting. Great if you can take some time
to experiment with it. If it works out fine, I'd be happy to go along,
otherwise we can fall back to the old model.
About the ABS proposal: While the project seems interesting, it seems to
be too premature for our needs. Even if Maven hasn't got a good answer
to all our needs, it still covers many of them most excellently. In my
opinion the multiproject problem is nowhere near grave enough to warrant
considering a switch from Maven.
BR,
Jukka Zitting