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? > > At any rate you have the two mode of ensuring reproducibility which is to > use concrete versions against an arbitrary set of repositories, or range > versions against a constrained set of a repositories. we don't have the same definition of reproducibility but yes, with range version, you can get more control using constrained set of repositories: but more control, to differentiate pre-release and release artifacts for example, is not yet reproducibility > In both cases you'll > have reproducibility problems if your repositories are not managed > correctly. But I think trying to come up with a property graph based > resolution mechanism to deal with context is not going to happen any time > soon and most likely never so I don't really think pursuing that is an > option. property graph resolution mechanism is probably too much but a parametrized resolution algorithm (filtering + final selection of one version from the remaining candidates), at global build level, should be feasible --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
