Community
Participate
Working Groups
We're looking at a two digit month value as part of our versioning scheme. When specifying a month (say march 03) the tycho-packaging-plugin strips the leading 0 and produces a mismatch version error. Format: YYYY.MM.X.qualifier We also using the tycho-versions-plugin to set the version and it correctly maintains the leading zeros. Build error: ===================================== [ERROR] Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:0.22.0:validate-version (default-validate-version) on project org.my.project: Unqualified OSGi version 2017.3.10000.qualifier must match unqualified Maven version 2017.03.10000-SNAPSHOT for SNAPSHOT builds -> [Help 1] ===================================== Notice the two versions: 2017.3.10000.qualifier 2017.03.10000-SNAPSHOT The version in the MANIFEST.MF is "2017.03.10000.qualifier", not the "2017.3.10000.qualifier" which is claimed by the error. The version in the pom.xml is "2017.03.10000-SNAPSHOT"
OSGi versions must be digit(s)[.digit(s)[.digits[.string]]] digits are treated and compared as integers, i.e. no leading zeros allowed See OSGi spec https://osgi.org/download/r6/osgi.core-6.0.0.pdf chapter 3.2.5 and 10.1.33
(In reply to Jan Sievers from comment #1) > digits are treated and compared as integers, i.e. no leading zeros allowed I don't see any specific statement saying that leading zeros are not allowed (though I may have overlooked it). The comparison as integers should not be affected by a leading 0. It appears a summary of version comparison occurring is: Summary of source: ======================== String osgiVersion = Version.parseVersion(manifestVersion).toString(); String osgiForCompare = osgiVersion.substring(...) // strip .qualifier String mavenForCompare = mavenVersion.substring(...) // strip -SNAPSHOT if!(osgiForCompare.equals(mavenForCompare)){ fail(...) } ======================== I believe the following would more accurately compare the versions values in a consistent manner. Summary of source: ======================== String osgiVersion = Version.parseVersion(manifestVersion).toString(); String osgiForCompare = osgiVersion.substring(...) // strip .qualifier String strippedMaven = mavenVersion.substring(...) // strip -SNAPSHOT String mavenForCompare = Version.parseVersion(strippedMaven).toString(); if!(osgiForCompare.equals(mavenForCompare)){ fail(...) } ======================== I haven't contributed before but I could submit a review of my local change for discussion once I figure out the process for that.
New Gerrit change created: https://git.eclipse.org/r/92543
I just tested using System.out.println(org.osgi.framework.Version.parseVersion("001.03.04").toString()); which yields 1.3.4 so looks like leading zeroes are allowed in OSGi. Throughout the Tycho codebase we assume there is a 1:1 mapping from OSGi versions to maven versions. We can allow leading zeros but should make sure the 1:1 mapping still applies
(In reply to Jan Sievers from comment #4) > Throughout the Tycho codebase we assume there is a 1:1 mapping from OSGi > versions to maven versions. i.e. we map both ways maven -> OSGi and OSGi -> maven
We can relax the version mapping to allow leading zeroes for this edge case. The most consistent way to validate would be if there are leading zeroes in maven (or OSGi), there should also be leading zeroes in OSGi (or maven), i.e. we would keep the literal 1:1 version mapping. If I got it right the proposed patch normalizes both versions before comparing so you could have leading zeroes on one side but not on the other and the validation would pass.
(In reply to Jan Sievers from comment #6) > We can relax the version mapping to allow leading zeroes for this edge case. > > The most consistent way to validate would be if there are leading zeroes in > maven (or OSGi), there should also be leading zeroes in OSGi (or maven), > i.e. we would keep the literal 1:1 version mapping. > > If I got it right the proposed patch normalizes both versions before > comparing so you could have leading zeroes on one side but not on the other > and the validation would pass. This is correct, when the patch was submitted I was unaware of the 2 way equality requirements. It may be required to get the OSGi version to store the original input which I don't believe it currently does, this would allow the comparison of original inputs on both sides. On a somewhat related note, the importance of this issue may be reduced as I've adjusted our internal versions to remove leading zeros for the build but not for packaging purposes and this is no longer blocking our mandated versioning scheme. (I don't necessarily need this change now but someone may in the future) If I can find some time I'll try to take another look into the issue.
(In reply to Colin Pedlar from comment #7) > If I can find some time I'll try to take another look into the issue. Hey Colin, this problem stil exists and haunts me as well. Any chance it may be resolved in the future?
Same here. OSGi version 2020.12.1 in META-INF/MANIFEST.MF does not match Maven version 2020.12.001 in pom.xml Although the version in MANIFEST.MF is correctly set to 2020.12.001
Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse/tycho/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only.
