You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Benson Margulies (JIRA)" <ji...@codehaus.org> on 2011/02/19 21:34:22 UTC

[jira] Created: (MNG-5018) Do not allow properties in current reactor to change dependencies of artifacts from repositories

Do not allow properties in current reactor to change dependencies of artifacts from repositories
------------------------------------------------------------------------------------------------

                 Key: MNG-5018
                 URL: http://jira.codehaus.org/browse/MNG-5018
             Project: Maven 2 & 3
          Issue Type: Improvement
          Components: Dependencies
    Affects Versions: 3.0.2
            Reporter: Benson Margulies


I've been bitten quite a few times by the following scenario:

1. Someone creates a POM that uses a property to coordinate dependencies of related artifacts. For example, they might choose the property 'jetty.version'. 

2. Ignorant of this, I choose the same property for a different purpose. For example, the item from (#1) might be using jetty6, and I might be be using jetty7. They have different group and artifact ids.

3. My property value overrides their property value in dependency resolution.

4. If I'm lucky, 'dependency not found'. If I'm unlucky, an incompatible version gets dragged in.

Note: This is not a case of real version management. the pom from #1 and the pom from #2 use completely different G+A: It's only V that gets tangled by the property name collision.

My opinion is that a POM coming from a repo should be immune to property override. It's bad modularity that i can reach inside and change it's behavior, and very surprising that it happens accidentally.

-- 
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

        

[jira] Closed: (MNG-5018) Do not allow properties in current reactor to change dependencies of artifacts from repositories

Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/MNG-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Bentmann closed MNG-5018.
----------------------------------

    Resolution: Incomplete
      Assignee: Benjamin Bentmann

>From the short description, this sounds like a dup of MNG-4913. So either the "affect version" was wrongly set or this report misses the required details to isolate the faulty code path. So please double check the Maven version or provide a concrete project that demonstrates the issue.

> Do not allow properties in current reactor to change dependencies of artifacts from repositories
> ------------------------------------------------------------------------------------------------
>
>                 Key: MNG-5018
>                 URL: http://jira.codehaus.org/browse/MNG-5018
>             Project: Maven 2 & 3
>          Issue Type: Improvement
>          Components: Dependencies
>    Affects Versions: 3.0.2
>            Reporter: Benson Margulies
>            Assignee: Benjamin Bentmann
>
> I've been bitten quite a few times by the following scenario:
> 1. Someone creates a POM that uses a property to coordinate dependencies of related artifacts. For example, they might choose the property 'jetty.version'. 
> 2. Ignorant of this, I choose the same property for a different purpose. For example, the item from (#1) might be using jetty6, and I might be be using jetty7. They have different group and artifact ids.
> 3. My property value overrides their property value in dependency resolution.
> 4. If I'm lucky, 'dependency not found'. If I'm unlucky, an incompatible version gets dragged in.
> Note: This is not a case of real version management. the pom from #1 and the pom from #2 use completely different G+A: It's only V that gets tangled by the property name collision.
> My opinion is that a POM coming from a repo should be immune to property override. It's bad modularity that i can reach inside and change it's behavior, and very surprising that it happens accidentally.

-- 
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

        

[jira] Commented: (MNG-5018) Do not allow properties in current reactor to change dependencies of artifacts from repositories

Posted by "Benson Margulies (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MNG-5018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=256936#action_256936 ] 

Benson Margulies commented on MNG-5018:
---------------------------------------

I searched, but I didn't find, MNG-4913. I had no idea that this was considered a bug, let along a fixed bug.

I'll set up a test case and see if it indeed still behaves this way.

> Do not allow properties in current reactor to change dependencies of artifacts from repositories
> ------------------------------------------------------------------------------------------------
>
>                 Key: MNG-5018
>                 URL: http://jira.codehaus.org/browse/MNG-5018
>             Project: Maven 2 & 3
>          Issue Type: Improvement
>          Components: Dependencies
>    Affects Versions: 3.0.2
>            Reporter: Benson Margulies
>            Assignee: Benjamin Bentmann
>
> I've been bitten quite a few times by the following scenario:
> 1. Someone creates a POM that uses a property to coordinate dependencies of related artifacts. For example, they might choose the property 'jetty.version'. 
> 2. Ignorant of this, I choose the same property for a different purpose. For example, the item from (#1) might be using jetty6, and I might be be using jetty7. They have different group and artifact ids.
> 3. My property value overrides their property value in dependency resolution.
> 4. If I'm lucky, 'dependency not found'. If I'm unlucky, an incompatible version gets dragged in.
> Note: This is not a case of real version management. the pom from #1 and the pom from #2 use completely different G+A: It's only V that gets tangled by the property name collision.
> My opinion is that a POM coming from a repo should be immune to property override. It's bad modularity that i can reach inside and change it's behavior, and very surprising that it happens accidentally.

-- 
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