Community
Participate
Working Groups
We currently have some inconsistencies in how the MIN and MAX versions are handled in the VersionRange. Consider the following: VersionRange gtEqual = new VersionRange("format(n[.n=0;[.n=0;]][d?S=M;]):2.1"); Version max = gtEqual.getMaximum(); The max version is now the Version.MAX_VERSION. Version max = new Version("format(n[.n=0;[.n=0;]][d?S=M;]):2.1"); VersionRange lt = new VersionRange(null, true, max, false); Version min = lt.getMinimum(); The min version is now the Version.MIN_VERSION. Problem 1. A VersionRange can only have one format and by that definition, both the above ranges are incorrect since the Version.MIN_VERSION and Version.MAX_VERSION does not conform with the format of the version at the opposite end. As a result, the following code will sometimes result in an IllegalArgumentException. VersionRange range = new VersionRange(someVersion, true, null, true); Version min = range.getMinimum(); Version max = range.getMaximum(); VersionRange anotherRange = new VersionRange(min, true, max, true); Problem 2. The VersionRange.toString() uses the format of the minVersion on output. Problem 3. Since a MIN_VERSION and a MAX_VERSION are exposed as public constants, it would be good if they could be used when creating OSGi VersionRanges too, i.e. this should be legal: VersionRange range = new VersionRange(new Version(1,0,0), true, Version.MAX_VERSION, true); and result in the same thing as: VersionRange range = new VersionRange(new Version(1,0,0), true, null, true); (the implementation must automatically substitute the Version.MAX_VERSION for the OSGi max version to retain backward compatibility).
Created attachment 126683 [details] Tests that provokes the problem Some additional tests for the omniversion test suite that provokes the MIN/MAX inconsistencies.
Created attachment 126685 [details] Remedy for the problems This patch will fix the problems: 1. A VersionRange can have differnet formats on its versions provided that one of the versions is the Version.MIN_VERSION or the Version.MAX_VERSION 2. The Version format of the VersionRange is obtained from the lower bound by default but if it's found to be the MIN_VERSION, the upper bound format is used instead. 3. If a range is created with a combination of an OSGi Version and the MIN_VERSION or MAX_VERSION, this is now allowed but the MIN_VERSION/MAX_VERSION will be replaced with its correspondence OSGi equivalent.
Released in HEAD. Changing VersionFormat#parseRaw to package private didn't seem related to the bug. I assume that change was intentional?
(In reply to comment #3) > Released in HEAD. Changing VersionFormat#parseRaw to package private didn't > seem related to the bug. I assume that change was intentional? > Yes it was. I discovered that leaving it public was unnecessary and could potentially lead to the creation of bogus versions.
