eclipse
Do something better with Eclipse Plug-ins
For Eclipse Plug-ins, the groupid the GAV for third party dependencies is different from the original. Generally, this is because the content has been pulled into Eclipse Orbit and is presented with a single bundle name that is some concatenation of the groupid and artifactid; the Maven groupid and artifactid are lost. My observation is that Tycho uses p2.eclipse-plugin as the groupid and the bundle name as the artifactid.
My observation is that the pattern for creating the bundle name is is lossy. In some cases, the groupid and artifactid are fully present, but in some cases repeated segments are optimized out.
The TL;DR: is that we just don't have enough information to consistently map this back to the right thing.
For example, we don't have enough information to consistently map p2.eclipse-plugin:net.bytebuddy.byte-buddy-agent:1.12.2 to maven/mavencentral/net.bytebuddy/byte-buddy-agent/1.12.2. When we encounter ids like this, we set the default type and source of p2/orbit, neither of which are particularly accurate, but at least give the IP Team a clue what's going on.
I'm thinking, though, that we may be able to make and test some really good guesses... That is, there is probably a half of a dozen or so ways to make reasonably good guesses at the GA from net.bytebuddy.byte-buddy-agent. In a worst-case scenario, we could just try them all and see what comes up.
Follow up thought... just make the server component do this rather than have the client make all sorts of extra calls.
And... maybe come up with something other than orbit as the default source.
Maven artifacts contain file bundle_name.jar/META-INF/maven/GID/AID/pom.xml . That's the actual pom that's on maven central so maybe licensetool can look up for it and lookup ipzilla/clearlydefined with the determined GID:AID:version based on that?
I'm not sure that that is entirely true for everything in Orbit. But it's a good idea.
The challenge with that is, up until now, I've never had a handle on the actual file. We probably have a fighting chance of making this happen with the Maven plugin. I'll investigate.
https://github.com/eclipse/tycho/issues/443 aims to improve that on Tycho side for artifacts that are "Maven-first".
Yet many artifacts are not available on Maven and only exist in p2 world.
In Tycho, the scope of dependencies is often system and it's possible to get the jar location with https://maven.apache.org/plugins/maven-dependency-plugin/list-mojo.html#outputAbsoluteArtifactFilename flag. From the jar location, in many cases, it would be possible to look at the content of about.html and deduce license from it; and let the tool decide whether to approve or not.
I think the root cause is
because the content has been pulled into Eclipse Orbit and is presented with a single bundle name
if orbit pulls in some content it may be the same as the maven one but there is no grantee so any assumptions could be false here anyways.
beside that @akurtakov is right that META-INF/maven/GID/AID/pom.xml might be a good choice even though some developers exclude this information on purpose.
