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
