0

Project A references Project B. Project B has included a local dependency. This local dependency unfortunately has a dependency to net.java.dev.designgridlayout in version 1.5.

We want to use net.java.dev.designgridlayout in version 1.11 in Project A but we are not able to "overwrite" the dependency. Eclipse always uses the dependency from Project B.

We already tried to exclude the 1.5 version from the local dependency, but it doesn't work. The strange thing is, that Eclipse successfully resolves a class that has been added with version 1.11. For an already existing class, however, eclipse resolves it from the transitive dependency from de.someCompany.

Project B:

<dependencies> <dependency> <groupId>de.someCompany</groupId> <artifactId>fs-client</artifactId> <version>5.1.209</version> <exclusions> <exclusion> <groupId>net.java.dev.designgridlayout</groupId> <artifactId>designgridlayout</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>net.java.dev.designgridlayout</groupId> <artifactId>designgridlayout</artifactId> <version>1.11</version> </dependency> </dependencies>

Project A:

<dependencies> <dependency> <groupId>Project-B</groupId> <artifactId>Project-B</artifactId> <version>1503.01</version> </dependency> </dependencies>

I also tried to include the 1.11 dependency in Project A.

We even tried to install the DesignGridLayout V. 1.11 in the local dependency and to change the groupID and artifactId to something different, but it cannot even be found by Eclipse for some reason. If it would be possible to include the DesignGridLayout with another groupId and artifactId, I think it would work.

mvn install:install-file -Dfile=lib\designgridlayout.jar -DgroupId=com.company.designgridlayout -DartifactId=design-grid-layout -Dversion=1.11 -DgeneratePom=true -Dpackaging=jar -DlocalRepositoryPath="%USERPROFILE%\.m2\repository"

Stefano L
  • 1,486
  • 2
  • 15
  • 36

1 Answers1

0

Not sure - but:

Your project A has a dependency to itself? Shouldn't it use project-b?

Its not a good idea to change group or artifact id's as maven can no longer detect its the same artifact. If you do a custom version the version number should be enough.

If you add the dependency in your own pom then you don't need to exclude the artifact, since the groupId and artifactId are the same. The version in your own pom will win in project-b. If project a defines that dependency again itself that version will win.

I would do a mvn dependency:tree on project-a pom to see where the dependencies come from.

For eclipse: it indexes the local repository. In the maven settings there is a re-index button. So if you manually copy jars in there that may help eclipse to find the artifact. But that workaround would need to be done on every machine. I would not count that as solution. In the maven world artifact-resolution is an infrastructure issue and should not be handled per project. The way this is done should be transparent through the settings.xml

wemu
  • 7,952
  • 4
  • 30
  • 59
  • alright :) - the dependency your look for in project-A is "designgridlayout"? what version does maven show for that? and where does it come from? – wemu Jan 08 '15 at 15:03