[hibernate-dev] trunk project layout

[Max Rydahl Andersen]

>> 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.
>    
Well, I thought one of your main pain point were the independent 
versioning - but I guess that
is not really a problem in both.
>> 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.
>    
I agree, but i.e. m2eclipse solves this (all dependencies can be 
resolved against the workspace) so I will assume
something like this is possible in Maven 3 (which is what m2eclipse uses 
internally to allow for this)

/max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090911/99a6eac1/attachment.html