[EMAIL PROTECTED] schrieb:
An alternative is to split things up so that the parent pom (the pom
that other modules inherit from) is not the "module pom" (the one used
to drive "bulk builds" of nested directories). A subdirectory can be
created, the existing pom moved down into it, and a new trivial pom
created in the base directory that just has <module> tags in it. I
don't see any need to change the artifactId for the parent pom, so
AFAIK simply moving it within svn should not break anything.
For example, the main myfaces pom is in its own subdir, and has no
<module> tags.
The Orchestra code is also set up like this, with the parent pom in
the "myfaces/orchestra/maven" dir, and the "myfaces/orchestra/pom.xml"
file (which is never released) just contains module tags.
Setting things up like this makes sense when the various subdirs have
different release cycles, as is the case for Myfaces in general (core,
core12, tomahawk, trinidad, etc have different release cycles) and
Orchestra (core, core15, flow have different release cycles). Of
course thinks like (core/api, core/impl) do not have independent
release cycles, so having the "module" pom also be the parent pom
makes sense there.
I think that the build-tools modules do (or should) have independent
release cycles, so pushing the parent pom into a subdir makes sense
there.
And if it is pushed down into its own dir, then you could also use the
maven-release-plugin to release it :-)
Comments, anyone?
Are there any objections if I move the parent pom for the maven2-plugins
into its own subdir? If not, I'll try to find time to do that tonight...
