<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html; charset=ISO-8859-1"

 http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

<br>

<blockquote cite="mid:1252679248.3463.13.camel@localhost.localdomain"

 type="cite">

  <blockquote type="cite">

    <pre wrap="">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 ?

    </pre>

  </blockquote>

  <pre wrap=""><!---->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.

  </pre>

</blockquote>

Well, I thought one of your main pain point were the independent

versioning - but I guess that<br>

is not really a problem in both.<br>

<blockquote cite="mid:1252679248.3463.13.camel@localhost.localdomain"

 type="cite">

  <blockquote type="cite">

    <pre wrap="">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.

    </pre>

  </blockquote>

  <pre wrap=""><!---->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.

  </pre>

</blockquote>

I agree, but i.e. m2eclipse solves this (all dependencies can be

resolved against the workspace) so I will assume<br>

something like this is possible in Maven 3 (which is what m2eclipse

uses internally to allow for this)<br>

<br>

/max<br>

</body>

</html>