I think I know understand your request. But I strongly disagree with it
and would object to changing the spec away from a well defined and
declarative versioning scheme.
Jigsaw desires to have this cake and eat it too. I fail to see how this
can work at scale.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargr...@us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
From: 向雅 <fya...@gmail.com>
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>,
Date: 2012/09/13 10:34
Subject: Re: [osgi-dev] About versions
Sent by: osgi-dev-boun...@mail.osgi.org
Hi Ray, You'r right:) seems my writing not so pool;--)
And seems we can provide some common schemes for different cases,
though version scheme varies.
As to some special or strange cases, provided by version requester self.
In cases like JDK version thing, the direct user also. and this case
maybe not out of ordinary. Another similar case, is Linux kernel
version.
So IMO, the first point, current Version class in OSGi core, not right:)
Agree?
致敬
向雅
2012/9/13 Raymond Auge <raymond.a...@liferay.com>:
> I believe the concept 向雅 is trying to put forth may be the notion of
an
> implementable framework extension for Version handling, thus putting
version
> rationalization in the hands of implementors rather than of the spec.
>
> Am I right 向雅?
>
> - Ray
>
> On Thu, Sep 13, 2012 at 9:45 AM, 向雅 <fya...@gmail.com> wrote:
>>
>> Haha:) Than you not say "you bad english":)
>>
>> Because there are some different version schemes, so Version concept
need
>> modeled interface.
>>
>> OK, I mean make Version aspect as standalone bundle.
>>
>> About when? execute version range query or constraints operation
>>
>> The version bundle, some special:) like the DS bundle.
>> In a way, like SPI. or "core module" concept of JBoss modules.
>> The version bundle must have lower start level to prepare for resolve.
>> In another word, It's framework2.
>>
>> No matter what order, just ensure the version bundle started before
>> resolver work
>>
>> IMO, maybe add some SPI like thing to framework, is not so bad:)
>>
>> I try my best as possible to let my typo best:)
>>
>>
>> 致敬
>> 向雅
>>
>>
>>
>>
>> 2012/9/13 BJ Hargrave <hargr...@us.ibm.com>
>>
>> I did not understand most of what you said. But you seem to be saying
that
>> version compatibility is up to entity being used. That is, as the
entity,
>> via the VersionRange interface, if it is compatible with some version.
>> However this is not declarative. It is imperative and require the
>> VersionRange implementation code to execute. In what context does the
>> VersionRange implementation code execute? For example, when a framework
is
>> trying to resolve a bundle so that it can have a class loader connected
to
>> the proper packages, how does the framework know what packages to use
for an
>> import without calling some VersionRange implementation in the bundle
which
>> does not yet have a class loader?
>>
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the OSGi Alliance
>> hargr...@us.ibm.com
>>
>> office: +1 386 848 1781
>> mobile: +1 386 848 3788
>>
>>
>>
>>
>>
>>
>>
>> From: 向雅 <fya...@gmail.com>
>> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>,
>> Date: 2012/09/13 08:52
>> Subject: [osgi-dev] About versions
>> Sent by: osgi-dev-boun...@mail.osgi.org
>>
>>
>>
>>
--------------------------------------------------------------------------------
>>
>>
>>
>>
>>
>> Hi all,
>>
>> Digging into the version problem:)
>> Agree with DBC, but package not equals to contract, nor do module! In
>> practice, both is hard to forced for so many reasons.
>> IMO, the Version class is source of evil or argument. It's contrary to
>> the DBC fact!
>> And in comment of Peter versions blog, someone prefer Roman Numerals.
>> Yes it should be acceptable.
>> And maybe even Pi as 3.14, maybe I would pick TianGan & DiZhi "甲乙丙
丁"
>> "子丑寅卯".
>> As China saying, All tastes difficult to cater! Because 100 people
>> have 100 tastes.
>> And 4 segments style version format, hard to follow.The famous case,
>> JDK from 1.4 to 5.
>> Idea?
>> Yes, Locale!
>> Interface the version, even it can ignored! because it's virtual,
>> every source version is just string.
>> The key is VersionRange interface.
>> The "locale VersionRange" know how to validate the constraint of its
>> version.
>> Because the module(bundle or package) only need know if it's
compatible!
>> So seems like this:
>>
>> interface VersionRange{
>> /**Just check out specified version if compatible the
>> requirement*/
>> boolean compatible(String or Version);
>> /**If there are multiple candidates, return a elect*/
>> int priority(String or Version);
>> }
>>
>> Then make the version package standalone as host, like DS, so fragment
>> from implementer or developer team be attachment.
>>
>> Any thoughts?
>>
>> 致敬
>> 向雅
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
