1

Edit: "Reverse Dependency analysis" would have been the keyword for what i searched - unfortunately I was not able to proper describe my question (maybe it has something to do with this not beeing a standard thing - i acctually dont even have a real usecase for this).

Say i have a typical convergence issue and the dependency:tree tells me something like this:

[INFO] com.my.group:myProject:jar:1.0.1 [INFO] +- org.not.my.group:a-direct-dependency:jar:1.1:compile [INFO] | \- org.not.my.group:transitive-dependency-A:jar:1.14.0:compile [INFO] \- org.not.my.group:another-direct-dependency:jar:1.1:compile [INFO] \- (org.not.my.group:transitive-dependency-A:jar:1.18.0:compile - omitted for conflict with 1.14.0)

is there a way to analyze a central repository (with nexus webgui available as well) to find out if there is a (newer) version of org.not.my.group:a-direct-dependency:jar that relies on the transitive dependency org.not.my.group:transitive-dependency-A:jar but in version 1.18.0 instead of 1.14.0?

Or generally asked: Can i find out who is depending on a artifact via the central repository (or any remote repository) similar as i would find it out using this locally?:

mvn dependency:tree -Dincludes=org.not.my.group:transitive-dependency-A:jar:1.18.0 -Dverbose

For further clarification: In the above (fictive) szenario i would solve the convergence issue using three "levels" of solutions whereas the first will whenever possible be the choice and the latest is "a dirty correction".

1 - Allign versions: If my dependencies - own or third party - direct or transitive - do rely on the same artifact X but define a different version i preferably try to find a newer release of X or a dependency in the tree to X that has a common version to the rest of the dependencies. This way i assume "a proper upgrade" of X because they may needed to apply code changes.

2 - exclude dependency: If i am not able to find such a artifact i will successivly try to exclude the lower versions in the hope the dependency that has this exclusion can handle the newer version. This requires intense testing since i dont have the guarantee of a newer release that properly points to the version - i basicially tell maven "this dependency will work with another dependency of version as well even thus i have no idear of the internal design of this dependency" - even if compilation works i may still experience runtime issues.

3 - use dependencyManagement: Since using the dependencyManagement can lead to "mask" (hide/outpass) certain convergence issues for the enforcer plugin i acctually dont consider this a solution (for my setup) anymore .... say i experienced a convergence issue and solved it using the dependencyManagement - later - one of the transitive dependencies changes and lead to a similar convergence issue that the enforcer plugin is not able to detect anymore.

Side-Note: I wish my English would be better so it would be easier for me to describe such specific topics ... and in the end easier for you guys to understand me. Thanks for the input i already received :)

JBA
  • 2,769
  • 5
  • 24
  • 40
  • explicit used dependencies should be explicitly declared and not use the transitive ones thus you should exclude those completely and not try to find a way to import newer transitive dependencies... if I understood you well – aurelius Feb 18 '15 at 09:42
  • We are close to - since English is not my mothers tongue i may have issues understanding you and the documentations. I totally agree in having the dependencies declared specificly and use the enforcer-plugin. – JBA Feb 18 '15 at 10:27
  • But say a third party artefact declared as a direct dependency brings up a "old/older" version of a transitive dependency and i dont want to just "force" it to have the newer version by defining the direct dependency but rather want to check if there is a newer version of the third party that possibly already uses a newer version of this transitive dependency (because they had to change their source to be compatible with the newer version). – JBA Feb 18 '15 at 10:31
  • In that case i would want to find out if there is a (or any) artefact that relies on another specific artefact in a specific version. – JBA Feb 18 '15 at 10:34
  • I tried to clarify my question since i just used sample group-Ids that do imply all of those artifacts are under my control. (If no further input will come in i just mark the below question as accepted since it is generally appliable and way more important than the detail i am looking for) – JBA Feb 18 '15 at 14:55

2 Answers2

3

First as already mentioned define those dependencies which are used directly instead of relying on the transitive dependencies.

Furthermore i would use maven-enforcer-plugin to prevent such situations.

<project>
  ...
  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>1.4</version>
        <executions>
          <execution>
            <id>enforce</id>
            <configuration>
              <rules>
                <dependencyConvergence/>
              </rules>
            </configuration>
            <goals>
              <goal>enforce</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      ...
    </plugins>
  </build>
  ...
</project>
khmarbaise
  • 92,914
  • 28
  • 189
  • 235
  • I think this is the general best approach to handle convergence issues - maybe you can give me further informations via the comments below my question. – JBA Feb 18 '15 at 10:32
  • Also note that not **I** rely on the said transitive dependency but a direct dependency of mine does so (o.k. my example is crap since anything is in the same group - sorry for that i will adjust it for further clarification) – JBA Feb 18 '15 at 14:14
1

As often my English skills were not good enoth - "Reverse dependency analysis" would have been the term to make myself clear - There are a few Plugins to archive this such as described here http://tech.finn.no/2013/01/31/i-wish-i-knew-my-consumers-maven-reverse-dependency/

JBA
  • 2,769
  • 5
  • 24
  • 40