Command line -f option should propagate to module poms.

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Command Line
  • Labels:
    None

Description

I have a multi module project where I would like to have parrallel builds. The default pom.xml build would be using jdk1.5 or jdk6, and the parrallel build pom would be for creating retro compiled jdk14 artifacts. So the pom for this build would be "pom-jdk14.xml". I've explored other options such as using a classifier for the retro translated artifact, and using profiles to choose between jdk1.5 and jdk1.4 builds. But both of these have problems that I can't get around without a lot of difficulty.

Using two separate poms works great for me for a single module project, but for a multi module project, I have no way to tell the modules to pick up a different pom.xml file.

So for my multi module build I would like to be able to say
mvn -f pom-jdk14.xml install

And each module should then look for it's own pom-jdk14.xml. This could be made into the default behaviour of the "-f" option, or a new option could be introduced like "-fg" to use the other pom file globally across all the module.

Issue Links

is superceded by

Improvement - An improvement or enhancement to an existing feature or task. MNG-1493 Support in multiproject environment modules with different named POMs

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • 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
Hide
Permalink
Paul Gier added a comment -

Adding patch to look for alternate pom files when the -f option is specified. Also, the system property "alternate.pom.file" can be used to specify alternate pom files.

Show
Paul Gier added a comment - Adding patch to look for alternate pom files when the -f option is specified. Also, the system property "alternate.pom.file" can be used to specify alternate pom files.
Hide
Permalink
Arik Kfir added a comment -

Why not use profiles for this?

Show
Arik Kfir added a comment - Why not use profiles for this?
Hide
Permalink
Paul Gier added a comment - - edited

I tried using profiles initially, but it started becoming very complicated.
The difficult requirement is that I want transitive dependencies to work, so this means that I can't just do something like build an additional artifact with a -jdk14 classifier. I need two separate artifacts with two different sets of dependencies, jdk1.5 and jdk1.4.
So getting transitive dependencies to work correctly means that I really need two separate artifactIds and two separate sets of dependencies. So I tried to use a profile to create two artifactIds from the same pom. This means I had something like
<artifactId>my-project${artifactClassifier}</artifactId>
Then I need to put all of my dependencies for the default build and the jdk1.4 build into two separate profiles. The only exception is the dependencies that are already jdk1.4 compatibly like junit and a few others, those can go in the regular dependency section. However, most of the dependencies, like the inter-module stuff and dependencies on other jboss projects, would have to be in a profile like this:

<profiles>
  <profile>
    <id>jdk15</id>
    <dependencies>
       ...
    </dependencies>
  </profile>
  
  <profile>
    <id>jdk14</id>
    <dependencies>
       ...
    </dependencies>
  </profile>

<profiles>

The main problem with this is that in order to use the jdk14 artifact, outside projects will have to make sure that they activate the correct profiles throughout the dependency tree or they will get the wrong dependencies.
If the profile is activated by id (-P jdk14), then the matching profile in the dependency is not automatically enabled. A property could be used to activate profiles in the dependency poms, but it can be difficult to enforce the same property in each project. And if different properties are used,
then the poms in the dependency tree will have to be searched for the correct properties to activate each of the correct profiles.

Show
Paul Gier added a comment - - edited I tried using profiles initially, but it started becoming very complicated. The difficult requirement is that I want transitive dependencies to work, so this means that I can't just do something like build an additional artifact with a -jdk14 classifier. I need two separate artifacts with two different sets of dependencies, jdk1.5 and jdk1.4. So getting transitive dependencies to work correctly means that I really need two separate artifactIds and two separate sets of dependencies. So I tried to use a profile to create two artifactIds from the same pom. This means I had something like <artifactId>my-project${artifactClassifier}</artifactId> Then I need to put all of my dependencies for the default build and the jdk1.4 build into two separate profiles. The only exception is the dependencies that are already jdk1.4 compatibly like junit and a few others, those can go in the regular dependency section. However, most of the dependencies, like the inter-module stuff and dependencies on other jboss projects, would have to be in a profile like this: 
<profiles>
  <profile>
    <id>jdk15</id>
    <dependencies>
       ...
    </dependencies>
  </profile>
  
  <profile>
    <id>jdk14</id>
    <dependencies>
       ...
    </dependencies>
  </profile>

<profiles>
The main problem with this is that in order to use the jdk14 artifact, outside projects will have to make sure that they activate the correct profiles throughout the dependency tree or they will get the wrong dependencies. If the profile is activated by id (-P jdk14), then the matching profile in the dependency is not automatically enabled. A property could be used to activate profiles in the dependency poms, but it can be difficult to enforce the same property in each project. And if different properties are used, then the poms in the dependency tree will have to be searched for the correct properties to activate each of the correct profiles.
Hide
Permalink
Dave Syer added a comment -

I also think alternate poms in reactor builds would be very useful. In my case I need to build and deploy the same artifacts with different artifactIds to different repositories. I can't see how this is possible with profiles.

Show
Dave Syer added a comment - I also think alternate poms in reactor builds would be very useful. In my case I need to build and deploy the same artifacts with different artifactIds to different repositories. I can't see how this is possible with profiles.
Hide
Permalink
Benjamin Bentmann added a comment -

Paul, are you aware that as of MNG-1493, the <module> element in the POM can not only point at a directory but also at a POM file? Wouldn't that solve your problem, by having a pom-jdk14.xml POM refer to its children via <module>child/pom-jdk14.xml</module>?

Show
Benjamin Bentmann added a comment - Paul, are you aware that as of MNG-1493, the <module> element in the POM can not only point at a directory but also at a POM file? Wouldn't that solve your problem, by having a pom-jdk14.xml POM refer to its children via <module>child/pom-jdk14.xml</module>?
Hide
Permalink
Benjamin Bentmann added a comment -

Superseded by MNG-1493.

Show
Benjamin Bentmann added a comment - Superseded by MNG-1493.

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Paul Gier
Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: