On Wed, Aug 21, 2013 at 11:34 AM, Hervé BOUTEMY <[email protected]> wrote: > IIUC Baptiste point, the question is not about exceptionally forcing to the > old release when 2 versions are "in conflict", but to choose the newer one of > the two proposed versions vs using the newest in the repository (= the latest) > because latest in the repository would give a non-reproducible result
Oh, sorry if I was unclear. I do not and will not ever recommending using the newest in the repository. Like you said, the latest in the repository would give non-reproducible results, and yeah that is very not good. When I say "newest" I mean choose the newest of the two proposed versions. > notice my quotes around "conflict" because it's not a conflict but a choice to > operate between 2 proposed versions (I know internal term used is "conflict", > but IMHO it's not the good term) Yeah, at my company we actually use the term "clash", i.e., "version clash". I was just using the word "conflict" because I thought that's what Maven developers called it. I'm happy to use any other term :) > IMHO, nearest is the best strategy because it let you decide: it's only an > automatic strategy for usual cases, and if you're not happy with automatic > transitive choice, you can configure the dependency in pom which will de facto > create the nearest Don't get me wrong. Nearest is a perfectly fine strategy. But newest is a perfectly fine strategy too. I can see others wanting it besides me. BTW, we could also have a "newest_unless_direct" strategy, so a direct reference from my pom will override. I think a lot of people could find that strategy useful. > I doubt configuration of a strategy per artifact is manageable: IMHO, if you > want to manage things, dependencyManagement is your friend Don't get me wrong. I think you and Jörg are absolutely correct that using dependencyManagement would probably turn this into a non-issue. I would probably not need a "nearest" strategy at all because every update to a new parent pom would get me the newest of all dependencies. We are definitely more inclined to using dependencyManagement now than before, if only to solve this problem; but we'd still prefer to have a "newest" strategy than to use dependencyManagement. Phillip --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
