Difference between p2 folders in local repository

[lppedd]

In the local repository, we can find a p2 folder.
In my case I have the following layout:

What are the differences between these folders? How are they used?

---

Continuing the #2031 discussion on resolving dependencies.
That works for plugins, but not for features.

When manually resolving a feature artifact throught WorkspaceReaders, TychoWorkspaceReader composes the local path as, for example:

C:\Users\edoardo.luppi\.m2\repository\p2\osgi\bundle\org.eclipse.nebula.widgets.nattable.core.feature\2.0.0.202012161455\org.eclipse.nebula.widgets.nattable.core.feature-2.0.0.202012161455.jar

But that folder only contains plugins. Features seems to be located starting directly at the root of the p2 folder:

C:\Users\edoardo.luppi\.m2\repository\p2\org\eclipse\update\feature\org.eclipse.nebula.widgets.nattable.core.feature\2.0.0.202012161455\org.eclipse.nebula.widgets.nattable.core.feature-2.0.0.202012161455.jar

So the question is, how do I correctly resolve/download feature JARs?

[laeubi]

So the question is, how do I correctly resolve/download feature JARs?

Feature jars are usually not something that can participate in maven dependency resolution, so you should explain what "resolve" means and what "do not work" mean.

[laeubi]

It's expected the artifact.groupId() to begin with p2

All "real" p2 artifacts begin with "p2." by definition, but many P2 sites promote bogus meta-data (see https://mvnrepository.com/artifact/org.eclipse.birt/org.eclipse.birt.core.ui that there is no 4.9.0-SNAPSHOT version on central).

So I think here is a check missing that the repository flag is set before augment the maven data (see org.eclipse.tycho.core.maven.MavenDependencyInjector.isValidMavenDescriptor(MavenDependencyDescriptor)) .

This seems like a bug to me.

As there is no feature / test associated with your use-case this is maybe a missing feature but not a bug ;-)
But if you like we can enhance this, just test this carefully to watch out for side-effects due to additional downloads.

[lppedd]

@laeubi

But if you like we can enhance this

That would be awesome.
I can see that MavenDependencyInjector already uses validation

tycho/tycho-core/src/main/java/org/eclipse/tycho/core/maven/MavenDependencyInjector.java

Lines 282 to 287 in 190dd00

	private Dependency createScopedDependency(ArtifactDescriptor descriptor, String groupId, File location,
	String scope) {
	Dependency dependency = new ArtifactDescriptorDependency(descriptor);
	MavenDependencyDescriptor dependencyDescriptor = descriptorMapping == null ? null
	: descriptorMapping.apply(descriptor);
	if (dependencyDescriptor != null && isValidMavenDescriptor(dependencyDescriptor)) {

And in fact the BIRT group id is set to p2.*.

So probably it's a matter of saying "are these Maven coordinates ok? If not, let's fall back to the standard ones" in TychoWorkspaceReader.

[laeubi]

And in fact the BIRT group id is set to p2.*.

This does not matter much as likely no one will ever deploy such an artifact, I think the MavenDependencyDescriptor is not useful in this code path but belong to the one marked with TODO below... I just experimented a lot with that but finally restricted the lookup to "plain" P2 items so this seems to slipped through.

So to summarize:

• if it starts with p2 MavenDependencyDescriptor should not be used
• if not, MavenDependencyDescriptor might be used to discover "secret" p2 artifacts, but we should disable that for now.

[lppedd]

@laeubi I can open a PR targeting TychoWorkspaceReader if you want.

but we should disable that for now

You mean that this behavior of looking for Maven coordinates should be disabled/not present everywhere or just for this use case?

[laeubi]

The looking for maven coordinates should be moved to the else but commented out for now (as it is effectively inactive at the moment anyways).