Yep you got it. If you need to turn that off, you'll need to redefine an execution using the same id to clear/change the behavior.
-----Original Message----- From: Jackson, Paul [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 1:20 PM To: Maven Users List Subject: RE: Reuse Best Practice Thank you for this suggestion - I had not heard of pluginManagement. If I understand you correctly, I add a pluginManagement section to the pom that is at a level that all my projects inherit. In my example it would be at com.g1.dcg and the section would look something like this: <build> <pluginManagement> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>unpack</id> <goals> <goal>unpack</goal> </goals> <!--phase>compile</phase--> <configuration> <artifactItems> <artifactItem> <groupId>com.g1.cdq.remotebuild</groupId> <artifactId>remotebuildscripts</artifactId> <version>${pom.version}</version> <type>zip</type> <outputDirectory>${project.build.directory}/dependencies</outputDirector y> </artifactItem> </artifactItems> </configuration> </execution> </executions> </plugin> </plugins> </pluginManagement> </build> I can deploy this pom with no problem because these plugins are defined in pluginManagement instead of plugins. Very cool. The three children that use this not only need to add this to their poms: <build> <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> </plugin> </plugins> </build> Any child that needs maven-dependency-plugin but doesn't want that configuration can override that in their poms. This should work for me. Thanks. -Paul -----Original Message----- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 12:11 PM To: Maven Users List Subject: RE: Reuse Best Practice Using a common parent (grand-parent in this case) of your parents is what you want. If you are trying to share plugin configuration, use pluginManagement to set the config. Then the children can just declare the plugin and they will inherit the config, while the (grand)parent will install because the plugin won't actually execute at the parent. -----Original Message----- From: Jackson, Paul [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2008 11:58 AM To: users@maven.apache.org Subject: Reuse Best Practice Hi, I'm fairly new to maven and have reached a point where I am unsure the best way to share configuration settings across projects. I am familiar with the <parent> tag and we use that, primarily, to inherit the version #. Since a pom can have only one parent, I am wondering what is the best way to share configuration info amongst multiple projects that have different parents. Consider this tree of projects owned by my team. com.g1 (Root POM, points to repositories) com.g1.dcg (Sets release number for all projects) com.g1.dcg.one com.g1.dcg.one.jar com.g1.dcg.one.modules (Zips up all native code) com.g1.dcg.one.modules.jni (Scripts that compile jni on 8 different platforms) com.g1.dcg.two com.g1.dcg.two.jar com.g1.dcg.two.modules com.g1.dcg.two.modules.jni (Scripts that compile jni on 8 different platforms) com.g1.dcg.three com.g1.dcg.three.jar com.g1.dcg.three.modules com.g1.dcg.three.modules.jni (Scripts that compile jni on 8 different platforms) com.g1.dcg.remotebuild.scripts (Common ant scripts used by jni tasks) The remotebuild scripts project contains some ant scripts that use scp and sshexec tasks to build the jni for a given project on all our supported platforms. For any of the jni projects to use these, they must use the maven-dependency-plugin to unpack the scripts and the maven-antrun-plugin to to execute it. I addition they need to call the native-maven-plugin and the build-helper-maven-plugin to zip up and attach the results. It's these 4 plugin configurations that I would like to reuse. I have considered two possibilities; 1) Create a parent pom that have these 4 plugins defined (Inheritance) 2) Create my own plugin that aggregates these functions (Composition) The issues I encountered with option 1 are: a) I can't have more than one parent per pom, so I am forced to choose between my natural tree and the pom containing the configuration I would like to reuse b) Getting the pom into the repository. mvn deploy requires a pom to build successfully, so my parent pom wouldn't deploy because it wasn't in a project containing all the source needed for building on 8 platforms. I tried mvn deploy:deploy-file, and this worked a little better, but I would have to do this by hand each time I made a change. The issues with option 2 are: a) I don't feel like writing a Java program just to wrap perfectly good mojos b) A plug-in requires a separate goal and execution for each phase in which it runs, leading to a decent amount of repeated configuration across projects. Thanks, -Paul NOTICE: This E-mail may contain confidential information. If you are not the addressee or the intended recipient please do not read this E-mail and please immediately delete this e-mail message and any attachments from your workstation or network mail system. If you are the addressee or the intended recipient and you save or print a copy of this E-mail, please place it in an appropriate file, depending on whether confidential information is contained in the message. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
