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

["Karl Heinz Marbaise (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MDEP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karl Heinz Marbaise closed MDEP-153.
------------------------------------
    Resolution: Won't Fix

> Active dependencies being unpacked but not listed as normal dependencies are not used by the reactor in determing build order
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MDEP-153
>                 URL: https://issues.apache.org/jira/browse/MDEP-153
>             Project: Maven Dependency Plugin
>          Issue Type: Bug
>          Components: unpack
>    Affects Versions: 2.0
>            Reporter: James Carpenter
>            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:
> {code:xml}<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>{code}
> ============================================================================
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)