Yeah, if Maven pom does not contain a usable scm entry and here is also no project url to use, it's probably better to not link at all.

Thanks @courtneycl

In the small sample set I have there are for example more okhttp dependencies still referring to wrong repositories.
Looking at the pom file for these (like mentioned above) would point to the right github repo: https://repo1.maven.org/maven2/com/squareup/okhttp3/logging-interceptor/5.0.0-alpha.10/logging-interceptor-5.0.0-alpha.10.pom

Also for the org.jetbrains.kotlinx:kotlinx-coroutines-* not all seem to be handled yet:

Just found another incorrect one.

bloop-config 1.5.5 lives in it's own repo at https://github.com/scalacenter/bloop-config and the pom file that you can see here links to the correct repository. Currently this is just linking to itself.

@ckipp01 fixed!

Coming back to your previous qs:

I would assume that the heuristic is simply looking at these entries in the pom files?

It looks at the pom files, but it also does other things, and sometimes the other things overwrite what we've detected from the pom files. It needs some rework for sure.

Cleared (they were wrong; the source isn't listed in Maven Central):

I'm also not fully sure what you mean here. For example, here is the jsr305 artifacts on Maven Central

Sorry, I meant a GitHub-hosted source isn't listed. We currently only link packages to repos on GitHub.

So I don't really want to keep pointing these out as it seems like an incredibly inefficient way to do this, but looking at the deps in Dotty, there are a ton of them that are incorrect. Just to show a few:

Seeing that this discussion was started 8 months ago, I'm more interested in any information you might have about a roadmap for better supporting various ecosystems on GitHub since it's been quite some time that the API has been open. For example even just ignoring the incorrect links even if you submit a maven dep with another build tool that's not Maven you still see weird messages like this:

Showing that it can't find it in my pom.xml even though it clearly says right above it that it's coming from a build.sbt. Again, super happy this feature exists and I'm really looking forward to it being more usable from something besides pure java dependencies using poms. Is there any sort of public roadmap?

Ah, I also just now am seeing https://github.com/orgs/community/discussions/43364. I would love to still do this if it's a possiblity.

Thank you @jhutchings1 for looking into this, out of curiosity, are Security Advisories impacted by this? As a sample, Microsoft.ApplicationInsights.WorkerService in my repo is reporting the fork vijay10193/asp1 as the source which hasn't been updated in a little over 3 years from the actual publisher microsoft/ApplicationInsights-dotnet. If the actual source repo publishes an advisory will I be notified of it without action from vijay10193/asp1

No. We publish security advisories based on the package name/ecosystem, so that process sidesteps the package-to-repo mapping altogether. The package-to-repo mapping is purely used as a UI treatment in the dependency graph UX and we don't use that for any security conclusions.

@jhutchings1 it's been a while since the last update. Are there any plans or news you could share with us?

Hi @laughedelic -- we made some changes to our Maven repo mappings a ways back so that we'll only show mappings over a certain confidence level. This decreases the chance of having wrong mappings (though, not to zero).

We are currently working on a bulk ingestion of metadata coming from ClearlyDefined -- this is primarily for licenses, but it also includes some repo mappings, and we'll be assessing whether we can use that as a source. Otherwise, we have time dedicated for mapping improvement efforts in the summer.

Thanks for the update! It's good to know that some work is happening or is planned.

One concern about using metadata from any external source like ClearlyDefined is that it won't work for private repositories. As people in the threads above have mentioned, the metadata from the published pom files is probably the best source.

Another possible approach could be extending the Dependency Submission API with the optional repository mapping. That would enable community tooling to solve the problem in the way that is best for each ecosystem.