[MDEP-153] Active dependencies being unpacked but not listed as normal dependencies are not used by the reactor in determing build order

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Won't Fix
• Affects Version/s: 2.0
• Component/s: unpack
• Assignee: Unassigned
• Reporter: James Carpenter
• Created: 06/Mar/08 10:58
• Updated: 30/Apr/15 21:12
• Resolved: 30/Apr/15 21:12

Description

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)

Issue Links

• is related to: MDEP-106 Unpacking primary artifact from sibling module uses repository rather than reactor