Fabrice Pipart created MNG-5982:
-----------------------------------
Summary: 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
dependency import
|
{code}
But in a nutshell, here is my pom:
{code:xml}
<groupId>test.properties</groupId>
<artifactId>buildme</artifactId>
<version>1.0-SNAPSHOT</version>
...
<dependencies>
<dependency>
<groupId>test.properties.installme</groupId>
<artifactId>module</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
</dependency>
</dependencies>
{code}
And I depend on a pom that looks like this (not under my control)
{code:xml}
<groupId>test.properties.installme</groupId>
<artifactId>module</artifactId>
<version>1.0-SNAPSHOT</version>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>test.properties.installme</groupId>
<artifactId>dependency</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
</dependencies>
{code}
and the problem lies in this last pom (not under my control again):
{code:xml}
<modelVersion>4.0.0</modelVersion>
<groupId>test.properties.installme</groupId>
<artifactId>dependency</artifactId>
<version>1.0-SNAPSHOT</version>
...
<properties>
<com.sun.tools.path>D:/java/jdk1.8.0_65/lib/tools.jar</com.sun.tools.path>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.8</version>
<scope>system</scope>
<systemPath>${com.sun.tools.path}</systemPath>
</dependency>
</dependencies>
</dependencyManagement>
{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 <groupId>:<artifactId>:jar:<version> 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)
