Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mainclass: Version attributes must be of type Version #4145

Merged
merged 1 commit into from Jun 5, 2020
Merged

mainclass: Version attributes must be of type Version #4145

merged 1 commit into from Jun 5, 2020

Conversation

bjhargrave
Copy link
Member

No description provided.

Signed-off-by: BJ Hargrave <bj@bjhargrave.com>
@bjhargrave bjhargrave added the maint-candidate Issues or pull requests that are candidates for a maintenance release label Jun 5, 2020
@bjhargrave bjhargrave merged commit cff3f92 into bndtools:master Jun 5, 2020
@bjhargrave bjhargrave deleted the version-attr branch June 5, 2020 19:16
@pkriens
Copy link
Member

pkriens commented Jun 8, 2020

Was there a reason for this or just purity? We generally treat version as a string to allow error handling in these places and maybe weird use cases. The verifier has to ensure that Bundle-Version is a proper version?

@bjhargrave
Copy link
Member Author

Was there a reason for this or just purity?

Yes. The purpose of the version attribute was for comparing against a version range.

public static String filter(String mainClass, VersionRange range) {
StringBuilder sb = new StringBuilder();
sb.append('(')
.append(MAINCLASS_NAMESPACE)
.append('=')
.append(mainClass)
.append(')');
if (range != null) {
sb.insert(0, "(&")
.append(range.toFilterString(VERSION_ATTRIBUTE))
.append(')');
}
return sb.toString();
}

If the version attribute was a plain string, then the version range filter would not properly compare.

There are not tests which confirm this, so the problem of the missing Version type was undetected. I noticed the problem when reindexing our Eclipse 2018-12 repo and saw the new bnd.mainclass capability has a version attribute that was not typed Version like the version attribute on osgi.wiring.bundle.

We generally treat version as a string to allow error handling in these places and maybe weird use cases.

This is not true in any of the resource builder code. We always treat versions as typed Version.

The verifier has to ensure that Bundle-Version is a proper version?

Perhaps, but that has nothing to do with proper filter comparison semantics for versions.

@bjhargrave bjhargrave modified the milestone: 5.2 Jul 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maint-candidate Issues or pull requests that are candidates for a maintenance release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants