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