jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2 & 3
  • MNG-3377

Build reactor from toplevel pom

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Not A Bug
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

The following is all about multi-project environments.
For many maven calls the result differs if you perform you mvn command on the toplevel project
or in a specific module. In the latter case the related modules of the projects are not included in the reactor
causing the result to be invalid or the build to fail.
There should be a way that I can call maven within a particular module causing the reactor
to be build from the toplevel pom while walking the relativePath (defaults to ../pom.xml) upwards
until a pom is reached, that has no parent. From that pom the reactor should be build,
while the actual build should work on the module where maven was invoked.

A typical example use-case would be the command "mvn eclipse:eclipse".
Right now it does not create project-internal dependencies if it is called
within the module. This is especially nasty when you have a local sandbox
module that should not (yet) be committed. Then you always need to add it
as extra module to your parent pom, call eclipse:eclipse and then revert the changed pom.

Additional use-cases are that you want to build a specific module rather than
the entire project. Right now you need to enter the module, give "mvn install" a try.
If it fails, you will see which dependency is missing. Then you go there before
and try "mvn install" there. This process is iterated until the first "mvn install" completes.
This is very inconvenient. However fixing such problems as well would
cause that not only the modules are added to the reactor but that the actual mvn call
is also applied to the dependend modules that are in the reactor.
This specific issue might need some extra discussion...

For reasons of compatibility the suggested improvement could/should be
activated by a specific commandline option (somehow the opposite of "-N").
A suggestion would be "-R" for reactor and recursive.

Issue Links

duplicates

New Feature - A new feature of the product, which has yet to be developed. MNG-2576 Make Like Reactor Mode

  • 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
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Jörg Hohwiller added a comment - 16/May/09 4:55 PM

Eigther no duplicate or NOT working (see MNG-2576)!

Show
Jörg Hohwiller added a comment - 16/May/09 4:55 PM Eigther no duplicate or NOT working (see MNG-2576)!
Hide
Permalink
Jörg Hohwiller added a comment - 18/May/09 2:19 PM

This is definitely no duplicate.
My suggestion was to put all projects starting from toplevel-pom into the so called reactor but not in order to execute them but just to have them available for the plugins. I can NOT easily tell if this fits into mavens architecture at all after I understood what has been done in MNG-2576.
However this is more how I am working. I "cd" to some module and maybe look at target/surefire-report or edit pom.xml.
Then I would not typically "cd" back to toplevel and then do some strange mvn command with the path to where I have been before as argument but rather call mvn in the place where I am in order to build that module.

Show
Jörg Hohwiller added a comment - 18/May/09 2:19 PM This is definitely no duplicate. My suggestion was to put all projects starting from toplevel-pom into the so called reactor but not in order to execute them but just to have them available for the plugins. I can NOT easily tell if this fits into mavens architecture at all after I understood what has been done in MNG-2576. However this is more how I am working. I "cd" to some module and maybe look at target/surefire-report or edit pom.xml. Then I would not typically "cd" back to toplevel and then do some strange mvn command with the path to where I have been before as argument but rather call mvn in the place where I am in order to build that module.
Hide
Permalink
Jörg Hohwiller added a comment - 18/May/09 2:29 PM

Please note that "mvn eclipse:eclipse" was just a stupid example.
Also see:
http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance

To think about this even further (but not what this issue is about), ask what's first maven users typical experience:
You do "mvn install" on some module. Then maven starts working and says "oh, I need <foo> to be installed first".
Then you "cd" around to <foo> and do "mvn install" and maven says "oh, I need <bar> to be installed first".
In the end the users says "hey, why do I have to do all this, if maven has all information available in my POMs?
With the suggested option maven at least would have all these modules available in reactor (or however you would call it, if that is reserved for what has to be strictly executed). Then it would be just a little more step to go so the example
just given could be solved. However this can already be done with "--also-make-dependents" but maybe not in a way
that users typically work.

Show
Jörg Hohwiller added a comment - 18/May/09 2:29 PM Please note that "mvn eclipse:eclipse" was just a stupid example. Also see: http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance To think about this even further (but not what this issue is about), ask what's first maven users typical experience: You do "mvn install" on some module. Then maven starts working and says "oh, I need <foo> to be installed first". Then you "cd" around to <foo> and do "mvn install" and maven says "oh, I need <bar> to be installed first". In the end the users says "hey, why do I have to do all this, if maven has all information available in my POMs? With the suggested option maven at least would have all these modules available in reactor (or however you would call it, if that is reserved for what has to be strictly executed). Then it would be just a little more step to go so the example just given could be solved. However this can already be done with "--also-make-dependents" but maybe not in a way that users typically work.
Hide
Permalink
C Roskelley added a comment - 30/May/09 5:58 AM

I'm new to maven, and the last comment by Jörg is exactly how I feel. I was really excited about -pl, -am and -amd, but it doesn't work easily for a user. Obviously there is some benefit, but the user still ends up cd'ing all over and then running a mvn command and eventually going back to the module that was being targeted. It seems like this should fit really well into mvn's architecture and make it easy for someone working on multi-module project.

Show
C Roskelley added a comment - 30/May/09 5:58 AM I'm new to maven, and the last comment by Jörg is exactly how I feel. I was really excited about -pl, -am and -amd, but it doesn't work easily for a user. Obviously there is some benefit, but the user still ends up cd'ing all over and then running a mvn command and eventually going back to the module that was being targeted. It seems like this should fit really well into mvn's architecture and make it easy for someone working on multi-module project.
Hide
Permalink
Jörg Hohwiller added a comment - 03/Jun/09 12:36 AM

After getting deeper into maven, I now understand that there is a problem:
In case of an @aggregator Mojo, maven gives away the control which project to process and delegates it to the Mojo. This finally means that an @aggregator Mojo would NOT work as expected when using this feature.
I do NOT want to start the discussion whether this was a misleading design decision or not.
However this initial issue does NOT make sense and the intention might be addressed by MNG-2675.

Show
Jörg Hohwiller added a comment - 03/Jun/09 12:36 AM After getting deeper into maven, I now understand that there is a problem: In case of an @aggregator Mojo, maven gives away the control which project to process and delegates it to the Mojo. This finally means that an @aggregator Mojo would NOT work as expected when using this feature. I do NOT want to start the discussion whether this was a misleading design decision or not. However this initial issue does NOT make sense and the intention might be addressed by MNG-2675.
Hide
Permalink
Jörg Hohwiller added a comment - 24/Jul/09 2:41 PM

Could someone close this issue with resolution INVALID (I have no such permission).
After all this ticket seems to make no sense because breaking compatibility with various plugins makes the feature useless.
For my 3. comment (18/May/09 02:29 PM) I will better find a new ticket.

Show
Jörg Hohwiller added a comment - 24/Jul/09 2:41 PM Could someone close this issue with resolution INVALID (I have no such permission). After all this ticket seems to make no sense because breaking compatibility with various plugins makes the feature useless. For my 3. comment (18/May/09 02:29 PM) I will better find a new ticket.
Hide
Permalink
Jörg Hohwiller added a comment - 24/Jul/09 2:53 PM

Filed MNG-4258.

Show
Jörg Hohwiller added a comment - 24/Jul/09 2:53 PM Filed MNG-4258.
Hide
Permalink
Jörg Hohwiller added a comment - 24/Jul/09 2:53 PM

okay, closed.

Show
Jörg Hohwiller added a comment - 24/Jul/09 2:53 PM okay, closed.

People

  • Assignee:
    Unassigned
    Reporter:
    Jörg Hohwiller
Vote (1)
Watch (1)

Dates

  • Created:
    25/Jan/08 5:07 PM
    Updated:
    24/Jul/09 2:53 PM
    Resolved:
    24/Jul/09 2:53 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.