Hi, To make a long story short, i will begin with the questiom:
I'm trying to figure out what is the Maven way to do this. How can i put up standards for different kind of poms types (ejb's, assemblies, ears, etc) in a multimodule environment without using different parents? -- The long story -- I'm migrating an entire build environment from ant to maven2 for a company with many, many projects. The most important thing is the corporate pom. This contains all configuration about how to build ejb's, wars, assemblies. This has been put mainly in the pluginManagement section, to be activated by sub poms. Now i'm working on many multimodule projects. The modules have the multimodule project as parent, so we can define properties and dependency(management) for an entire multimodule project. So far so good. However when i setup de poms for modules i still have to explicitly activate all the plugins it needs. For instance, for an assembly module i have to invoke 5 different plugins (1 * dependency:copy-dependencies, 3 * scm:checkout, 1 * assembly:package). Although, the configuration of these plugins are setup in the corporate pom, i still have to activate the plugins in each module. So i'm basically duplicating plugin invocations for each module. I'm trying a way to solve this. Of course i could create different corporate poms, like: 1. corporate assembly pom 2. corporate ear pom 3. ... and let the modules inherit from that. But this disables the reuse of properties and dependencies on in multimodule projects poms. I've tried to following things: 1. Profiles Put plugin invocations in profiles and let modules activate them. -> This does not work. There is no way to activate a profile (defined in the corporate pom) for a specific module. The profile will be activated for all modules or for none. They only way to activate a profile for a specific module, is to define the entire profile in that module. No option. 2. Create different lifecycle Using plexus, creating a new lifecycle with new phases. If i could create new phases, then i could for instance create specific assembly phases and bind plugins to those phases. The lifecycle should be activated by specifying a new kind of pom packaging. -> Creating new phases is not supported by maven (there is only little documentation about this) 3. Create plugins to alter maven If tried creating plugins like ProfileActivators (which inject profiles in specific conditions). -> This does not work. They entire lifecycle execution seems to have been build up in advance. There seems no way to alter this. 4. Write my own plugins to replace the invocation different plugins. -> This is no good. Since plugins/mojo cannot be reused i end up rewriting a lot of plugin code. And rewriting the scm plugin for instance..., just seems to be a bad thing to me. 5. Use the maven-invoker-plugin to let each module invoke itself with a predefined profile. The only plugin in a module would be the invoker plugin. -> This works, but.... this will startup a new maven reactor for each module. I'm not facing lifecycle issues YET, but also this seems to be a bad thing. -- So to summarize again: I'm trying to figure out what is the Maven way to do this. How can i put up standards for different kind of poms types (ejb's, assemblies, ears, etc) in a multimodule environment without using different parents? Basically i'm looking for lifecycle execution reusability. Define a set of plugin invocations including configuration in a corporate pom. And activate/reuse this lifecycle execution in a specific module, keeping the pom of the module clean. I've also read Deterministic Lifecycle Planning to come with maven 2.1 (can't wait :)) and i'm trying to figure out if that would solve these issues. Can anybody comment on this? -- View this message in context: http://www.nabble.com/Looking-for-lifecycle-execution-reusability-%28building-a-corporate-pom%29-tp15450774s177p15450774.html Sent from the Maven Developers mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
