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: [email protected]
For additional commands, e-mail: [email protected]
