[
http://jira.codehaus.org/browse/MASSEMBLY-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_102201
]
John Casey commented on MASSEMBLY-163:
--------------------------------------
which mojo are you binding into the plugin execution? If you're using
assembly:assembly, assembly:directory, or assembly:attached, then you may see
this behavior. (not entirely sure about assembly:attached, but I think it's in
that group.) This is because these mojos were meant to be run outside the
context of a normal build, and therefore fork a new lifecycle to build the
package phase. To address this shortcoming for bound assembly-plugin use cases,
we've created the assembly:single mojo, which assumes that it's bound into the
lifecycle at the appropriate point to ensure that the resources it needs are
available...you should give this one a spin.
> In a multiproject environment Assembly causes many unneded rebuilds
> --------------------------------------------------------------------
>
> Key: MASSEMBLY-163
> URL: http://jira.codehaus.org/browse/MASSEMBLY-163
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.1
> Environment: Linux Gentoo, Java 1.5.0_07_b3 sun, Maven 2.0.4, plugin
> 2.1
> Reporter: Simone Gianni
>
> I have a project subdivided in 10 modules. 2 of these modules uses the
> assembly plugin with the built-in descriptor "jar-with-dependencies".
> When running mvn clean install (or also only maven install) from the root of
> the project, I see that every time it is building one of the two sub-projects
> that uses the assembly plugin, it rebuilds some already built projects, even
> if they are not dependencies of the "to be assembled" project, nor they have
> any other apparent motivation to be rebuilded. One of the two project using
> assembly doesn't even has a single dependency on other project, but triggers
> a nearly complete rebuild.
> One of the projects is a WAR overlaying another war, useless to say that it
> consumes a lot of time, and gets built 3 times.
> I've tested also with -o to exclude possible changes in external
> dependencies, checked all the dependency tree to make sure that there were no
> circular or otherwise "crossed" dependencies, changed the order of <modules>
> in the parent pom to the best build order, checked by hand starting from an
> empty local repository that building the artifacts (by hand, one by one,
> commenting out the assembly) in that order satisfies all the dependencies.
--
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
