Before Maven starts executing plugins against projects, Maven first has to construct the build plan.
The build plan needs to take into account the inter-project GAV dependencies, so that the projects can be built in the correct sequence. So if A -> B -> C, Maven needs to ensure that C is built before A. This is the case irrespective of whether B is part of the reactor or not... because if C is part of the reactor, then A should be using the artifacts of C that were built from the reactor. So when you have a plugin execution bound to the lifecycle, and it says "I will need the dependencies" then Maven says: oh look, there will be a plugin that needs to resolve dependencies, therefore I need to compute the dependency graph and resolve it in order to ensure that any side-effects of the dependency graph do no affect my planned build order. So if you go "mvn install", Maven looks at the plugins for each module and sees that 'aggregation' (of type pom) has no plugin executions for its lifecycle where the dependencies need to be resolved resolved, fine the build plan is not going to be affected by inter-module dependencies, lets go When you go "mvn clean", Maven looks at the plugins, sees the 'exec' plugin will need to resolve dependencies and says... hmmm I had better take a look at the dependencies to see if they may impact my build plan... oh dear I cannot find this dependency anywhere... fail the build, because it's going to fail anyway and better to fail fast than waste the developers time. HTH -Stephen On 13 March 2013 15:10, Wolf Geldmacher <[email protected]> wrote: > Hail all ye maven gurus! > > I've (again) hit some issues with the-maven-way(tm) that I'd appreciate > your thoughts on: > > Using Maven 3.0.5/Java 1.7.0_10/Linux on an (abstracted) aggregation > project with two POMs: > > maven/pom.xml: > <project> > <modelVersion>4.0.0</**modelVersion> > > <groupId>maven.issue</groupId> > <artifactId>aggregation</**artifactId> > <version>2014.0.0-SNAPSHOT</**version> > <packaging>pom</packaging> > > <url>http://localhost/**documentation/maven<http://localhost/documentation/maven> > </url> > > <dependencies> > <dependency> > <groupId>maven.issue</groupId> > <artifactId>dependency</**artifactId> > <version>1.0</version> > </dependency> > </dependencies> > > <properties> > <project.build.sourceEncoding>**UTF-8</project.build.** > sourceEncoding> > </properties> > > <modules> > <module>dependency</module> > </modules> > > <build> > <plugins> > <plugin> > <groupId>org.codehaus.mojo</**groupId> > <artifactId>exec-maven-plugin<**/artifactId> > <version>1.2.1</version> > <configuration> > <executable>echo</executable> > </configuration> > <executions> > <!-- > Binding to the clean phase will make the > clean fail when any dependencies are specified > and we try run clean for a fresh project! > --> > <execution> > <id>clean</id> > <phase>clean</phase> > <goals> <goal>exec</goal> </goals> > <configuration> > <arguments> > <argument>Executing mvn clean</argument> > </arguments> > </configuration> > </execution> > </executions> > </plugin> > </plugins> > </build> > > <reporting> > <plugins> > <plugin> > <groupId>org.apache.maven.**plugins</groupId> > <artifactId>maven-site-plugin<**/artifactId> > <version>3.2</version> > </plugin> > <plugin> > <groupId>org.apache.maven.**plugins</groupId> > <artifactId>maven-project-**info-reports-plugin</** > artifactId> > <version>2.6</version> > <configuration> > <dependencyLocationsEnabled>**false</** > dependencyLocationsEnabled> > </configuration> > </plugin> > </plugins> > </reporting> > > </project> > > maven/dependency/pom.xml: > <project> > <modelVersion>4.0.0</**modelVersion> > > <groupId>maven.issue</groupId> > <artifactId>dependency</**artifactId> > <version>1.0</version> > > <url>http://localhost/**documentation/maven/dependency<http://localhost/documentation/maven/dependency> > **</url> > > <reporting> > <plugins> > <plugin> > <groupId>org.apache.maven.**plugins</groupId> > <artifactId>maven-site-plugin<**/artifactId> > <version>3.2</version> > </plugin> > <plugin> > <groupId>org.apache.maven.**plugins</groupId> > <artifactId>maven-project-**info-reports-plugin</** > artifactId> > <version>2.6</version> > </plugin> > </plugins> > </reporting> > > </project> > > > (1) When I run "mvn clean" on the top level *for the first time* I get > this error: > > [ERROR] Failed to execute goal on project aggregation: Could not resolve > dependencies \ > for project maven.issue:aggregation:pom:**2014.0.0-SNAPSHOT: \ > Failure to find maven.issue:dependency:jar:1.0 in <URL of our MRM> > > Obviously it cannot be in the MRM yet, as I'm building (this version) for > the first time, but: > - Why does maven even try to resolve this dependency when cleaning? > - And (just out of curiosity) why does it try to resolve that dependency > outside of the reactor? > > (2) Once the maven build cycle has been run beyond the "install" phase for > this project the dependency will be satisfied either from the local cache > or from the MRM - but: This makes a first time clean for each new version > behave differently from all later invocations and breaks the "mvn clean > install" mantra used by CI systems. The scenario cannot be that exotic and > we all want stable and reproducible builds - so: How do you solve it? > > (3) If you comment out the binding of "exec-maven-plugin:exec" to the > "clean" phase, a first time clean will succeed. > > Shouldn't adding a plugin to some phase be transparent w/r/t the > prerequisites of the phase? Who's to blame for the unexpected change in > behaviour? Is this a problem in the Maven core? Is this an issue with the > "exec-maven-plugin"? > > (4) Running "mvn site" on this same project shows a very similar problem: > The first time a site is generated (i.e. without having run the maven build > cycle to, or beyond, the "install" phase), site generation will fail with > the same message as above, even without any additional plugins bound to the > site phase. > > Is it considered "best practice" that the "site" life cycle implicitly > depends on the "build" life cylce, at least as far as dependencies are > concerned? If so: Why is it a different life cycle then? If not: Is there > some mechanism (type of dependency?) that I can use to specify a dependency > @compile, but not @site time? > > Thanks & Regards, > Wolf > > (hopefully the POMs make it through to the mailing list - otherwise i will > post a follow-up with external links) > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
