another option is bnd's aQute.bnd.version.Version
which should work on old versions (although the package may have been slightly different) But I would go with Neil's solution if at all possible since it's spec compliant and therefore more safe long term. - Ray On Wed, Jun 11, 2014 at 9:40 AM, Neil Bartlett <[email protected]> wrote: > I would say that the VersionRange class from OSGi R5 Core is exactly the > right tool for the job. If you need to use a version of OSGi older than R5 > — bearing in mind that Felix, Equinox and Knopflerfish all comply with at > least R5 — then you can copy the source of that class to your own project. > > Regards, > Neil > > > On 11 June 2014 at 14:29:02, Guillaume Nodet ([email protected]) wrote: > > Felix utils has a few classes that you can use. > > > https://github.com/apache/felix/tree/trunk/utils/src/main/java/org/apache/felix/utils/version > Though with osgi r5, there is a new VersionRange class. > So depending on which osgi minimal version you target, pick the one you > need. > > > 2014-06-11 15:11 GMT+02:00 Christopher BROWN <[email protected]>: > > > Hello, > > > > Regarding version ranges, such as [1.0.0,2.0.0), is there any way to > > construct an object representation of that range in code with Felix / > OSGi > > in general, and then test if a given Version object matches? Something > > along the lines of FrameworkUtil.createFilter(string)... > > > > This is all done automatically for package dependencies, but I'm looking > > for a solution in a different area. > > > > The OSGi-based product I'm working on uses OSGi for packing code, that's > > fine. However, the user interface associated is packaged up in ZIP files > > that the application loads, containing templates, CSS, and JavaScript. > The > > JavaScript files in particular can have dependencies on specific versions > > of specific libraries, such as jQuery 1.9.x or 2.x+, Underscore, > Backbone, > > to name but a few. The non-technical suppliers of these ZIP files aren't > > skilled in defining OSGi manifests to express these dependencies but they > > can choose to pick a library and a version from a list. These JavaScript > > libraries are made available as URLs that are injected into the templates > > based on these declared dependencies. > > > > So I'd like to be able to reuse this logic at an application level, > instead > > of reimplementing it (for the principle, even if it's not a huge > > challenge). > > > > Is there any such solution available with Felix? > > > > Thanks, > > Christopher > > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
