Le dimanche 15 juin 2014 09:19:26 Jason van Zyl a écrit : > On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > > Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit : > >>> yes, but how is the constraint expressed and coded? > >> > >> Trying to encode these in such a way where you effectively have a > >> property > >> graph is hard. Aether has some preliminary support for this but not > >> really. > >> In practice to date it's really constrain the version or constrain what > >> you > >> are resolving against. > >> > >> Either explicit with your version as a concrete version if you want to > >> resolve against the wild. Or you use ranges and the constraint is encoded > >> as the list of repositories you are going to resolve against. > > > > for the moment, yes, the constraint has to be encoded as the list of > > repositories you resolve against: if we make this practice clear, things > > will get much clearer until we find another strategy (I don't have one > > for the moment) > > > >> Given that we have a de facto formalism through our code, specifically in > >> Aether, that I would gravitate toward using a formalized resolution model > >> like what OSGi. I'm certainly not a huge proponent of OSGi, but they have > >> a > >> completely formalized and specified resolution algorithm. > > > > I really didn't find any formalisation of resolution algorithm, either in > > Aether of OSGi: once a list of version have been found that match the > > constraint, I still don't see/know what is the chosen one > > > > Can you point me to the right direction, please? > > You need to download the spec: http://www.osgi.org/Specifications/HomePage > > There is a section on versions. ok, I found the answer:
"3.8 Resolving Process ... An exporter with a higher version is preferred over an exporter with a lower version" then maximum version (compatible with version range) is used: we should be able to say simply that and IIUC: - nobody finds that any other choice is better in any case - nobody finds that it looks like LATEST, which was removed because it was told not reproducible Now I understand how using version ranges is not really compatible with using SNAPSHOTs: SNAPSHOT is the way to handle limited change when not using ranges But if you choose to use ranges, you have this de-facto LATEST handling that makes SNAPSHOTs more a problem than anything For the moment, I continue to like SNAPSHOTs + preferred versions :) But I start to see all the implications of using ranges: this is a whole other organization Regards, Hervé --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
