You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Wolf Geldmacher <wo...@abacus.ch> on 2013/03/13 16:10:50 UTC
Maven life cycle dependencies
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</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</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
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven life cycle dependencies
Posted by Stephen Connolly <st...@gmail.com>.
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 <wo...@abacus.ch> 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<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Maven life cycle dependencies
Posted by Adrien Rivard <ad...@gmail.com>.
On Wed, Mar 13, 2013 at 4:10 PM, Wolf Geldmacher
<wo...@abacus.ch>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<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
For the clean issue, you should add the maven-clean-plugin itself to the
execution and not the exec-maven-plugin.
see http://maven.apache.org/plugins/maven-clean-plugin/usage.html
--
Adrien Rivard
RE: Maven life cycle dependencies
Posted by Martin Gainty <mg...@hotmail.com>.
> Date: Thu, 14 Mar 2013 09:04:01 +0100
> From: wolf.geldmacher@abacus.ch
> To: users@maven.apache.org
> Subject: Re: Maven life cycle dependencies
>
> On 13.03.2013 16:58, Wayne Fay wrote:
> >> <dependencies>
> >> <dependency>
> >> <groupId>maven.issue</groupId>
> >> <artifactId>dependency</artifactId>
> >> <version>1.0</version>
> > ...
> >> <modules>
> >> <module>dependency</module>
> >> </modules>
> > This seems like a bad idea right up front. You shouldn't have a
> > dependency as a module in the same pom. You have constructed
> > essentially a circular reference.
> The strange setup is only due to my effort to reduce the example code to
> the minimum. I wanted to provide working POMs that all the scenarios I'm
> describing can be reproduced with.
MG>agree
MG>f you want to setup a grouping of dependencies thatr you want your parent pom to pass to the children use dependency-management
MG>http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management
>
> Cheers,
> Wolf
MG>Viel Gluck
MG>Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Maven life cycle dependencies
Posted by Wolf Geldmacher <wo...@abacus.ch>.
On 13.03.2013 16:58, Wayne Fay wrote:
>> <dependencies>
>> <dependency>
>> <groupId>maven.issue</groupId>
>> <artifactId>dependency</artifactId>
>> <version>1.0</version>
> ...
>> <modules>
>> <module>dependency</module>
>> </modules>
> This seems like a bad idea right up front. You shouldn't have a
> dependency as a module in the same pom. You have constructed
> essentially a circular reference.
The strange setup is only due to my effort to reduce the example code to
the minimum. I wanted to provide working POMs that all the scenarios I'm
describing can be reproduced with.
Cheers,
Wolf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven life cycle dependencies
Posted by Wayne Fay <wa...@gmail.com>.
> It's not _so_ bad as he isn't inheriting from the aggregator pom, so in
> effect the dependency forces the aggregator to be built last...
Good point, I didn't notice that, just assumed it was the parent which
is the typical layout...
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven life cycle dependencies
Posted by Stephen Connolly <st...@gmail.com>.
It's not _so_ bad as he isn't inheriting from the aggregator pom, so in
effect the dependency forces the aggregator to be built last...
Generally a bad practice, and Maven will blow up if you use the aggregator
as a parent for the child, but in this case he can get away with it (until
he hits his problem...)
On 13 March 2013 15:58, Wayne Fay <wa...@gmail.com> wrote:
> > <dependencies>
> > <dependency>
> > <groupId>maven.issue</groupId>
> > <artifactId>dependency</artifactId>
> > <version>1.0</version>
> ...
> > <modules>
> > <module>dependency</module>
> > </modules>
>
> This seems like a bad idea right up front. You shouldn't have a
> dependency as a module in the same pom. You have constructed
> essentially a circular reference.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Maven life cycle dependencies
Posted by Wayne Fay <wa...@gmail.com>.
> <dependencies>
> <dependency>
> <groupId>maven.issue</groupId>
> <artifactId>dependency</artifactId>
> <version>1.0</version>
...
> <modules>
> <module>dependency</module>
> </modules>
This seems like a bad idea right up front. You shouldn't have a
dependency as a module in the same pom. You have constructed
essentially a circular reference.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org