[ http://jira.codehaus.org/browse/MASSEMBLY-35?page=all ]
Jason van Zyl moved MNG-1462 to MASSEMBLY-35:
---------------------------------------------
Version: (was: 2.0)
Fix Version: (was: 2.0.1)
type: Bug (was: Improvement)
Component: (was: maven-assembly-plugin)
Workflow: jira (was: Maven)
Key: MASSEMBLY-35 (was: MNG-1462)
Project: Maven 2.x Assembly Plugin (was: Maven 2)
> assembly:assembly forks a lifecycle and cannot be used in a reactor
> environment. Need a new mojo suitable for this environment,
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: MASSEMBLY-35
> URL: http://jira.codehaus.org/browse/MASSEMBLY-35
> Project: Maven 2.x Assembly Plugin
> Type: Bug
> Reporter: Jerome Lacoste
> Assignee: John Casey
> Priority: Critical
> Attachments: MNG-1462-attached_mojo_for_assembly_plugin.diff
>
> Original Estimate: 30 minutes
> Remaining: 30 minutes
>
> Basically I use the assembly plugin in a module under the reactor project.
> I attach the assembly plugin to the verify phase (because of MNG-1311), but
> somehow when my module is being processed, the plugin is executed for the
> package phase and it
> forks the full project lifecycle, because it is an aggregator.
> This triggers the rebuild all my reactor projects.
>
> This happens twice (I have 2 modules which use the assembly plugin),
> making my build 3 times too long.
>
>
>
> Now investigating the issue.
>
> The stack trace looks like:
>
> private void executeGoalAndHandleFailures( String task, MavenSession session,
> MavenProject project,
> EventDispatcher dispatcher, String
> event, ReactorManager rm,
> long buildStartTime, String target
> )
>
> private void executeGoal( String task, MavenSession session, MavenProject
> project )
>
> private void executeGoalWithLifecycle( String task, MavenSession session, Map
> lifecycleMappings,
> MavenProject project, Lifecycle
> lifecycle )
>
> private void executeGoals( List goals, MavenSession session, MavenProject
> project )
> throws LifecycleExecutionException, BuildFailureException,
> PluginNotFoundException
>
> private void forkLifecycle( MojoDescriptor mojoDescriptor, MavenSession
> session, MavenProject project )
> throws LifecycleExecutionException, BuildFailureException,
> PluginNotFoundException
>
> which creates the redundancy here:
>
> private void forkLifecycle( MojoDescriptor mojoDescriptor, MavenSession
> session, MavenProject project )
> throws LifecycleExecutionException, BuildFailureException,
> PluginNotFoundException
> {
> PluginDescriptor pluginDescriptor =
> mojoDescriptor.getPluginDescriptor();
> getLogger().info( "Preparing " + pluginDescriptor.getGoalPrefix() +
> ":" + mojoDescriptor.getGoal() );
>
> if ( mojoDescriptor.isAggregator() )
> {
> for ( Iterator i = session.getSortedProjects().iterator();
> i.hasNext(); )
> {
> MavenProject reactorProject = (MavenProject) i.next();
>
> line();
>
> getLogger().info( "Building " + reactorProject.getName() );
>
> line();
>
> forkProjectLifecycle( mojoDescriptor, session, reactorProject
> );
> }
> }
> else
> {
> forkProjectLifecycle( mojoDescriptor, session, project );
> }
> }
>
>
> The redundancy appears because the assembly plugin is an aggregator so if
> forked it will fork all reactor projects.
>
> It is forked in my case because the execute phase is not null.
>
> In DefaultLifeCycleExecutor:
>
> private void executeGoals( List goals, MavenSession session, MavenProject
> project )
> throws LifecycleExecutionException, BuildFailureException,
> PluginNotFoundException
> {
> for ( Iterator i = goals.iterator(); i.hasNext(); )
> {
> MojoExecution mojoExecution = (MojoExecution) i.next();
>
> MojoDescriptor mojoDescriptor = mojoExecution.getMojoDescriptor();
>
> if ( mojoDescriptor.getExecutePhase() != null ||
> mojoDescriptor.getExecuteGoal() != null )
> {
> forkLifecycle( mojoDescriptor, session, project );
> }
>
>
> and getExecutePhase() is "package"
>
> Now before executing this:
>
> Map lifecycleMappings = constructLifecycleMappings( session,
> task, project, lifecycle );
> executeGoalWithLifecycle( task, session, lifecycleMappings,
> project, lifecycle );
>
>
> my lifecycleMappings contains 3 entries each with a list of single
> MojoExecution instances
>
> install -> ME21
> verify -> MJ17
> test -> MJ20
>
>
> Then when this mappings are processed as a goal chain:
>
> List goals = processGoalChain( task, lifecycleMappings, lifecycle );
>
> The goals have been sorted so that:
>
> (MJ20, MJ17, MJ21) which looks OK to me.
>
> which were constructed by:
>
>
> private Map constructLifecycleMappings( MavenSession session, String
> selectedPhase, MavenProject project,
> Lifecycle lifecycle )
> throws LifecycleExecutionException, BuildFailureException,
> PluginNotFoundException
> {
> // first, bind those associated with the packaging
> Map lifecycleMappings = bindLifecycleForPackaging( session,
> selectedPhase, project, lifecycle );
>
> // next, loop over plugins and for any that have a phase, bind it
> for ( Iterator i = project.getBuildPlugins().iterator(); i.hasNext();
> )
> {
> Plugin plugin = (Plugin) i.next();
>
> bindPluginToLifecycle( plugin, session, lifecycleMappings,
> project );
> }
>
> return lifecycleMappings;
> }
>
> Links to a somewhat related issue: http://jira.codehaus.org/browse/MNG-1311
> Now a little chat with jdcasey conclude that a new Mojo needs to be created:
> (18:02:35) jdcasey: CoffeeBre: it doesn't seem to have anything to do with it
> being an aggregator...it's all based on that @execute phase="package"
> annotation
> (18:02:48) jdcasey: that prompts the lifecycle executor to fork the
> lifecycle, and re-run package
> (18:02:50) jdcasey: hmm
> (18:03:49) jdcasey: looks like this mojo isn't designed to be integrated into
> the lifecycle
> (18:04:13) jdcasey: it looks like you'd have to write another mojo front-end
> for the assembly process, which doesn't specify @execute phase="package" in
> it.
> (18:04:49) jdcasey: the mojo could be a thin wrapper around the real guts,
> which would be in a separate class
> (18:05:15) jdcasey: I think that would be the simplest way around.
> (18:05:43) ***jdcasey thinks the @execute annotation is poorly named...
> (18:05:46) CoffeeBre: what about removing the @execute phase instaed?
> (18:06:02) jdcasey: well, then you lose the ability to call 'mvn
> assembly:assembly'
> (18:06:10) jdcasey: because it requires the package phase.
> (18:07:04) jdcasey: something like assembly:attached would be good,
> IMO...that's what you want to do, right? attach them to the main project
> artifact so they're installed/deployed too?
> (18:07:27) jdcasey: that new mojo could reference the same code, which would
> be factored into a general case api in that plugin
> (18:07:34) CoffeeBre: and with regard to the aggregator, I mentionned it
> because of line 701 in DefaultLifeCycleExecutor
> (18:08:02) jdcasey: yeah, but if you look, that just determines *how* the
> lifecycle is forked, not *whether*
> (18:08:32) CoffeeBre: you mean it shouldn't be forked at all? (I am trying to
> follow)
> (18:10:42) jdcasey: CoffeeBre: you need a new mojo that integrates with the
> existing lifecycle, but has to bind on or after the package phase...rather
> than forking
> (18:11:57) CoffeeBre: jdcasey: see also MNG-1310 and MNG-1274. related to my
> use of the assembly plugin
> (18:16:53) CoffeeBre: jdcasey: trying to summarize. If I follow you, the
> issue is because the assembly:assembly mojo is forking and we don't want
> that. So I create a simple Mojo wrapper within the assembly plugin with 2
> differences. Map to assembly:attached, and do not specify a @execute. Could
> that be the solution for MNG-1311 as well?
> (18:17:45) jdcasey: CoffeeBre: that won't solve MNG-1311, because we need to
> eliminate the infinite loop (thought I worked on that once already)
> (18:18:16) jdcasey: CoffeeBre: you may need to factor some logic out of the
> existing AssemblyMojo into a common class, or extend it (not sure whether the
> annotations will show through when extending)
> (18:18:41) jdcasey: if you factor into common API, and reference from both
> the AssemblyMojo and the new AttachedAssemblyMojo (or whatever) it'll
> definitely work
> (18:18:56) jdcasey: but the new mojo should *not* specify the execute stuff
> (18:19:46) jdcasey: CoffeeBre, jeremyw: I've gotta run out for a bit, but
> I'll be back in like an hour or so
> (18:19:58) CoffeeBre: jdcasey: I wondered if the infinite loop was not
> created by the fact that the plugin was aggregating all the projects
> (18:20:35) jdcasey: CoffeeBre: um, possibly...but I think aggregation is
> appropriate here...not sure, I'd have to investigate further.
> (18:20:49) CoffeeBre: jdcasey: ok. Have to run out as well. Will create an
> issue and add info there.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
