4 ms·

This seems less linking and more dependency resolution. What was wrong with > ./gradlew dependencies and then sorting out your duplicate dependencies with im

This seems less linking and more dependency resolution. What was wrong with > ./gradlew dependencies and then sorting out your duplicate dependencies with improper version issues. I have spent a lot of time down this road myself and most of it was not fully understanding the framework dependencies, munging of stackoverflow solutions, or apache-commons hell...sometimes a little bit of it all. Not trying to crap on your hardwork but interested in your motivations if its something bigger which I am not seeing. Long term I don't think you can properly suggest the appropriate dependency, this is why most build tools provide default selection and let you override with exclude patterns. Additionally there is a linting tool that will parse through duplicates and offer to clean up your gradle files if that is interesting to you alongside your work.

bassman9000 8y ago
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.
pvorb 8y ago
I guess its called linker to make the phrase sound like "the missing link for the JVM."
oweiler 8y ago
Maven equivalent for ./gradlew dependencies: mvn dependency:tree -Dverbose or ./mvnw dependency:tree -Dverbose (if you are using the Maven wrapper)
jermo 8y ago
./gradlew dependencies will not tell you which versions play nice together.
- bunderbunder 8y ago
  Concrete example: I dealt with a dependency conflict between two different packages that wanted different versions of Apache Commons. Both of them only claimed that they wanted "greater than or equal to X version." This wasn't actually true, though, because Apache Commons had removed some features and added some features, so the real requirements were Package A wants Commons >= X and < Y Package B Commons >= Z where Z > Y. Sorting that out meant manually doing exactly what this Depends package does - poking around with different versions and using the missing method exceptions and some other research to figure out the exact nature of the conflict, so that I could pin their versions and set up appropriate package relocation rules. This tool would not just do that faster, but also more reliably - by doing it manually, I was only able to verify that I had resolved any issues with the code I actually exercised. A gap in test coverage would leave me exposed to run-time errors in production.

bassman9000 8y ago

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.

pvorb 8y ago

I guess its called linker to make the phrase sound like "the missing link for the JVM."

oweiler 8y ago

Maven equivalent for ./gradlew dependencies: mvn dependency:tree -Dverbose or ./mvnw dependency:tree -Dverbose (if you are using the Maven wrapper)

jermo 8y ago

./gradlew dependencies will not tell you which versions play nice together.

bunderbunder 8y ago
Concrete example: I dealt with a dependency conflict between two different packages that wanted different versions of Apache Commons. Both of them only claimed that they wanted "greater than or equal to X version." This wasn't actually true, though, because Apache Commons had removed some features and added some features, so the real requirements were Package A wants Commons >= X and < Y Package B Commons >= Z where Z > Y. Sorting that out meant manually doing exactly what this Depends package does - poking around with different versions and using the missing method exceptions and some other research to figure out the exact nature of the conflict, so that I could pin their versions and set up appropriate package relocation rules. This tool would not just do that faster, but also more reliably - by doing it manually, I was only able to verify that I had resolved any issues with the code I actually exercised. A gap in test coverage would leave me exposed to run-time errors in production.