On Tue, Jul 22, 2008 at 11:33 AM, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
> [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... > +1, we need to make more modular this part for release plugins
