jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jérôme BENOIS <ben...@argia-engineering.fr>
Subject Re: Rethinking the great split
Date Wed, 03 Aug 2005 15:47:18 GMT
I totally agree, Maven is good project but limited to manage

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

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

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

View raw message