make aggregation feasible

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0-beta-1
  • Component/s: None
  • Labels:
    None

Description

some plugins need to be able to aggregate, eg the assembly plugin could take all the content based on its descriptor from the subprojects, and include them under a base path. However, at the moment it runs across all of the subprojects as well.

Need to be able to have a goal turn off the execution of the reactor (essentially it will be in aggregation mode), but have all the projects available to it (possibly just collecting - see the other bug about reactor execution modes).

Issue Links

is depended upon by

Improvement - An improvement or enhancement to an existing feature or task. MNG-662 Refactor release plugin to handle reactored build and release-pom.xml-SCM interactions.

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Task - A task that needs to be done. MNG-148 Write an ear mojo

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Mauro Botelho added a comment -

I was thinking about this while I was playing with the Eclipse plug-in. At the time, my thought was to solve it by passing the request as a reactor request, this way plugins could decide if they want to run in aggregate mode or not.

Show
Mauro Botelho added a comment - I was thinking about this while I was playing with the Eclipse plug-in. At the time, my thought was to solve it by passing the request as a reactor request, this way plugins could decide if they want to run in aggregate mode or not.
Hide
Permalink
Brett Porter added a comment -

in this case, a coupld of other features need to be implemented:

  • the code from DefaultMaven that does the project aggregation should be moved into the project builder as an optional function
  • dependency resolution that is triggered by a goal on the main project would also need to resolve dependencies of the collected projects on an aggregation enabled project
Show
Brett Porter added a comment - in this case, a coupld of other features need to be implemented:
  • the code from DefaultMaven that does the project aggregation should be moved into the project builder as an optional function
  • dependency resolution that is triggered by a goal on the main project would also need to resolve dependencies of the collected projects on an aggregation enabled project
Hide
Permalink
Brett Porter added a comment -

postponing - too much risk of destabilising ahead of release

Show
Brett Porter added a comment - postponing - too much risk of destabilising ahead of release
Hide
Permalink
John Casey added a comment -

release plugin becomes an aggregator plugin when refactored to handle reactored builds.

Show
John Casey added a comment - release plugin becomes an aggregator plugin when refactored to handle reactored builds.
Hide
Permalink
John Casey added a comment -

1. Plugins must declare @aggregator if they want to operate on the whole set of MavenProject instances at once without being applied repeatedly in standard reactor fashion.

2. LifecycleExecutor should preprocess the task list given from DefaultMaven (actually, from the CLI), and partition sets of tasks together, where continuous lists of non-aggregator tasks are grouped, and aggregator tasks are partitioned separately. Brett's example:

clean:clean install release:prepare site:site

are 3 partitions:

( clean:clean install ) ( release:prepare ) ( site:site )

To do this, we need to move MavenProject iteration out of DefaultMaven, and into the LE, right behind the aforementioned preprocessing/partitioning step. I'll use this as a jumping off point for implementation...

Show
John Casey added a comment - 1. Plugins must declare @aggregator if they want to operate on the whole set of MavenProject instances at once without being applied repeatedly in standard reactor fashion. 2. LifecycleExecutor should preprocess the task list given from DefaultMaven (actually, from the CLI), and partition sets of tasks together, where continuous lists of non-aggregator tasks are grouped, and aggregator tasks are partitioned separately. Brett's example: clean:clean install release:prepare site:site are 3 partitions: ( clean:clean install ) ( release:prepare ) ( site:site ) To do this, we need to move MavenProject iteration out of DefaultMaven, and into the LE, right behind the aforementioned preprocessing/partitioning step. I'll use this as a jumping off point for implementation...
Hide
Permalink
John Casey added a comment -

NOTE: currently using straight reactored builds ('-r' builds) with aggregator plugins CAN result in weirdness, since there is no clean hierarchy of projects, and the first one read into the system will be the one from which plugin configuration is read during task segmentation (not sure that this matters at all, actually, but just mentioning it...).

I'll let it get logged as a bug if there are specific cases where this is a problem.

Show
John Casey added a comment - NOTE: currently using straight reactored builds ('-r' builds) with aggregator plugins CAN result in weirdness, since there is no clean hierarchy of projects, and the first one read into the system will be the one from which plugin configuration is read during task segmentation (not sure that this matters at all, actually, but just mentioning it...). I'll let it get logged as a bug if there are specific cases where this is a problem.

People

  • Assignee:
    John Casey
    Reporter:
    Brett Porter
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: