Maven 2 & 3

Make Like Reactor Mode

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
Kenney Westerhof added a comment -

fixed algorithm description

Show
Kenney Westerhof added a comment - fixed algorithm description
Hide
Brian Fox added a comment -

Seems almost exactly what I wrote in this proposal: http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode

Show
Brian Fox added a comment - Seems almost exactly what I wrote in this proposal: http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode
Hide
Dan Fabulich added a comment -

Checked in revision 687388.

Show
Dan Fabulich added a comment - Checked in revision 687388.
Hide
Paul Benedict added a comment -

To be inline with the issue management that marks issues for branch/head as 2.0.x and 2.1.x, is this something that is also being slated for 3.0? If so, please add the version.

Show
Paul Benedict added a comment - To be inline with the issue management that marks issues for branch/head as 2.0.x and 2.1.x, is this something that is also being slated for 3.0? If so, please add the version.
Hide
Dan Fabulich added a comment -

I don't think I understand your question, but maybe this will help: revision 687388 was made to branches/maven-2.1.x. I have not ported it to trunk. The fate of the maven-2.1.x branch is up in the air right now, but I imagine that we will do a release off of that branch, and that it will be called 2.1.0 or possibly 2.1.1.

Show
Dan Fabulich added a comment - I don't think I understand your question, but maybe this will help: revision 687388 was made to branches/maven-2.1.x. I have not ported it to trunk. The fate of the maven-2.1.x branch is up in the air right now, but I imagine that we will do a release off of that branch, and that it will be called 2.1.0 or possibly 2.1.1.
Hide
Trevor Harmon added a comment -

Brian, are you sure that this issue is the same as your proposal? In the issue's description, there is a "root" ancestor project that is common to all child projects. In your proposal, however, there is no such common ancestor. ("packages", "services", and "ui" are orphans.)

Show
Trevor Harmon added a comment - Brian, are you sure that this issue is the same as your proposal? In the issue's description, there is a "root" ancestor project that is common to all child projects. In your proposal, however, there is no such common ancestor. ("packages", "services", and "ui" are orphans.)
Hide
Jörg Hohwiller added a comment -

This feature is exactly what I am looking for. E.g. this would help for eclipse:eclipse and many other things. Since the issue is closed, I have the question how to use it. I downloaded 2.1.0 and mvn -version says:
Maven version: 2.1.0-M1
mvn --help tells me about this option:

r,-reactor Execute goals for project found in the
reactor

Is this what came out of this issue?
I thought that if I call maven on some module (e.g. "c1" from the example above) with this option, it would behave as if called with the same goal on the toplevel (root) but executions of the actual goal is only performed in the called module ("c1").
So I tried
mvn -r eclipse:eclipse
on one of my modules but I get:

Cannot execute mojo: eclipse. It requires a project with an existing pom.xml, but the build is not using one.

there is a valid pom.xml in the working directory.

What do I miss?
Could you help me with what "closed/fixed" means here?

Show
Jörg Hohwiller added a comment - This feature is exactly what I am looking for. E.g. this would help for eclipse:eclipse and many other things. Since the issue is closed, I have the question how to use it. I downloaded 2.1.0 and mvn -version says: Maven version: 2.1.0-M1 mvn --help tells me about this option: r,-reactor Execute goals for project found in the reactor Is this what came out of this issue? I thought that if I call maven on some module (e.g. "c1" from the example above) with this option, it would behave as if called with the same goal on the toplevel (root) but executions of the actual goal is only performed in the called module ("c1"). So I tried mvn -r eclipse:eclipse on one of my modules but I get: Cannot execute mojo: eclipse. It requires a project with an existing pom.xml, but the build is not using one. there is a valid pom.xml in the working directory. What do I miss? Could you help me with what "closed/fixed" means here?
Hide
Brian Fox added a comment -

You don't have the right 2.1 if it says 2.1.0-M1. It should be:

Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400)

And then you will have these options:
pl,-projects Build specified reactor projects
instead of all projects
r,-reactor Dynamically build reactor from
subdirectories

Show
Brian Fox added a comment - You don't have the right 2.1 if it says 2.1.0-M1. It should be: Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) And then you will have these options: pl,-projects Build specified reactor projects instead of all projects r,-reactor Dynamically build reactor from subdirectories
Hide
Jörg Hohwiller added a comment -

Thanks for the hints.
I updated to official 2.1.0.
However I am clueless with "-r" whatever it should do. It is definitively NOT what I described in MNG-3377.

I also tried -pl which is sort of not-intuitive. I have to supply the full path down to my module.

The showcase of doing a eclipse:eclipse on a single module but having the project in the reactor so project dependencies are not pointing to jars did NOT work.

I did
cd mmm (toplevel)
mvn eclipse:eclipse
cd mmm-util/mmm-util-core
mv .classpath .classpath.ori
cd ../..
mvn eclipse:eclipse -pl mmm-util/mmm-util-pojo
cd mmm-util/mmm-util-core
diff .classpath .classpath.ori

I get:
12c12
< <classpathentry kind="var" path="M2_REPO/net/sf/m-m-m/mmm-util-core/1.0.3-SNAPSHOT/mmm-util-core-1.0.3-SNAPSHOT.jar" sourcepath="M2_REPO/net/sf/m-m-m/mmm-util-core/1.0.3-SNAPSHOT/mmm-util-core-1.0.3-SNAPSHOT-sources.jar"/>

> <classpathentry kind="src" path="/mmm-util-core"/>

All I wanted in MNG-3377 is
cd mmm-util/mmm-util-core
mvn -r eclipse:eclipse
and have the project dependencies as build from toplevel.

Please note eclipse:eclipse is just one usecase here.

Is this a bug or shall I reopen MNG-3377 because it is no duplicate and this issue is something different that is no use for me?

Show
Jörg Hohwiller added a comment - Thanks for the hints. I updated to official 2.1.0. However I am clueless with "-r" whatever it should do. It is definitively NOT what I described in MNG-3377. I also tried -pl which is sort of not-intuitive. I have to supply the full path down to my module. The showcase of doing a eclipse:eclipse on a single module but having the project in the reactor so project dependencies are not pointing to jars did NOT work. I did cd mmm (toplevel) mvn eclipse:eclipse cd mmm-util/mmm-util-core mv .classpath .classpath.ori cd ../.. mvn eclipse:eclipse -pl mmm-util/mmm-util-pojo cd mmm-util/mmm-util-core diff .classpath .classpath.ori I get: 12c12 < <classpathentry kind="var" path="M2_REPO/net/sf/m-m-m/mmm-util-core/1.0.3-SNAPSHOT/mmm-util-core-1.0.3-SNAPSHOT.jar" sourcepath="M2_REPO/net/sf/m-m-m/mmm-util-core/1.0.3-SNAPSHOT/mmm-util-core-1.0.3-SNAPSHOT-sources.jar"/> — > <classpathentry kind="src" path="/mmm-util-core"/> All I wanted in MNG-3377 is cd mmm-util/mmm-util-core mvn -r eclipse:eclipse and have the project dependencies as build from toplevel. Please note eclipse:eclipse is just one usecase here. Is this a bug or shall I reopen MNG-3377 because it is no duplicate and this issue is something different that is no use for me?
Hide
Dan Fabulich added a comment -

It's not "-r" you want. -r is when you have a directory full of subdirectories, each of which is a project. I won't explain -r, because it makes very little sense.

Instead, I'm going to compare the new feature to an old feature. This may confuse you, because it may make you accidentally use the old feature instead of the new feature.

Before this bug MNG-2576 was fixed, you had to use the Maven Reactor Plugin. http://maven.apache.org/plugins/maven-reactor-plugin/

Now, you can use --project-list, --also-make, --also-make-dependents, and --resume-from to get a similar effect.

Here's a table of old commands and their new Maven 2.1 commands.

1) "mvn reactor:resume -Dfrom=bar" is now "mvn --resume-from bar"
2) "mvn reactor:make -Dmake.folders=foo,bar" is now "mvn --project-list foo,bar --also-make"
3) "mvn reactor:make-dependents -Dmake.folders=foo,bar" is now "mvn --project-list foo,bar --also-make-dependents"

Make-like functionality is complicated; read the documentation for maven-reactor-plugin for more details.

Show
Dan Fabulich added a comment - It's not "-r" you want. -r is when you have a directory full of subdirectories, each of which is a project. I won't explain -r, because it makes very little sense. Instead, I'm going to compare the new feature to an old feature. This may confuse you, because it may make you accidentally use the old feature instead of the new feature. Before this bug MNG-2576 was fixed, you had to use the Maven Reactor Plugin. http://maven.apache.org/plugins/maven-reactor-plugin/ Now, you can use --project-list, --also-make, --also-make-dependents, and --resume-from to get a similar effect. Here's a table of old commands and their new Maven 2.1 commands. 1) "mvn reactor:resume -Dfrom=bar" is now "mvn --resume-from bar" 2) "mvn reactor:make -Dmake.folders=foo,bar" is now "mvn --project-list foo,bar --also-make" 3) "mvn reactor:make-dependents -Dmake.folders=foo,bar" is now "mvn --project-list foo,bar --also-make-dependents" Make-like functionality is complicated; read the documentation for maven-reactor-plugin for more details.
Hide
Jörg Hohwiller added a comment -

Thanks for the clarification. Funny that I missed reactor-plugin - it could have saved me a lot of time already.
Anyways there is no "-project-list" so I assume you mean "-projects" instead.
However that is the same as "-pl" what I used in the quoted example above.
And it is simply NOT working. From what I experience

mvn -pl foo/bar mygoal

is nothing but

cd foo/bar
mvn mygoal

Wow!
What am I missing?

Show
Jörg Hohwiller added a comment - Thanks for the clarification. Funny that I missed reactor-plugin - it could have saved me a lot of time already. Anyways there is no "-project-list" so I assume you mean "-projects" instead. However that is the same as "-pl" what I used in the quoted example above. And it is simply NOT working. From what I experience mvn -pl foo/bar mygoal is nothing but cd foo/bar mvn mygoal Wow! What am I missing?
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

Vote (5)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved: