show maven coordinates in dependency:tree for p2 dependencies with maven-mapped coordinates / enable usage of dependency scanners such as BlackDuck

[sratz]

Currently, dependency:tree outputs p2 dependencies in the form

[INFO] +- p2.eclipse.plugin:org.eclipse.equinox.common:eclipse-plugin:3.20.200.v20250628-0509:system

even if they have maven-mapped coordinates: https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.equinox.common/3.20.200

Is there a way to instead derive an output in the maven form?

[INFO] +- org.eclipse.platform:org.eclipse.equinox.common:jar:3.20.200:compile

This would enable the usage of analysis tools such as BlackDuck, which essentially make use of dependecy:tree: https://documentation.blackduck.com/bundle/detect/page/gettingstarted/howitworks.html

[laeubi]

even if they have maven-mapped coordinates: https://mvnrepository.com/artifact/org.eclipse.platform/org.eclipse.equinox.common/3.20.200

The main problem is that these maven coordinates are most often wrong, so we only map those that are valid maven coordinates. For the consumer pom we try a bit harder (e.g. query maven central for the hashsum) but this is of course much slower.

According to the docs:

Runs the Black Duck Signature Scanner on the project. This might identify additional dependencies not known to the package manager such as a .jar file copied into the project directory.

It actually should be possible with the tool as well, you should ask the to handle system scoped dependencies the same as a "copied jar".

[sratz]

It looks like the Sonatype API is broken, or at least the claim that lookup via SHA-1 of the JAR file is possible is false:

0d704582a32510b2f85341d6a18dd52221075ae9 *org.eclipse.equinox.common-3.20.200.jar
72c813af612586f81c874a2774eaba9c73e36744 *org.eclipse.equinox.common-3.20.200.pom

Search via JAR SHA-1 returns nothing:
https://central.sonatype.com/solrsearch/select?q=1:0d704582a32510b2f85341d6a18dd52221075ae9

Search via pom.xml SHA1 works, but of course that doesn't help:
https://central.sonatype.com/solrsearch/select?q=1:72c813af612586f81c874a2774eaba9c73e36744

That would explain why I also did not see any additional entries in the consumer pom.

[laeubi]

I think the sontype search is outdate thats why we use the SmoSearchBackend that uses a different URL

https://github.com/apache/maven-indexer/blob/master/search-backend-smo/src/main/java/org/apache/maven/search/backend/smo/SmoSearchBackendFactory.java#L29-L39

[sratz]

Tycho uses the new (CSC) one:

tycho/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/packaging/reverseresolve/MavenCentralArtifactCoordinateResolver.java

Line 108 in 92d3825

SmoSearchBackend searchBackend = SmoSearchBackendFactory.createCsc();

which I think is the new one.

The old one (SMO) returns nothing for either query:
https://search.maven.org/solrsearch/select?q=1:0d704582a32510b2f85341d6a18dd52221075ae9
https://search.maven.org/solrsearch/select?q=1:72c813af612586f81c874a2774eaba9c73e36744

[laeubi]

Its maybe not all perfect but sadly I can not say whats maybe wrong with sonatype :-\

[sratz]

the way I read https://www.sonatype.com/blog/2011/02/new-service-to-search-for-artifacts-in-maven-central it should support searching for JAR SHA1s. I have reached out to them via the website feedback form, let's see what happens.

[merks]

@sratz

This is completely tangential. The Foundation has been working on SBOM directly from a p2 repository, a product zip/tar.gz, or for installation:

https://eclipse.dev/eclipse/markdown/?file=eclipse-cbi/p2repo-sbom/main/docs/index.md

E.g., this is generated for the 4.36 repository:

https://download.eclipse.org/cbi/archive/sboms/cbi.p2repo.sbom-general-generator/98/index.html

It has lots of useful detail, including dependencies and traceability back to maven central...

[laeubi]

@sratz I intentionally have not asked why this is needed ... interestingly especially paid tools tend to require the user to make all kind of hacks and I don't know exactly what this tool purpose is.

Beside that Tycho now has a mojo for this: https://tycho.eclipseprojects.io/doc/main/tycho-sbom-plugin/generator-mojo.html

[ptziegler]

At least from a technical perspective, Tycho is already perfectly capable of mapping p2 to Maven coordinates (if available on Maven Central of course). Since we also have to use BlackDuck, I eventually came up with something like this, which was executed from our own Tycho-based Mojo:

@Parameter(property = "session", readonly = true, required = true)
private MavenSession mavenSession;

@Parameter(property = "project", readonly = true, required = true)
private MavenProject mavenProject;

@Component(hint = "central")
private ArtifactCoordinateResolver mavenResolver;

public void execute()
	for (Dependency p2dependency : mavenProject.getDependencies()) {
		mavenResolver.resolve(p2dependency, mavenProject, mavenSession).ifPresent(m2dependency -> {
			...
		});
	}
}

However, we eventually gave up on this and simply created one huge mapping table for those coordinates. Primarily because it's a) incredibly brittle, b) incredibly slow and c) abusing the Maven Central API, which is why I don't think it's a good idea for Tycho to provide such functionality directly.

[ptziegler]

I also want to mention that the SHA-1 lookup only works if the bundles from the update site match exactly the artifacts on Maven Central. Which happens for e.g. the Platform bundles, but there are several Eclipse projects where this is not the case.

[laeubi]

You can of course implement your own lookup as well. one might even can guess the maven coordinates from these wrong values of course, the mapping is quite straight forward, just remove the qualifier from the OSGi version...

[ptziegler]

The reason I bring this up is because especially with BlackDuck, there are more problems than just the m2/p2 coordinates. BlackDuck also doesn't know what to do with e.g. features and the Babel translation fragments (which are usually not even in their database).

So it's almost inevitable that one has to do some additional pre-processing of the dependency tree before passing it to BlackDuck.

[laeubi]

I dont know what BlackDuck actually overs compared to other tools, as mentioned above sometimes it works to use dependency:copy and dump the result into such tools.

Apart from that, improve them or bother the support with that could be a more sustainable solution. If every one uses workaround nothing will ever change.

[ptziegler]

In my humble opinion, if the Eclipse Foundation is able to figure out the mapping between the Maven coordinates and the coordinates produced by Tycho, then I except the same from a company that has supply chain security as their business model and who charges a lot of money for their service. 🤷

As said, it's fairly straightforward to do this with Tycho already but the result will be mediocre, unless you have a lot of human intervention.