Details

    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      Add a commandline option to enable maven to expand the reactor scope to find projects that are dependencies
      of the projects currently in the reactor, and add them.

      Currently only the current project and child projects are included in the reactor search. I'm proposing
      to add a commandline switch that lets maven check parent directories to find the root of the project tree,
      and then do a normal reactor scan, only adding projects that would normally not be added if they're needed
      as dependencies of the projects that would normally be built.

      Here's a sample project tree:

      • root
        • p1
          • c1 (depends on p2)
        • p2 (depends on c2)
        • p3
          • c2

      And a sample algorithm:

      • When building c1, the reactor would contain [c1].
      • Maven would check p1, then root, etc, using the <parent> tags (without the versions!)
        to see if the project is still in the current reactor.
      • It would then create a second list of projects (reactor2) containing ALL projects, using the newly discovered root: [root, p1, c2, p2].
      • remove all projects from reactor2 contained in reactor: reactor2 = [root, p1, p2]
      • resolve all direct dependencies for all projects in reactor in reactor2 and add them to reactor, taking versions into account: reactor = [p2, c1]
      • repeat previous step until all projects have their dependencies resolved from reactor 2. first iteration would yield reactor = [c2, p2, c1],
        next iteration would stop since c1 doesn't have any dependencies present in reactor2.

      This would ensure that when some local project's sources have changed, they'll be incorporated
      in the build, regardless of where you build. So you don't have to do a reactor build each time you change more
      than 1 project, and you don't have to remember which projects you changed and build them in the correct order
      yourself, manually.

        Issue Links

          Activity

          Hide
          Brian Fox added a comment -

          Either way, if you expect this to affect eclipse:eclipse's generated output, it won't. Eclipse:eclipse is an aggregator and expects to see every project in the reactor when it produces the output. Your user story above needs to be written against the eclipse plugin.

          Show
          Brian Fox added a comment - Either way, if you expect this to affect eclipse:eclipse's generated output, it won't. Eclipse:eclipse is an aggregator and expects to see every project in the reactor when it produces the output. Your user story above needs to be written against the eclipse plugin.
          Hide
          Dan Fabulich added a comment -

          Joerg,

          A "," is not a "/".

          "foo,bar" is for directory structures that look like this:

          myroot
           |
           +-- foo
           +-- bar
           +-- quz
          

          Normally "mvn install" from "myroot" would build all three subdirectories ("foo" "bar" "quz"). But "mvn -pl foo,quz" would build just foo and quz.

          So you ask "what am I missing?" You're missing the "--also-make" directive.

          If you want to build "foo" and everything "foo" depends on, you'd write: "mvn -pl foo -am". If you want to build foo and quz and everything they depend on, then you'd write "mvn -pl foo,quz -am". If bar were a subdirectory of foo, you could write "mvn -pl foo/bar -am".

          I hope that helps. I'll try to put together a blog article about this in the hope that anyone could actually figure it out.

          Show
          Dan Fabulich added a comment - Joerg, A "," is not a "/". "foo,bar" is for directory structures that look like this: myroot | +-- foo +-- bar +-- quz Normally "mvn install" from "myroot" would build all three subdirectories ("foo" "bar" "quz"). But "mvn -pl foo,quz" would build just foo and quz. So you ask "what am I missing?" You're missing the "--also-make" directive. If you want to build "foo" and everything "foo" depends on, you'd write: "mvn -pl foo -am". If you want to build foo and quz and everything they depend on, then you'd write "mvn -pl foo,quz -am". If bar were a subdirectory of foo, you could write "mvn -pl foo/bar -am". I hope that helps. I'll try to put together a blog article about this in the hope that anyone could actually figure it out.
          Hide
          Jörg Hohwiller added a comment -

          Thanks guyz! Now I really know what this issue is all about.
          What I was missing is that the suggestion I made in MNG-3377 that was marked as a duplicate of this issue has almost nothing to do with this.

          Show
          Jörg Hohwiller added a comment - Thanks guyz! Now I really know what this issue is all about. What I was missing is that the suggestion I made in MNG-3377 that was marked as a duplicate of this issue has almost nothing to do with this.
          Hide
          Jörg Hohwiller added a comment -

          Who had the idea to use relative paths as arguments to "-pl" rather than [groupId:]artifactId?
          In the most common case this means more typing if you have more than one level of sub-moudles.

          mvn eclipse:eclipse -pl mmm-util/mmm-util-pojo

          would otherwise just be

          mvn eclipse:eclipse -pl mmm-util-pojo

          However that just the way it is now and no good idea to change it after being release...

          Show
          Jörg Hohwiller added a comment - Who had the idea to use relative paths as arguments to "-pl" rather than [groupId:] artifactId? In the most common case this means more typing if you have more than one level of sub-moudles. mvn eclipse:eclipse -pl mmm-util/mmm-util-pojo would otherwise just be mvn eclipse:eclipse -pl mmm-util-pojo However that just the way it is now and no good idea to change it after being release...
          Hide
          Benjamin Bentmann added a comment -

          Who had the idea to use relative paths as arguments to "-pl" rather than [groupId:]artifactId?

          I noticed that the current code already supports groupId:artifactId. So it looked natural to relax this to [groupId]:artifactId (see MNG-4244). Note the leading colon which allows to safely distinguish between a path and an artifact id (portable projects don't have a colon in their simple directory name).

          Show
          Benjamin Bentmann added a comment - Who had the idea to use relative paths as arguments to "-pl" rather than [groupId:] artifactId? I noticed that the current code already supports groupId:artifactId. So it looked natural to relax this to [groupId] :artifactId (see MNG-4244 ). Note the leading colon which allows to safely distinguish between a path and an artifact id (portable projects don't have a colon in their simple directory name).

            People

            • Assignee:
              Dan Fabulich
              Reporter:
              Kenney Westerhof
            • Votes:
              5 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: