Links to Maven dependencies based on <scm> metadata in JAR's pom.xml

[Przemyslaw Czuj]

I use Linky only for quickly sharing links to the source code of various repositories. I’m usually disappointed when I end up in some dependency code and I can’t simply copy a link using the context menu.

Technically the operation I need to do to navigate to the dependency source code should be possible to automate. JAR files build by Maven contain pom.xml which when translated to the effective pom should contain <scm> tag with <url> to the source code.

It may not be simple to create a link pointing to a revision of a specific version, however even link to a default branch would greatly help in saving a lot of manual work.

[Daniil Penkin]

Hey @Przemyslaw Czuj ,

Thanks for reaching out and bringing up this idea!

I can totally understand the use case you are describing. Linky indeed does nothing to any code that is outside of any of the local repositories in the current IDE project. And at the moment Linky is agnostic to the repository content: it only needs to know SCM metadata for a given file to generate Bitbucket URL for it.

Even though you’re right about scm.url property in Maven projects and artifacts it produces, I can see few issues here:

• the least important one is what you mentioned: it would be hard to link to a specific version because there’re no common rules on tagging or marking releases. But as you also said, even navigating to some version of the file might be useful.
• given a JAR with the SCM metadata in a pom.xml inside it, there’s no way to tell what was the layout of the classes in that JAR in the original repository. The easiest example would be a multi module maven project, where every module generates an artifact. So parsing scm.url from just the pom wouldn’t be enough, moreover, in this case Linky would likely need to somehow fetch the parent pom first because the module pom will likely lack SCM metadata.
• even if Linky managed to figure the right maven module, the layout of the files in a module and in a JAR it produces might be irrelevant. src/main/<lang> is just a convention, not a rule. So Linky would need to parse another bit from the pom.xml to be able to generate the right link – source directories.
• classes generated during compilation are another problem: they don’t exist in the original repository at all. So, unlike the current state of things where Linky’s actions appear only for the files it can surely generate a link for, with the new functionality Linky would never know in advance if building a link is possible for a given file, so such action in the context menu might be confusing.
• finally, pom.xml might be generated not by maven, and this complicates things even more. For example, gradle can bake pom.xml into the artifacts, but the repository layout will have nothing in common with maven.

All these things together sound like adding a lot of complexity, and the outcome of that new logic is far from covering all of the use cases.

I can think of two potential work arounds for some of these problems, but obviously they are both limited and not ideal:

1. Make use of Code Search in Bitbucket. Once we know the URL of the original repository, we can search for a given file by its name and maybe path in the JAR to try narrow down the results. But again, a repo can contain multiple files with the same name and even path in many places of the repository. Obviously, link constructing will require some API calls in this case, so it’s gonna be slow.
2. Similar thing but use other local repositories. If, say, you have a library somewhere else on a disk and you ever opened it in the IDE, we can keep track of it. And when you happen ti generate a link for a JAR that was generated from that library, we can try using local search instead of calling out to Bitbucket. Two problems here: we couldn’t use any of IDE’s functionality to work with that other repository, and it might be horribly out of sync with its upstream repository.

All in all, even though I really like your idea in theory, I can’t figure any feasible practical way to implement it. If you have any other ideas of how the problems I described can be approached, please share them.

Cheers,
Daniil

‌

[Przemyslaw Czuj]

Thanks a lot for reading my suggestion and for a quick and rich response! And obviously thanks for creating Linky - it really helps when discussing the code with others and documenting solutions.

I didn’t think before about the issues you described. It sounds like the solution is not really as simple as I thought to point to a specificc source file.

The potential workaround 1. you described seems like a very interesting idea. Maybe it could be even a bit simpler and it would only create a link to the repository - without locating the file. Creating a link to just a search query would also be useful though.

[Daniil Penkin]

Thanks for your kind words I’m happy that Linky provides real value in some of your workflows.

Maybe it could be even a bit simpler and it would only create a link to the repository

Yeah that must be way easier, though I’m still not sure how much help IntelliJ can provide here vs how much logic needs to be added on top. Anyways, the idea sounds interesting and I can imagine the use case, so I’ll see what I can do here.