Nick, Interesting you should mention this, this is one of the problems to solve on my product's TODO list... I'm referring in particular to RequireJS.
RequireJS doesn't seem to handle versions, just symbolic names such as "jquery". So (for a simple example) on the server, the designer would pick either jQuery2.x or jQuery1.x, and the server can generate a JavaScript fragment containing the RequireJS "config" object which would point the "jquery" dependency to the best-match version. This approach does have its limitations, as unlike OSGi, it's not transitive. But it's better than nothing. :-) Now, just need to implement it... -- Christopher On 11 June 2014 16:01, Nick Baker <[email protected]> wrote: > On a possibly related note. We (Pentaho) have a framework similar to the > WebJars project which we plan on migrating to OSGI. We create > javascript/css jars with embedded RequireJS module definitions. One of the > biggest challenges will be marrying AMD versioned module dependencies with > OSGI versioning. If there¹s interest I¹ll send an update to the mailing > list once we get there. > > -Nick Baker > > On 6/11/14, 9:46 AM, "Christopher BROWN" <[email protected]> wrote: > > >Thanks for the quick replies. I'm not yet using V5, so copying > >VersionRange from V5 seems like the simplest option (looking to moving > >later to V5). Had a look at the code, and it's what is needed. > > > >Thanks, > >Christopher > > > > > >On 11 June 2014 15:40, 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 > >> > > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
