Maven
  1. Maven
  2. MNG-2184

Possible problem with @aggregator and forked lifecycles

    Details

    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      In the Clover plugin the report mojo is an aggregator (http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/main/java/org/apache/maven/plugin/clover/CloverReportMojo.java). It also spawns a forked lifecycle:

      * @execute phase="test" lifecycle="clover"
      * @aggregator
      

      When I run this clover report on the Cargo API module, which contains children modules, all the modules are executed several times as shown in the attached logs. They should be executed only once. The @aggregator is supposed to execute only once and it executes several times.

      1. cargo.log
        59 kB
        Vincent Massol

        Issue Links

          Activity

          Hide
          John Casey added a comment -

          thinking about this more, if an aggregator mojo is bound simultaneously to two module poms in the same reactor, where should it execute? If it's bound to a pom at all, then merely the root location of the reactor may change whether the aggregator runs or not, using the logic from revId: 619721.

          I'm commenting that code out until I can think about this more, and come up with something. I really think the safest solution may be to prohibit aggregators in the lifecycle at all.

          Show
          John Casey added a comment - thinking about this more, if an aggregator mojo is bound simultaneously to two module poms in the same reactor, where should it execute? If it's bound to a pom at all, then merely the root location of the reactor may change whether the aggregator runs or not, using the logic from revId: 619721. I'm commenting that code out until I can think about this more, and come up with something. I really think the safest solution may be to prohibit aggregators in the lifecycle at all.
          Hide
          brianfox brianfox added a comment -

          We need to support aggregators in the lifecycle, i'm convinced of that, but they should only run at the root of the execution, just like its done from the cli.

          Show
          brianfox brianfox added a comment - We need to support aggregators in the lifecycle, i'm convinced of that, but they should only run at the root of the execution, just like its done from the cli.
          Hide
          John Casey added a comment -

          But what are the implications for that? If they're bound to the usual root pom of a project hierarchy, then they will always be included in the build process, because all modules should inherit from that top-level pom, and maven will get the opportunity to limit the mojo to one execution. However, if the aggregator is bound to one of the child modules, then it would run when the child is built in isolation (since it would be included in the build-plan of the root project), but NOT when the build is run from the top-level POM (which would be the root project, and the aggregator isn't bound to this POM but one of its modules.

          So, that leaves us with some sort of session attribute that tracks the execution of aggregators, to limit their execution to once-per-build.

          Now, what if two of the child modules specify a binding to the same aggregator mojo, with different configurations? In this case, it will all fall apart, since the binding project is not the root project, and both aggregator bindings really are meant to execute.

          What do we do in those cases??

          Why do we absolutely need aggregator mojos that are bound to the lifecycle? What are the real use cases, and is there a better solution that we could design? Personally, I'd much rather see the pre- and post-execution mojo thing that we talked about in the comments of:

          http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning

          IF we could find a way to make their binding and execution behavior consistent regardless of how a collection of POMs is built (i.e. which ones are included should not modify the build of any one of them).

          Show
          John Casey added a comment - But what are the implications for that? If they're bound to the usual root pom of a project hierarchy, then they will always be included in the build process, because all modules should inherit from that top-level pom, and maven will get the opportunity to limit the mojo to one execution. However, if the aggregator is bound to one of the child modules, then it would run when the child is built in isolation (since it would be included in the build-plan of the root project), but NOT when the build is run from the top-level POM (which would be the root project, and the aggregator isn't bound to this POM but one of its modules. So, that leaves us with some sort of session attribute that tracks the execution of aggregators, to limit their execution to once-per-build. Now, what if two of the child modules specify a binding to the same aggregator mojo, with different configurations? In this case, it will all fall apart, since the binding project is not the root project, and both aggregator bindings really are meant to execute. What do we do in those cases?? Why do we absolutely need aggregator mojos that are bound to the lifecycle? What are the real use cases, and is there a better solution that we could design? Personally, I'd much rather see the pre- and post-execution mojo thing that we talked about in the comments of: http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning IF we could find a way to make their binding and execution behavior consistent regardless of how a collection of POMs is built (i.e. which ones are included should not modify the build of any one of them).
          Hide
          brianfox brianfox added a comment -

          The ounce:application goal is an aggregator that is intended to be bound to a pom. We need to collect the information about all child projects. I think that where ever in the tree an aggregator is defined, it should run once there. Meaning if it shows up in two children, well then it runs for each of those (once for each of those trees)

          The aggregation part isn't really what is needed if there is another way to get the fully interpolated child projects....this is what is really needed.

          Show
          brianfox brianfox added a comment - The ounce:application goal is an aggregator that is intended to be bound to a pom. We need to collect the information about all child projects. I think that where ever in the tree an aggregator is defined, it should run once there. Meaning if it shows up in two children, well then it runs for each of those (once for each of those trees) The aggregation part isn't really what is needed if there is another way to get the fully interpolated child projects....this is what is really needed.
          Hide
          John Casey added a comment -

          you're not talking about an aggregator mojo, just a regular one that uses $

          {reactorProjects}

          ...and @inheritedByDefault false (or whatever that annotation is).

          Show
          John Casey added a comment - you're not talking about an aggregator mojo, just a regular one that uses $ {reactorProjects} ...and @inheritedByDefault false (or whatever that annotation is).

            People

            • Assignee:
              John Casey
              Reporter:
              Vincent Massol
            • Votes:
              27 Vote for this issue
              Watchers:
              24 Start watching this issue

              Dates

              • Created:
                Updated: