Hi Benson Benson Margulies wrote: >> By the way, do you know any good and well managed example of a multi-module >> (Apache) project with different versions/life cycles for each module? > > Not, I think, in the sense that you mean. > > All my experience concerns two categories of project: monoliths, like > CXF, and ant farms, like Maven. > > You can model CXF as one big build tree with many modules that are > released on a completely locked lifecycle. > > Maven, on the other hand, has 27 independently-release items. They are > only and always released independently. No one ever makes a release of > maven-and-its-plugins. The Maven PMC makes releases of all the > different items, each on their own schedule. So no one is ever trying > to make a single artifact with all the sources of all of them, it > wouldn't make sense.
The Maven example is interesting. Even if it has independently released items, it also has an "apache-maven" module which aggregate some of those items in order to build the Apache Maven distribution: - https://svn.apache.org/repos/asf/maven/maven-3/trunk/apache-maven/ - http://www.apache.org/dist/maven/source/ This is somehow similar to what I was trying to do with JenaDist. Interestingly, they use <dependencies> (in their pom.xml file) + <dependencySet> (in their assembly.xml file) (as my first attempt) rather than <modules> + <moduleSets> (as my second attempt). I am still unclear to what are pros/cons of these two different approaches. Andy seemed to be in favor of the first approach, therefore I will rework JenaDist to use that instead. > > It seems to me that Jena wants to be more maven-like than CXF-like. Probably (but, I don't read minds). I have not strong opinions on this, I just want to find the solution which maximizes automation, minimizes process overhead and satisfy the need of Jena users and developers as well as committers. Sometimes it is difficult to understand what different people want. The JenaDist was an attempt to provide Jena users a single .zip file to download with all the necessary .jar in a lib/ directory (as we used to do for Jena + ARQ in the past) and all the command line scripts. Jena as a single jar has been mentioned in the past (and I want to explore possible solutions to do that as well). This will be another interesting experiment. Paolo
