> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
