Maven
  1. Maven
  2. MNG-3377

Build reactor from toplevel pom

    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
    • Number of attachments :
      0

      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

          Activity

          Hide
          Jörg Hohwiller added a comment -

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

          Show
          Jörg Hohwiller added a comment - Eigther no duplicate or NOT working (see MNG-2576 )!
          Hide
          Jörg Hohwiller added a comment -

          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 - 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
          Jörg Hohwiller added a comment -

          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 - 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
          C Roskelley added a comment -

          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 - 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
          Jörg Hohwiller added a comment -

          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 - 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
          Jörg Hohwiller added a comment -

          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 - 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
          Jörg Hohwiller added a comment -

          Filed MNG-4258.

          Show
          Jörg Hohwiller added a comment - Filed MNG-4258 .
          Hide
          Jörg Hohwiller added a comment -

          okay, closed.

          Show
          Jörg Hohwiller added a comment - okay, closed.

            People

            • Assignee:
              Unassigned
              Reporter:
              Jörg Hohwiller
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: