0

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.

   my project   |           other project
                |
mybuild  -------|------> pom --------> pom with systemPath
            dependency        import
                |

But in a nutshell, here is my pom:

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

And I depend on a pom that looks like this (not under my control)

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

and the problem lies in this last pom (not under my control):

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

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:

The POM for <groupId>:<artifactId>:jar:<version> is invalid, transitive dependencies (if any) will not be available

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

Do you see any workaround for this? Any way to override the value of the property and still benefit from the maven transitive dependencies?

Thanks a lot

  • Can't test this right now on a Linux box but are you sure the Maven version is the same? – Tunaki Feb 19 '16 at 17:15
  • Yes I tested with several versions of maven. 3.0 up to a 3.3.9 I think. The issue (bug?) 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 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). – Fabrice Pipart Feb 20 '16 at 11:01
  • Maybe it would be better to file a bug report at the [Maven JIRA](https://issues.apache.org/jira/browse/MNG). You seem to have tested this quite thoroughly ;). – Tunaki Feb 20 '16 at 12:34
  • This is an option. I was here looking for an opinion whether it is normal or not. I could definitely be wrong thinking it is not the correct behavior. I was also asking here to know if one could think of a workaround. But you are right, I'll fill a bug report in parallel. – Fabrice Pipart Feb 20 '16 at 12:58

0 Answers0