3 ms·

Couple this to the fact that you can search for the class at https://search.maven.org/#browse https://search.maven.org/#browse to find the artifact hosting it

Couple this to the fact that you can search for the class at https://search.maven.org/#browse https://search.maven.org/#browse to find the artifact hosting it, and it tends to be a couple minute job Bonus tracks: gradle dependencyInsight is great for a similar task: finding out which artifact is bringing the dep.

village-idiot 8y ago
That’s all fine and well if you have one or two broken dependencies from big popular libraries. This technique does not scale if you have a few dozen internal libraries and a few hundred internally deployed artifacts, or more. At that scale you need a more automated solution.
- bassman9000 8y ago
  Anecdote: we have a large codebase with probably 100+ 3rd party dependencies, and dozens of internal modules, and that technique works pretty well. Besides, where's the automated part on the OP solution? I agree the automation, either with this tool, or vanilla project management ones like gradle, could be beneficial.
  - village-idiot 8y ago
    I can’t speak to gradle, since we don’t use it, but none of the other tools I’ve touched look at ABI compatibility. It’s pretty easy to tell who brought in whatever version after it’s crashed, but catching that in advance is much much harder.
voodootrucker 8y ago
To the parent and GP, this is a problem in large code bases. As soon as you bring in a high level dependency like Spring, Spark, or DropWizard the graph goes 20+ levels deep and manual resolution becomes difficult. Build tools do their best. Gradle has a reasonably sane version based solution. By statically analyzing the method invocations (and eventually properties too), this tool could (one day) just tell you the versions to use that would be most likely to work. The long term vision would be to actually incorporate this as a dependency resolution strategy in Gradle so you don't have to think at all.

village-idiot 8y ago

That’s all fine and well if you have one or two broken dependencies from big popular libraries. This technique does not scale if you have a few dozen internal libraries and a few hundred internally deployed artifacts, or more. At that scale you need a more automated solution.

bassman9000 8y ago
Anecdote: we have a large codebase with probably 100+ 3rd party dependencies, and dozens of internal modules, and that technique works pretty well. Besides, where's the automated part on the OP solution? I agree the automation, either with this tool, or vanilla project management ones like gradle, could be beneficial.
- village-idiot 8y ago
  I can’t speak to gradle, since we don’t use it, but none of the other tools I’ve touched look at ABI compatibility. It’s pretty easy to tell who brought in whatever version after it’s crashed, but catching that in advance is much much harder.

voodootrucker 8y ago

To the parent and GP, this is a problem in large code bases. As soon as you bring in a high level dependency like Spring, Spark, or DropWizard the graph goes 20+ levels deep and manual resolution becomes difficult. Build tools do their best. Gradle has a reasonably sane version based solution. By statically analyzing the method invocations (and eventually properties too), this tool could (one day) just tell you the versions to use that would be most likely to work. The long term vision would be to actually incorporate this as a dependency resolution strategy in Gradle so you don't have to think at all.