[
http://jira.codehaus.org/browse/MDEP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126366
]
Brian Fox commented on MDEP-153:
--------------------------------
This will never be possible to fix with Maven 2.0.x, but it is one of the use
cases I discussed with John while putting together:
http://docs.codehaus.org/display/MAVEN/Atypical+Plugin+Use+Cases
> 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
