I am not happy with the way hibernate is built currently (see http://in.relation.to/12116.lace for part of the details). One thing I do not like currently is the way "release related" stuff and "code" are mixed. To me, I'd really prefer that "release" be something that was a separate "lifecycle" (to borrow the Maven terminology) on the root project where we ran the jdocbook plugin and generally built the SF release assemblies. Anyway, I wanted to throw the idea out there to get feedback and see what suggestions folks have.

I am not happy with the way hibernate is built currently (see http://in.relation.to/12116.lace for part of the details). One thing I do not like currently is the way "release related" stuff and "code" are mixed. To me, I'd really prefer that "release" be something that was a separate "lifecycle" (to borrow the Maven terminology) on the root project where we ran the jdocbook plugin and generally built the SF release assemblies. Anyway, I wanted to throw the idea out there to get feedback and see what suggestions folks have.

> In the words of Arnaud (commenter on the blog), isn't the GateIn > approach what you want ? > > 1 project with submodules, all have the same version thus the parent is > the reactor ? > Different discussions. The "GateIn approach" is *functionally* no different than what we have today Max. The only difference at all is that our aggregator (the top level) does not (1) define the "parent information" nor (2) inherit the same "parent information". And as Arnaud goes on to admit, the fact that Maven does not differentiate types of metadata is a design flaw.

> btw. I remember we initially did this parent were put in a dir on its > own to make eclipse > happy - that is not really a concern anymore since later eclipse > versions can handle > having a root project and just exclude the directories that are also > projects in Eclipse terminology. > That's not the reason, no. I split parent out because of 2 reasons: 1) (philosophical) because that's what makes sense 2) (practical) because otherwise you ended up having to run install on root immediately after checkout to actually work on any of the sub-modules. As it stands today, you can install parent/ and then immediately do your work on core/ because parent is the only piece it depends on. If "parent information" is merged into the aggregator you instead have to run a full install (code, docs, tutorials, etc) just to work on a patch to core. Actualy #2 really illustrates why I find Maven's binary-only dependencies cumbersome. Binary-only is just another way to say that the modules are separately versionable. If Maven allowed source-level dependencies (aka, these modules are always checked out and worked on together and therefore no need to look in repo) then one would not need to run the install on root initially to be able to do work on sub-modules. And the new -am/-amd stuff is a step in that direction but its band-aids on top of (imo) bad design decisions.

Hi, I am just wondering if you could elaborate what exactly the problem with the release. I think so far you are the only one who actually did a release for Core using the current setup. Hibernate Search and Validator also use the maven release plugin and there is works just fine. Admittedly the project structures are much simpler there. Since you seem most annoyed about the release plugin, couldn't we just extend it or write our own? You already put so much work into custom maven plugins, what's the difference with the release plugin? Picking up on Max's comment - the parent directory for the master pom is really not needed anymore. I think pretty much all IDE can handle now a proper maven module setup. Last but not least, regarding your problem of building only sub modules from the command line. I personally build always from the top level directory. If I want to build a single submodule I use the '--project' command line options. I also found somewhere a bash completion script for maven (if someone is interested I can post it here) so I can just type 'mvn --project' and expand the sub modules by using the tab key. This approach served me well in Validator the last few month. --Hardy On Fri, 11 Sep 2009 07:07:40 +0200, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > I am not happy with the way hibernate is built currently (see > http://in.relation.to/12116.lace for part of the details). > > One thing I do not like currently is the way "release related" stuff and > "code" are mixed. To me, I'd really prefer that "release" be something > that was a separate "lifecycle" (to borrow the Maven terminology) on the > root project where we ran the jdocbook plugin and generally built the SF > release assemblies. > > Anyway, I wanted to throw the idea out there to get feedback and see > what suggestions folks have. >