[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145199#action_145199
]
Gary S. Weaver commented on MNG-3719:
-------------------------------------
Note: the fact that that associated project's pom.xml and plugin executions
above are tied to the same lifecycle and yet do not execute in order seems to
be a bug with Maven 2, since it states on the lifecycle page in the
documentation
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
that:
"Note: As of Maven 2.0.5, multiple goals bound to a phase are executed in the
same order as they are declared in the POM."
However, it appears that is not working in Maven 2.0.9, because if it were,
then the above pom would execute in order as intended.
I think though that having executions be allowed to specify dependencies on
other executions is probably the better way to do it, wouldn't it be?
> Need to have a way to either define plugin execution dependencies on other
> plugin executions having executed first (at least within same lifecycle phase)
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-3719
> URL: http://jira.codehaus.org/browse/MNG-3719
> Project: Maven 2
> Issue Type: Bug
> Components: POM
> Affects Versions: 2.0.9
> Environment: Maven 2.0.9, java version "1.5.0_13" Java(TM) 2 Runtime
> Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
> Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
> Reporter: Gary S. Weaver
> Priority: Critical
> Attachments: plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
>
>
> I extend my sincere apologies if there is a much easier way of doing this,
> but so far I haven't found any.
> There should be some way to ensure order of plugin executions through
> dependencies on other executions. See attached project for example, or see
> below for the applicable example in a pom.xml. When plugins are defined in
> pom.xml in the following manner to ensure correct execution order, they are
> not executed sequentially and there is no way to indicate dependencies, as
> would be expected (note- I'm not expecting that it interpret the "step 1...",
> ..., "step 5..." IDs, I'm only suggesting that either the plugins be executed
> in order that they are found in the XML (most intuitive) or that there be
> some concept of priority/ordinal added, or even perhaps (this would be most
> "ant-like") that plugin executions (and maybe even plugin goal executions) be
> allowed to define prequisite execution IDs to be run (even if they are IDs
> not defined in the pom, but maybe a parent pom, even though I don't need that
> right now).
> I know that this could be problematic if a plugin execution from one
> lifecycle phase depends on another from another lifecycle phase (and you
> could get into circular references that way that would have to be recognized
> during pom validation after loading/merging pom.xmls). However, not being
> able to at the very least define order of execution of different (or the
> same) plugin executions as noted below and in attached project makes it
> difficult to chain plugin executions that depend on each other, thereby
> reducing the practicality of the pom.xml and Maven 2.
> For example, these plugin executions cannot be ordered properly in Maven
> 2.0.9, since there appears to be no way to indicate dependencies of one
> execution on another:
> {code}
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <configuration>
> <source>1.5</source>
> <target>1.5</target>
> </configuration>
> </plugin>
> <plugin>
> <!-- backup original source web.xml in preparation for
> chaining of plugin modifications to it -->
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-antrun-plugin</artifactId>
> <executions>
> <execution>
> <id>step 1 - backup-original-web.xml-from-src</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <tasks>
> <mkdir dir="${pom.basedir}/target"/>
> <mkdir dir="${pom.basedir}/target/tmpwebxml"/>
> <copy
> file="${pom.basedir}/src/main/webapp/WEB-INF/web.xml"
> todir="${pom.basedir}/target/tmpwebxml/"/>
> </tasks>
> </configuration>
> </execution>
> </executions>
> </plugin>
> <plugin>
> <!-- this plugin converts to
> ${basedir}/src/main/webapp/WEB-INF/web.xml to ${basedir}/target/jspweb.xml -->
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>jspc-maven-plugin</artifactId>
> <executions>
> <execution>
> <id>step 2 - jspc</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>compile</goal>
> </goals>
> </execution>
> </executions>
> <configuration>
> <injectString><!-- [INSERT JSPC FRAGMENT HERE]
> --></injectString>
> </configuration>
> <dependencies>
> <!-- These dependencies are the portlet.tld is needed for
> JSP compilation -->
> <dependency>
> <groupId>org.apache.pluto</groupId>
> <artifactId>pluto-taglib</artifactId>
> <version>1.1.3</version>
> <type>jar</type>
> </dependency>
> <dependency>
> <groupId>javax.portlet</groupId>
> <artifactId>portlet-api</artifactId>
> <version>1.0</version>
> <type>jar</type>
> </dependency>
> <dependency>
> <groupId>javax.servlet</groupId>
> <artifactId>jstl</artifactId>
> <version>1.1.2</version>
> <type>jar</type>
> </dependency>
> <dependency>
> <groupId>taglibs</groupId>
> <artifactId>standard</artifactId>
> <version>1.1.2</version>
> <type>jar</type>
> </dependency>
> </dependencies>
> </plugin>
> <plugin>
> <!-- copy modified web.xml file into source so it can be
> worked on by the another plugin. do this before each chained change to
> web.xml -->
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-antrun-plugin</artifactId>
> <executions>
> <execution>
> <id>step 3 -
> copy-jspc-web.xml-atop-web.xml-in-src</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <tasks>
> <copy file="${pom.basedir}/target/jspweb.xml"
> todir="${pom.basedir}/src/main/webapp/WEB-INF/"/>
> </tasks>
> </configuration>
> </execution>
> </executions>
> </plugin>
> <!-- bind 'pluto:assemble' goal to 'generate-resources' lifecycle
> -->
> <plugin>
> <!-- this plugin converts to
> ${basedir}/src/main/webapp/WEB-INF/web.xml to
> ${basedir}/target/pluto-resources/web.xml -->
> <groupId>org.apache.pluto</groupId>
> <artifactId>maven-pluto-plugin</artifactId>
> <version>${pluto.version}</version>
> <executions>
> <execution>
> <id>step 4 - pluto-modifications-to-web.xml</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>assemble</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-war-plugin</artifactId>
> <configuration>
> <warName>NewsReaderPortlet</warName>
>
> <!--<webXml>${basedir}/src/main/webapp/WEB-INF/web.xml</webXml>-->
> <!--<webXml>${basedir}/target/jspweb.xml</webXml>-->
> <webXml>${basedir}/target/pluto-resources/web.xml</webXml>
> </configuration>
> <dependencies>
> <dependency>
> <groupId>org.apache.pluto</groupId>
> <artifactId>pluto-util</artifactId>
> <version>${pluto.version}</version>
> <scope>provided</scope>
> </dependency>
> </dependencies>
> </plugin>
>
> <plugin>
> <!-- restore original web.xml file back into source after
> "chained" plugin modifications are complete -->
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-antrun-plugin</artifactId>
> <executions>
> <execution>
> <id>step 5 - restore-web.xml-to-src</id>
> <phase>generate-resources</phase>
> <goals>
> <goal>run</goal>
> </goals>
> <configuration>
> <tasks>
> <copy
> file="${pom.basedir}/target/tmpwebxml/web.xml"
> todir="${pom.basedir}/src/main/webapp/WEB-INF/"/>
> </tasks>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
