tycho icon indicating copy to clipboard operation
tycho copied to clipboard

Improve handling of P2 maven metadata

Open laeubi opened this issue 3 years ago • 3 comments

Currently if we generate maven-metadata and have snapshots/unqualified items in the list this will result in something like

artifactId=bundle
groupId=tycho-its
version=1.0.0-SNAPSHOT

even though the bundle is packed as bundle-1.0.0-SNAPSHOT.jar the manifest has for example Bundle-Version: 1.0.0.202201270726

I wonder if we at least in the P2-Metadata should replace with the real qualifier? Or maybe in the maven generated pom as well?

While one might argue that with a release there should be a fixed version, at least most of the builds probably use either the auto-generated qualifier or the jgit provided one instead of assign a unique release version.

@mickaelistria @akurtakov WDYT?

laeubi avatar Jan 27 '22 09:01 laeubi

I wonder if we at least in the P2-Metadata should replace with the real qualifier? Or maybe in the maven generated pom as well? While one might argue that with a release there should be a fixed version, at least most of the builds probably use either the auto-generated qualifier or the jgit provided one instead of assign a unique release version.

The issue is how to knew whether the build is a release or a snapshot, whether it's intended to be overriden with a future change or not? We cannot assume that the qualifier does change automatically for different content in all cases, so it seems like by default, people who expect that if -SNAPSHOT is used in their pom.xml, it's a disposable overridable SNAPSHOT in the Maven sense and doesn't get magically converted to a supposedly static final shareable release. So I think it's safer to stick to what's in the pom file.

People willing to do a release should be able to do so as usual with Maven: by removing -SNAPSHOT or replacing it with some static value before rebuild. Then it becomes "only" a matter of fixing the build-qualifier and validate-version to understand that by either not failing or by forcing the qualifier according to the Maven version.

mickaelistria avatar Jan 27 '22 10:01 mickaelistria

Thats valid I think, even though platform is not going that path, but I have seen that they use version ranges in their depdendecies.

So maybe we should use that as well for snapshot version as something like <version>[1.0.0,1.0.1)</version>? That would capture everything ignoring the qualifier!

laeubi avatar Jan 27 '22 11:01 laeubi

Strange enough a version in an artifact means "recommended version" see here. So maven is free to choose any version, that's quite strange.

So for a local build maven might choose another version if it can't find the SNAPSHOT but for a remote one I assume it will just bails out an error. So I wonder if we should set for the reactor project a version range? And if we create a site set the correct version string as it is somewhat "deployed" then?

laeubi avatar Jan 29 '22 05:01 laeubi

There are now other ways to accomplish that (e.g. Tycho CI friendly versions)

laeubi avatar Oct 19 '22 05:10 laeubi