multi-project pain

[Torsten Curdt <tc...@apache.org>]

Alright guys! You know I love maven - I harass you on IIRC often
enough. But let me give some ...let's call it "user feedback".

I have to say I am impressed how much documentation is actually
available on the website! And the book is awesome! Congrats!
Unfortunately both are missing out on multi-projects ...which
(according to the user's list) is obviously where quite a few people
are struggling at the moment.

Some things I came across when I moved commons jci to maven2...

I wanted the different jci compiler implementations to be available as
different jars and be able to compile them individually. Multi-project
- clear choice. So I went ahead and found out this can be done with
the "module" tags. First thought: Why "modules"? Everyone talks about
"multi-projects" and "artifacts" ...but anyway. So I changed the
layout and and created poms for all the compiler sub-projects.

When I tried to build the (main) project I got told off that packaging
was meant to be "pom" not "jar" ...ok - but why? (I mean
conceptually?) ...anyway, I changed that but then I had to realize
that my core classes (meant to be build from the main pom) where not
getting compiled. Hm... so obviously package type "pom" means the
build section gets ignored and ...well, no package is getting created.
Well, fair enough - having a separate jar for the core is not too bad.
So I changed that. Cool - builds!

I've ignored the tests so far. But let's look into that now. Hm... the
core tests do need a compiler implementation to run. Hm... the
compilers depend on the core so the test would need to run after both
compilers and the core are compiled ..crap! That doesn't work. Hm...
it would be more than just a PITA to mock a compiler for the core. So
I ended up creating another "test" modules that depends on core and a
compiler implementation. Ok. Not fantastic but works. Well ...maybe
not a bad idea in the end anyway.

Still a happy camper so far - now this is where the real pain begins.
Let's look into the reports and project documentation generation. So I
defined a few reports in the parent pom, built the site and had a
look. Hm ...the general information from the parent pom is there - but
where is the stuff that comes from the sub-projects?! I would have
expected to get at least a project node for each sub-project in the
left navigation bar. Searching on the web I found a "${modules}" tag
that might need to be included into the site.xml. Hm.... still no
luck. Further reading through the archives.... "What is this skin
plugin thingy?" Confused. Ok. Different approach.

Although I really hate to move the documentation and the site into the
core sub-project I gave it a try. So the idea is that the core site
will become the main site. If I don't get the reports for the compiler
sub-projects ....well, I could live without them - they are only
wrappers. But this sucks! But let's try it.

So I moved all the reports from the parent pom into the core pom. No
defined reports for the parent, nothing to inherrit to the
sub-projects and I will just define my site in the core. I expected
that a call to site will just get ignored by the parent and passed on
to the core site goal which will do the actual work ...but now
-although I haven't defined a single report- a whole bunch of reports
(more than I ever had defined) get generated for the parent pom - WTF?

If anyone could help me get the commons-jci site up and running that
would be great.
I am currently feeling a bit lost in this area of maven.

http://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk/


And BTW:

On the front page "Information for Maven 1.0 Users" should include a link to

 http://maven.apache.org/guides/mini/guide-m1-m2.html

You guys should also provide a stylesheet for migrating at least
something from the project.xml to the pom.xml.

And IMO maven is way too verbose. Guys you are talking to a user.
"[INFO]" and stuff like that is good for log a file but not for a user
output. If you output less you could also get rid of some of the
"---------------------------------------------"

...lines.

Puuh! Thanks for listening ...feels better now :)

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: multi-project pain

[Torsten Curdt <tc...@apache.org>]

> > ...why? Could you elaborate?
> > I find the current behaviour counter-intuitive.
>
> I think if you were building a jar that had <modules>, 9/10 people would
> expect the modules to be included in some way.

Hm... the whole point of modules is to be modular - and not be part of the whole
thing. So of course it would nice to be able to include them in war e.g. but
I would not expect them in the jar. Maybe I am really 1 out of 10 ...but I
would not be too sure of that.

> > Hmm... this "multi-module" support does not seem to be ready for prime
> > time yet. What is it worth if only a few plugins support aggregation
> > ...and not even surefire (which is one of most important ones!) does!
>
> I'm assuming you just forgot the <sarcasm> tags :)

Well, let's say the <frustration> tags.

> > Applying patches for further aggregation support would help too *nutch* ;)
> >
> > http://jira.codehaus.org/browse/MTAGLIST-6
>
> You can apply this yourself now.

Thought I only have sandbox access!? If not - consider it done.

> > http://jira.codehaus.org/browse/MPMD-28
>
> It's on "the list".

Oh, boy ...I know these list ;)

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: multi-project pain

[Brett Porter <br...@apache.org>]

Torsten Curdt wrote:
>> > I meant: why shouldn't also the parent pom have a src directory and
>> > generate a jar? I don't understand the concept of this distinction
>> > that forces me to have all my code in modules.
>>
>> It would be counter-intuitive unless it were aggregating.
> 
> ...why? Could you elaborate?
> I find the current behaviour counter-intuitive.

I think if you were building a jar that had <modules>, 9/10 people would 
expect the modules to be included in some way.

> Hmm... this "multi-module" support does not seem to be ready for prime
> time yet. What is it worth if only a few plugins support aggregation
> ...and not even surefire (which is one of most important ones!) does!

I'm assuming you just forgot the <sarcasm> tags :)

> 
> Applying patches for further aggregation support would help too *nutch* ;)
> 
> http://jira.codehaus.org/browse/MTAGLIST-6

You can apply this yourself now.

> http://jira.codehaus.org/browse/MPMD-28

It's on "the list".

Cheers,
Brett

-- 
Brett Porter <br...@apache.org>
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: multi-project pain

[Torsten Curdt <tc...@apache.org>]

> multi-module

ok ...multi-module it is from now on :)

> > I meant: why shouldn't also the parent pom have a src directory and
> > generate a jar? I don't understand the concept of this distinction
> > that forces me to have all my code in modules.
>
> It would be counter-intuitive unless it were aggregating.

...why? Could you elaborate?
I find the current behaviour counter-intuitive.

> > Next big thing would be aggregation support for the surefire plugin.
> > Does anyone have that on his cards yet?
>
> Not that I know of.

Hmm... this "multi-module" support does not seem to be ready for prime
time yet. What is it worth if only a few plugins support aggregation
...and not even surefire (which is one of most important ones!) does!

Applying patches for further aggregation support would help too *nutch* ;)

http://jira.codehaus.org/browse/MTAGLIST-6
http://jira.codehaus.org/browse/MPMD-28

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: multi-project pain

[Brett Porter <br...@apache.org>]

Torsten Curdt wrote:
>> > First thought: Why "modules"? Everyone talks about
>> > "multi-projects" and "artifacts"
>>
>> I try to avoid calling it multiproject for this reason.
> 
> So how do you call it then? ;)

multi-module

> 
>> > When I tried to build the (main) project I got told off that packaging
>> > was meant to be "pom" not "jar" ...ok - but why?
>>
>> Currently, there's no real concept of aggregation in the standard
>> packaging plugins, so it makes no sense to have a build root with a type
>> other than pom.
> 
> I meant: why shouldn't also the parent pom have a src directory and
> generate a jar? I don't understand the concept of this distinction
> that forces me to have all my code in modules.

It would be counter-intuitive unless it were aggregating.

> Next big thing would be aggregation support for the surefire plugin.
> Does anyone have that on his cards yet?

Not that I know of.

- Brett

-- 
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: multi-project pain

[Torsten Curdt <tc...@apache.org>]

> > First thought: Why "modules"? Everyone talks about
> > "multi-projects" and "artifacts"
>
> I try to avoid calling it multiproject for this reason.

So how do you call it then? ;)

> > When I tried to build the (main) project I got told off that packaging
> > was meant to be "pom" not "jar" ...ok - but why?
>
> Currently, there's no real concept of aggregation in the standard
> packaging plugins, so it makes no sense to have a build root with a type
> other than pom.

I meant: why shouldn't also the parent pom have a src directory and
generate a jar? I don't understand the concept of this distinction
that forces me to have all my code in modules.

> >  So I ended up creating another "test" modules that depends on core and a
> > compiler implementation. Ok. Not fantastic but works. Well ...maybe
> > not a bad idea in the end anyway.
>
> This is a pretty common pattern. What is your API doing that it needs an
> implementation to test it? How do you differentiate testing the API from
> the implementation? I think it's a good practice to separate them.

Yes, in the end having the test separate is maybe not that bad at all.

What I am actually trying to test is the monitoring, notification and
the reloading ...which is triggered by a compilation. Of course I
*could* mock a compiler ...but that's a bit of an effort. Maybe I will
do it at some stage. It would be cleaner - but so far the testcases
just use one of the implementations.

> > "What is this skin plugin thingy?" Confused. Ok. Different approach.
>
> That stuff is new, and only released as a beta yesterday. I tried to
> include some docs in the site, but it probably needs some more.

Cool ...nice to have a beta out :)

> > Although I really hate to move the documentation and the site into the
> > core sub-project I gave it a try. So the idea is that the core site
> > will become the main site. If I don't get the reports for the compiler
> > sub-projects ....well, I could live without them - they are only
> > wrappers. But this sucks! But let's try it.
>
> You lost me here as to why moving it to the core project was even necessary.

I did not want the reports to run for every module so I just picked
one of the modules to build the site. I would have to change into that
directory and build the site from there. Not nice. Also did not stick
with it.

> I wouldn't recommend moving the whole site into the core project - you
> should be able to build all your reporting sections as part of a
> reactored site, possibly aggregating some as I think you've since
> discovered.

Yepp ...finally :)

> However, I recommend the content goes into a separate
> parallel directory. (See chapter 6 of the book).

Aha ....must have missed that one - will have a read.

> > So I moved all the reports from the parent pom into the core pom. No
> > defined reports for the parent, nothing to inherrit to the
> > sub-projects and I will just define my site in the core. I expected
> > that a call to site will just get ignored by the parent and passed on
> > to the core site goal which will do the actual work ...but now
> > -although I haven't defined a single report- a whole bunch of reports
> > (more than I ever had defined) get generated for the parent pom - WTF?
>
> Can you give more details? The only default reports should be the
> project info reports.

Well ....more than I expected ;-)

IMO there should be no default reports. Too much magic. Keep it
simple. If it's not in the pom - it does not appear.

> > http://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk/
>
> Did you since get this sorted or still need help?

Well, I finally got it working ...somehow

 http://jakarta.apache.org/commons/sandbox/jci

Not perfect - but a first page that I can update. Still if you could
spend 2 minutes having a look at the layout and the pom ...would be
really appreciated.

AND!! Please (with sugar on top!) ...I need the these two patches applied

 http://jira.codehaus.org/browse/MPMD-28
 http://jira.codehaus.org/browse/MTAGLIST-6

as creating the site currently only works with my locally patched plugins.

Next big thing would be aggregation support for the surefire plugin.
Does anyone have that on his cards yet?

> > And BTW:
> >
> > On the front page "Information for Maven 1.0 Users" should include a
> > link to
> >
> > http://maven.apache.org/guides/mini/guide-m1-m2.html
>
> done.

Cool

> > You guys should also provide a stylesheet for migrating at least
> > something from the project.xml to the pom.xml.
>
> We actually have code to do it in the sandbox. Nobody has pushed it into
> a plugin yet though.

Whatever ...link that stylesheet from the upgrade guide. Maybe someone
comes up with a plugin. If not one can at least use xsltproc for the
easy upgrade.

> > And IMO maven is way too verbose. Guys you are talking to a user.
> > "[INFO]" and stuff like that is good for log a file but not for a user
> > output. If you output less you could also get rid of some of the
>
> Agreed.

Great :)

> > Puuh! Thanks for listening ...feels better now :)
>
> Good to hear :)

;-)

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: multi-project pain

[Brett Porter <br...@apache.org>]

Torsten Curdt wrote:
> First thought: Why "modules"? Everyone talks about
> "multi-projects" and "artifacts" 

I try to avoid calling it multiproject for this reason.

> When I tried to build the (main) project I got told off that packaging
> was meant to be "pom" not "jar" ...ok - but why? 

Currently, there's no real concept of aggregation in the standard 
packaging plugins, so it makes no sense to have a build root with a type 
other than pom.

> I've ignored the tests so far. But let's look into that now. Hm... the
> core tests do need a compiler implementation to run. Hm... the
> compilers depend on the core so the test would need to run after both
> compilers and the core are compiled ..crap! That doesn't work. Hm...
> it would be more than just a PITA to mock a compiler for the core. So
> I ended up creating another "test" modules that depends on core and a
> compiler implementation. Ok. Not fantastic but works. Well ...maybe
> not a bad idea in the end anyway.

This is a pretty common pattern. What is your API doing that it needs an 
implementation to test it? How do you differentiate testing the API from 
the implementation? I think it's a good practice to separate them.

> Let's look into the reports and project documentation generation. So I
> defined a few reports in the parent pom, built the site and had a
> look. Hm ...the general information from the parent pom is there - but
> where is the stuff that comes from the sub-projects?! I would have
> expected to get at least a project node for each sub-project in the
> left navigation bar. Searching on the web I found a "${modules}" tag
> that might need to be included into the site.xml. Hm.... still no
> luck. Further reading through the archives.... "What is this skin
> plugin thingy?" Confused. Ok. Different approach.

That stuff is new, and only released as a beta yesterday. I tried to 
include some docs in the site, but it probably needs some more.

> Although I really hate to move the documentation and the site into the
> core sub-project I gave it a try. So the idea is that the core site
> will become the main site. If I don't get the reports for the compiler
> sub-projects ....well, I could live without them - they are only
> wrappers. But this sucks! But let's try it.

You lost me here as to why moving it to the core project was even necessary.

I wouldn't recommend moving the whole site into the core project - you 
should be able to build all your reporting sections as part of a 
reactored site, possibly aggregating some as I think you've since 
discovered. However, I recommend the content goes into a separate 
parallel directory. (See chapter 6 of the book).

> So I moved all the reports from the parent pom into the core pom. No
> defined reports for the parent, nothing to inherrit to the
> sub-projects and I will just define my site in the core. I expected
> that a call to site will just get ignored by the parent and passed on
> to the core site goal which will do the actual work ...but now
> -although I haven't defined a single report- a whole bunch of reports
> (more than I ever had defined) get generated for the parent pom - WTF?

Can you give more details? The only default reports should be the 
project info reports.

> If anyone could help me get the commons-jci site up and running that
> would be great.
> I am currently feeling a bit lost in this area of maven.
> 
> http://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk/

Did you since get this sorted or still need help?

> 
> 
> And BTW:
> 
> On the front page "Information for Maven 1.0 Users" should include a 
> link to
> 
> http://maven.apache.org/guides/mini/guide-m1-m2.html

done.

> 
> You guys should also provide a stylesheet for migrating at least
> something from the project.xml to the pom.xml.

We actually have code to do it in the sandbox. Nobody has pushed it into 
a plugin yet though.

> And IMO maven is way too verbose. Guys you are talking to a user.
> "[INFO]" and stuff like that is good for log a file but not for a user
> output. If you output less you could also get rid of some of the

Agreed.

> Puuh! Thanks for listening ...feels better now :)

Good to hear :)

- Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org