Right! The change if occurred, it's just an unexpected:-) But from my view, the version MUST have a shift:)(Clinton 9X). f.e. POM of maven like thing, in consideration?
Yes, me too. I'm not Sun or Oracle. But maybe I'm the sun or oracle!:) just joke:) Again, joke! Indeed, I wonder why Jigsaw still coding? 致敬 向雅 2012/9/13 BJ Hargrave <[email protected]> > 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* <http://www.osgi.org/>* > **[email protected]* <[email protected]> > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > > > From: 向雅 <[email protected]> > To: OSGi Developer Mail List <[email protected]>, > Date: 2012/09/13 10:34 > Subject: Re: [osgi-dev] About versions > Sent by: [email protected] > ------------------------------ > > > > 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 <[email protected]>: > > 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, 向雅 <[email protected]> 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 <[email protected]> > >> > >> 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 > >> [email protected] > >> > >> office: +1 386 848 1781 > >> mobile: +1 386 848 3788 > >> > >> > >> > >> > >> > >> > >> > >> From: 向雅 <[email protected]> > >> To: OSGi Developer Mail List <[email protected]>, > >> Date: 2012/09/13 08:52 > >> Subject: [osgi-dev] About versions > >> Sent by: [email protected] > >> > >> > >> > >> > -------------------------------------------------------------------------------- > >> > >> > >> > >> > >> > >> 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 > >> [email protected] > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > >> > >> > >> > >> > >> _______________________________________________ > >> OSGi Developer Mail List > >> [email protected] > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > >> > >> > >> > >> > >> _______________________________________________ > >> OSGi Developer Mail List > >> [email protected] > >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > > > > > > > _______________________________________________ > > OSGi Developer Mail List > > [email protected] > > https://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
