2

I have a main project and a commons project which has a dependency that is not in any repository and needs to be included using <scope>system</scope>.

Because the system dependency is defined using a relative url using a maven property ${project.basedir}, I made it <optional>true</optional> so that it doesn't bother other projects and so depending projects need to redefine this dependency with the correct path.

Commons pom.xml:

<dependency>
    <groupId>thirdparty-group</groupId>
    <artifactId>artifact</artifactId>
    <version>1.4.2</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/dependency.jar</systemPath>
    <optional>true</optional>
</dependency>

In main project's pom:

<dependency>
    <groupId>my-group</groupId>
    <artifactId>commons</artifactId>
    <version>1.0-SNAPSHOT</version>
    <scope>compile</scope>
</dependency>

<dependency>
    <groupId>thirdparty-group</groupId>
    <artifactId>artifact</artifactId>
    <version>1.4.2</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/dependency.jar</systemPath>
</dependency>

Obviously dependency.jar is in both the commons and main project.

The commons jar installs properly without a hitch. But when used in the main project however, the result is:

[WARNING] The POM for my-group:commons:jar:1.0-SNAPSHOT is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for my-group:commons:1.0-SNAPSHOT

[ERROR] 'dependencies.dependency.systemPath' for thirdparty-group:artifact:jar must specify an absolute path but is ${project.basedir}/lib/dependency.jar @

The build continues, but transitive runtime dependencies are now excluded breaking the application.

Why is maven complaining about a dependency from commons that is not even relevant to the main project (as it is optional, why is it even included as transitive dependency)? How to work around this problem?

Putting the system dependency in the repo is not an option unfortunately.

Benny Bottema
  • 11,111
  • 10
  • 71
  • 96
  • The simplest solution for such problems is simply install a repository manager and install such kind of artifacts there. And you are fine...No need to define system scoped dependencies... – khmarbaise Aug 11 '16 at 18:38

1 Answers1

2

Going by @PascalThivent's excellent answer, I worked around the issue by defining a local repo inside the commons project, and then changing the scope to compile with <optional>true</optional>.

In commons pom.xml:

<dependencies>
    <dependency>
        <groupId>thirdparty-group</groupId>
        <artifactId>artifact</artifactId>
        <version>0.0.1</version>
        <scope>compile</scope>
        <optional>true</optional>
    </dependency>
</dependencies>

<repositories>
    <repository>
        <id>local-repo</id>
        <url>file://${basedir}/lib/local-repo</url>
    </repository>
</repositories>

To install the library:

mvn org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file \
             -Dfile=./lib/dependency.jar \ 
             -DgroupId=thirdparty-group \ 
             -DartifactId=artifact \ 
             -Dversion=0.0.1 \
             -Dpackaging=jar \
             -DlocalRepositoryPath=.\lib\local-repo

I can just commit this to the VCS directly so other developers don't have to do this every time on checkout.

In the main project's pom.xml nothing changes. It can still use its own system dependency, or go this approach as well. Both approaches work for the WAR file that comes out there...

Community
  • 1
  • 1
Benny Bottema
  • 11,111
  • 10
  • 71
  • 96