On Sat, 4 Sep 2004 17:59:04 -0400, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I had envisioned something even simpler, where the version string was > either a triple, or a partial and a +. The former would be "perfect", > the later would be "greaterequal". You may have noticed that in > general I prefer more complex solutions but in this case, my gut > feeling is that "less is more". Need to come up with percise, codable > defintiions of all those match types. >
I think it could be useful to distinguish between more than just "perfect" and "greaterequal" matches. For instance it is quite common to use the major version to indicate a refactored and backwards incompatible version. And minor versions often just indicate added features, but otherwise backwards compatible. Thus for a dependency the following would be possible: - no version or match attribute -- any version of "other.module" required - only version given -- would use the default "compatible" match for given version - version and match="greaterequal" -- all 3 parts of the version must be greater or equal - version and match="compatible" -- major must match and others must be greater or equal - version and match="equivalent" -- major and minor must match and last is greater or equal - version and match="perfect" -- all 3 parts of the version must match > There was a proposal to allow more wide ranging format for version > numbers. It would be kind of neat to allow version="1.0-beta-2+" I > suppose "rc" would sort after "beta", but comparing to "1.0" (final) > might be tricky. > This would indeed be tricky. In the referenced Eclipse document the version is even made up of 4 parts (major.minor.service.tag) and simple lexographical sorting is proposed. > Using the RegistryAssembly is exactly the idea I was thinking of. > Someting doesn't smell right, however, between the RegistryBuilder, > RgistyAssembly, the DescriptorParser (and its base class) ... I think > the seperation of concerns is not quite right Maybe a class with the responsibility to carry out the post processing of a registry is required. --knut > > On Sat, 4 Sep 2004 21:01:11 +0200, Knut Wannheden > <[EMAIL PROTECTED]> wrote: > > Hi Howard, > > > > I've started to look at on how to implement module dependencies. > > Before actually thinking too hard about the syntax and semantics of > > the version matching I wanted to take a look at when and how these > > depenencies are checked. > > > > I thought that I'd use the RegistryAssembly#addPostProcessor(Runnable) > > from within the DescriptorParser to implement the checking. This way > > it is ensured that the checks aren't run until all modules have been > > parsed. The downside is that the RegistryAssembly needs the additional > > methods addModuleDescriptor() and getModuleDescriptor(String) used by > > the Runnable implementing the dependency checking. Further this would > > have to be refactored if we ever decided to allow users to define new > > modules at runtime with Java code. But first things first. > > > > What do you think about this approach? > > > > For the actual module dependency version matching syntax and semantics > > I had something as follows (inspired by > > http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/runtime/runtime.html) > > in mind: > > > > <dependency module-id="some.other.module" version="1.0.0" match="perfect"/> > > > > where the "version" and "match" attributes would be optional. The > > "match" attribute would allow the values "perfect", "equivalent", > > "compatible", "greaterequal", where "compatible" would be the default. > > > > --knut > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
