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. > >> >> 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 To me there is not real distinction between pre-release and release. As I move more toward continuous delivery I see it as a stream of releases all with standard versions. Right now I partition by putting them in separate repositories, maybe at some point in the future the partitioning can be logical. This would be a property graph type resolution where there is a property associated with a particular deployment that says what type it is so the system can decide whether it should participate in resolution. But that presupposes property graph based resolution and that we can actually define what these types are. That's not going to happen for a while so the most practical option for the time being is separating these types into different repositories. Nightly, integration, milestone, or whatever you happen to call them. > >> 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
