[hibernate-dev] trunk project layout

[Steve Ebersole]

On Fri, 2009-09-11 at 14:07 +0200, Max Rydahl Andersen wrote:
> 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.

> 
> /max
> 
> Steve Ebersole 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.
> >
> >    
-- 
Steve Ebersole <steve at hibernate.org>
Hibernate.org