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
