Active dependencies being unpacked but not listed as normal dependencies are
not used by the reactor in determing build order
-----------------------------------------------------------------------------------------------------------------------------
Key: MDEP-153
URL: http://jira.codehaus.org/browse/MDEP-153
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.0
Reporter: James Carpenter
Assignee: Brian Fox
Priority: Critical
I have a multi-module build in which one child module is using the unpack goal
to expand the contents of a sibling module. Unfortunately, when building from
the parent level the reactor fails to consistently create an appropriate order
because the unpacked sibling artifact is not listed as a normal dependency.
(The sibling artifact being extracted happens to be an attached artifact, but
that is a lesser issue.)
=================================================
Workaround:
Add a fake dependency at test scope which excludes all transitive dependencies
to the module which is unpacking the sibling artifact. This has the negative
side effect of slightly polluting the test classpath.
Within the sibling pom module with the unpack goal I have content similar to:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>process-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
</execution>
</executions>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.mycompany.myproject</groupId>
<artifactId>module-A</artifactId>
<version>${project.version}</version>
<type>zip</type>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.directory}/expansiondirectory</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<!--The dependency listed here must correspond to the primary
artifact of module-A.
From experimentation I have discovered the reactor will only
recognize an artifact as an
active artifact if the type matches the packaging of the
sibling being referenced.-->
<dependency>
<groupId>com.mycompany.myproject</groupId>
<artifactId>module-A</artifactId>
<version>${project.version}</version>
<type>jar</type>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependencies>
============================================================================
Proposed solution:
1) Add support in maven for dependencies of "ghost" scope.
2) Some mechanism a plugin can use an injected component to affect reactor
build order.
Both of the above solutions are way to light in detail, to be of much use. I
only have shallow knowledge of how the reactor works with the artifact resolver
and other components to figure out build order. Therefore, I can't propose a
solid solution without spending more time digging around in the maven code.
The core maven developers can probably think of several solutions on the top of
their head.
==============================================================================
Related JIRA: MDEP-106
==============================================================================
Old Relevant Posting:
An old posting in the mailing list shows I'm not the only one to have
encountered this problem:
Link:
http://www.nabble.com/control-of-reactor-ordering-from-plugin-td7481761s177.html#a7481761
===============================================
Subject: control of reactor ordering from plugin
by Brian E Fox Nov 21, 2006; 04:45pm :: Rate this Message: - Use ratings to
moderate (?)
Reply | Reply to Author | Print | View Threaded | Show Only this Message
This is a usability question but also dev related since the answer may
require/prompt changes to the dependency plugin.
I'm using assembly:attached to generate many different zip files that
package things I want to reuse. In this case, some data to be imported
into hsql for unit test purposes. This zip file occurs in a sub module
/data/modules. In /data/variants I have more assembly:attached things
that depend on the product of the rest of the builds. In otherwords, the
dependency tree effectively is: /data/variant[s] -> service jars ->
/data/module[s].
Since I'm using the dependency plugin to unpack/copy artifacts, these
zips are effectively dependencies but Maven doesn't know because they
aren't explicitely listed in the dependency section. We attempted to
list these zips as proper dependencies to affect the ordering, but in
doing so, Maven fails because it can't find a pom that matches the zip
(remember we have pom packaging with assembly:attached to deploy).
Putting the data child at the top of the module tree in the parent pom
works a little, but Maven still doesn't understand that some jars need
to be built before executing the data/modules assemblies. (we can
control a little by listing the jars as dependencies and won't run into
the missing pom problem like the assembly:attached zips but I'm looking
for a way to make the dependency-plugin more robust)
So, the question is: Is it possible to modify the dependency plugin in a
way to allow it to take part in the ordering phase that Maven does
before executing the builds? (ie to have it inject some dependencies to
the tree) Alternatively, is there a way to allow the dependency plugin
to detect that some artifacts are in the same reactor build and cause
them to be built before continuing? (fork perhaps? - not ideal because
presumably these modules would then be built 2x)
--
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
