haha:) see belows Regards, qinxian
BTW for convenience :) 致敬 向雅 2012/9/13 BJ Hargrave <[email protected]> >>I think that is what is being said. But that sort of defeats the whole point of a standard. Having a consistent, declarative version model allows semantic versioning. The critical point is the semantic versioning based on the version model, and only the version model oriented. But the version like the locale, its difference pervasive, so the version in current spec not a truth! >>If versions are always on the eye of the beholder, then you need some "oracle" [1] code to understand what everyone means by a version. It simply does not scale. Indeed, to adapt varied version, just only a translator is need. it make an addition to the scale. >>If you want to do something weird in your own little universe, you can hack the Version and VersionRange classes to implement your own rules. Half and Half. In really do some try by my way!:-) the first half. What's goal of my try? for myself? I can eat the code so as not to be hungry? What's goal of OSGi modular? Spread the better method? In my little universe, I found this point maybe a good point for OSGi, and because the version problem just be here, so I do this discuss. If OSGi do this better, the adaptability will be increased. It's not a good thing? it's the second half. >>Just don't expect a bundle from outside of your universe to play well. Because it's just a discuss, IMO, you love who who:) Will all due respect, this style some like "American" of USA. Indeed American is not USA, USA not American too. >>[1] https://en.wikipedia.org/wiki/Oracle (I don't mean Oracle Corporation :-) Seems make some judgement for some unknown things! I'm sure you not historian:) -- 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: Raymond Auge <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 2012/09/13 10:17 Subject: Re: [osgi-dev] About versions Sent by: [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
