[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-5982:
-
Fix Version/s: (was: 4.0.0-alpha-1)
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Assignee: Michael Osipov
>Priority: Minor
> Labels: needs-attention
> Fix For: 3.8.5, 4.0.0-alpha-2, 4.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-5982:
-
Fix Version/s: 4.0.0-alpha-2
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Assignee: Michael Osipov
>Priority: Minor
> Labels: needs-attention
> Fix For: 3.8.5, 4.0.0-alpha-1, 4.0.0-alpha-2, 4.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5982:
Labels: needs-attention (was: must-be-in-4.0.0-alpha-1 needs-attention)
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Assignee: Michael Osipov
>Priority: Minor
> Labels: needs-attention
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5982:
Fix Version/s: 3.8.x-candidate
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Priority: Minor
> Labels: must-be-in-4.0.0-alpha-1, needs-attention
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5982:
Labels: must-be-in-4.0.0-alpha-1 needs-attention (was: needs-attention)
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Priority: Minor
> Labels: must-be-in-4.0.0-alpha-1, needs-attention
> Fix For: 4.0.x-candidate
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-5982:
--
Fix Version/s: (was: 3.7.0-candidate)
3.7.x-candidate
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Labels: needs-attention
> Fix For: 3.7.x-candidate
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-5982:
--
Fix Version/s: 3.7.0-candidate
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Labels: needs-attention
> Fix For: 3.7.0-candidate
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MNG-5982:
---
Priority: Minor (was: Major)
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Priority: Minor
> Labels: needs-attention
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MNG-5982:
---
Labels: needs-attention (was: )
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>Priority: Major
> Labels: needs-attention
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabrice Pipart updated MNG-5982:
Affects Version/s: 3.0
Component/s: POM
Inheritance and Interpolation
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 3.0, 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5982) The POM for ... is invalid, transitive dependencies ... while property was overriden
[
https://issues.apache.org/jira/browse/MNG-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabrice Pipart updated MNG-5982:
Summary: The POM for ... is invalid, transitive dependencies ... while
property was overriden (was: The POM for ... is invalid, transitive
dependencies .. while property was overriden)
> The POM for ... is invalid, transitive dependencies ... while property was
> overriden
>
>
> Key: MNG-5982
> URL: https://issues.apache.org/jira/browse/MNG-5982
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.9
> Environment: Linux and Mac
>Reporter: Fabrice Pipart
>
> I experienced issues with a maven build that does not behave the same way if
> done on Windows (like they were done in the past) or Linux (like I want to do
> them now).
> I want to build a project that has a dependency on another project that pom
> that itself imports a pom that contains a Windows path.
> {code:xml}
>my project | other project
> |
> mybuild ---|--> pom > pom with systemPath
> dependencyimport
> |
> {code}
> But in a nutshell, here is my pom:
> {code:xml}
> test.properties
> buildme
> 1.0-SNAPSHOT
> ...
>
>
> test.properties.installme
> module
> 1.0-SNAPSHOT
> pom
>
>
> {code}
> And I depend on a pom that looks like this (not under my control)
> {code:xml}
> test.properties.installme
> module
> 1.0-SNAPSHOT
> ...
>
>
>
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> import
> pom
>
>
>
>
>
> log4j
> log4j
> 1.2.17
>
>
> {code}
> and the problem lies in this last pom (not under my control again):
> {code:xml}
> 4.0.0
> test.properties.installme
> dependency
> 1.0-SNAPSHOT
> ...
>
> D:/java/jdk1.8.0_65/lib/tools.jar
>
>
>
>
> com.sun
> tools
> 1.8
> system
> ${com.sun.tools.path}
>
>
>
> {code}
> I have no control on the other project in question. I totally agree that a
> refactoring to use environment variable in place of the hard coded paths
> would solve my problem. But instead the Windows path is defined in a
> property. *One would think that overriding the value of the property
> depending on my platform would be enough.* But it is not.
> Unfortunately in this precise case case maven seems to behave to behave
> poorly.
> Before applying any property override in any form (in settings.xml,
> -Dproperty=, redefinition in root pom), maven starts building the effective
> pom. And during that step, if it finds the pattern I mentioned above (a
> dependency on another pom that itself imports a pom that contains a Windows
> path), then it says:
> {code:xml}
> The POM for ::jar: is invalid, transitive
> dependencies (if any) will not be available
> {code}
> As a consequence, my project needs to explicitly define all the dependencies
> of the second project. And I cannot rely on transitive dependencies which
> gives me a lot of trouble.
> In order to illustrate the issue, I created a minimal example showing the
> problem. It can be found here:
> [https://github.com/fabricepipart/test-properties]
> Can you confirm this is a bug from maven?
> I tested with several versions of maven. 3.0 up to a 3.3.9 I think.
> The issue remains the same. It is all a matter of redefining the value of the
> property based on the environment. If I *launch maven with
> -Dcom.sun.tools.path=/correct/linux/path*, globally my build is fine. Because
> when the classes are compiled, it is the *overriden Linux path that is
> taken*, not the Windows one.
> But during the *initial evaluation of the pom*(before any maven phase is
> started), the error I mentioned above is thrown because the *value of the
> property is still the Windows one* (and the path is considered invalid).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
