Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of nbaker@pentaho.com designates
 98.129.35.7 as permitted sender)
From: Nick Baker <nbaker@pentaho.com>
To: "users@felix.apache.org" <users@felix.apache.org>
CC: Guillaume Nodet <gnodet@apache.org>
Date: Wed, 11 Jun 2014 09:01:50 -0500
Subject: Re: Constructing and matching version ranges in code with OSGi
Thread-Topic: Constructing and matching version ranges in code with OSGi
Thread-Index: Ac+FfbIbXsb5Oua+QL280mXCAvm/dg==
Message-ID: <CFBDD851.CF1E%nbaker@pentaho.com>
References: 
 <CAHL_zcPKPGpTktRXkPze3vErcjDivgVwS6fOvHXyqCu6_TNK7Q@mail.gmail.com>
 <CAA66TporhamOSQ7s5fSUf-mfHYJwDPRwOHcu1_7yP+yURB-90w@mail.gmail.com>
 <etPan.53985c56.643c9869.f859@Endofunctor.local>
 <CAHL_zcMSAN90wk5sOXvUNJemhd1O2UaWODOA3brRP0pEVBMX6g@mail.gmail.com>
In-Reply-To: 
 <CAHL_zcMSAN90wk5sOXvUNJemhd1O2UaWODOA3brRP0pEVBMX6g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.4.1.140326
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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=B9s interest I=B9ll send an update to the mailing
list once we get there.

-Nick Baker

On 6/11/14, 9:46 AM, "Christopher BROWN" <brown@reflexe.fr> 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 <njbartlett@gmail.com> 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
>> =8B bearing in mind that Felix, Equinox and Knopflerfish all comply with
>>at
>> least R5 =8B 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 (gnodet@apache.org) wrote:
>>
>> Felix utils has a few classes that you can use.
>>
>>
>>=20
>>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 <brown@reflexe.fr>:
>>
>> > 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org