You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Paul Gier (JIRA)" <ji...@codehaus.org> on 2009/07/10 18:03:23 UTC

[jira] Issue Comment Edited: (MNG-3150) Command line -f option should propagate to module poms.

    [ http://jira.codehaus.org/browse/MNG-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=106957#action_106957 ] 

Paul Gier edited comment on MNG-3150 at 7/10/09 11:01 AM:
----------------------------------------------------------

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:
{code:xml}
<profiles>
  <profile>
    <id>jdk15</id>
    <dependencies>
       ...
    </dependencies>
  </profile>
  
  <profile>
    <id>jdk14</id>
    <dependencies>
       ...
    </dependencies>
  </profile>

<profiles>
{code}
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.



      was (Author: pgier):
    
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.


  
> Command line -f option should propagate to module poms.
> -------------------------------------------------------
>
>                 Key: MNG-3150
>                 URL: http://jira.codehaus.org/browse/MNG-3150
>             Project: Maven 2
>          Issue Type: Improvement
>          Components: Command Line
>            Reporter: Paul Gier
>             Fix For: 3.x
>
>         Attachments: MNG-3150-maven-core-r573613.patch
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira