Thanks. I've rewritten the PR under the assumption that all version ranges are "hard". Please take another look. (PTAL)
On Fri, Nov 1, 2019 at 7:54 PM Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > > On Fri 1 Nov 2019 at 21:37, Elliotte Rusty Harold <elh...@ibiblio.org> > wrote: > > > Pass 1: > > https://github.com/apache/maven-site/compare/master...elharo:patch-34 > > > > This might not be accurate. In particular I am assuming that if there > > are two requirements for [1.0,2.0] and (3.0,5.0) that something will > > be picked. > > > If the same dependency is pulled into the tree in different places and the > intersection of ranges is an empty set then the build fails. > > This might not be accurate. If this instead fails the > > build, please let me know. Comments are probably most convenient on > > the PR. Thanks all. > > > > *** {Dependency Version Requirement Specification} > > > > Dependencies' <<<version>>> elements define version requirements, > > which are used to compute effective dependency > > versions. Version requirements have the following syntax: > > > > * <<<1.0>>>: "Soft" requirement on 1.0. Use 1.0 if no other version > > appears earlier in the dependency tree. > > > > * <<<[1.0]>>>: "Hard" requirement on 1.0. Use 1.0 and only 1.0, even > > if other versions come before this dependency in > > the tree. If multiple hard versions conflict, fail the build. > > > > * <<<(,1.0]>>>: Soft requirement on any version \<= 1.0 > > > > * <<<[1.2,1.3]>>>: Soft requirement on any version between 1.2 and > > 1.3 inclusive. > > > > * <<<[1.0,2.0)>>>: 1.0 \<= x \< 2.0; soft requirement on any version > > between 1.0 inclusive and 2.0 exclusive. > > > > * <<<[1.5,)>>>: Soft requirement on any version greater than or equal to > > 1.5. > > > > * <<<(,1.0],[1.2,)>>>: Soft requirement on any version less than or > > equal to 1.0 than or greater than > > or equal to 1.2, but not 1.1. Multiple requirements are comma-separated > > > > * <<<(,1.1),(1.1,)>>>: Soft requirement on any version except 1.1; > > for example because > > it is known not to have a critical vulnerability. > > > > > > On Fri, Oct 25, 2019 at 4:43 PM Stephen Connolly > > <stephen.alan.conno...@gmail.com> wrote: > > > > > > On Tue 22 Oct 2019 at 11:30, Elliotte Rusty Harold <elh...@ibiblio.org> > > > wrote: > > > > > > > The docs at > > > > > > https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification > > > > say: > > > > > > > > 1.0: "Soft" requirement on 1.0 (just a recommendation, if it matches > > > > all other ranges for the dependency) > > > > [1.0]: "Hard" requirement on 1.0 > > > > > > > > However, I don't think anywhere do we actually explain what a soft or > > > > a "Hard" requirement is. If someone can clarify this for me, I'll > > > > update the docs accordingly. > > > > > > > > > > Ranges only come into affect when you have multiple dependencies using > > > ranges. > > > > > > When you use ranges, Maven tries to satisfy all the requests. > > > > > > A soft version is like: “I’d like this if I can have it” > > > > > > A hard version is: “only this or die” > > > > > > If your dependency tree has dependency foo being brought in by multiple > > > dependencies: > > > > > > Maven first gets the intersection of all ranges > > > > > > If there is more than one version left in the intersection, Maven looks > > at > > > the “nearest” soft version requests and if that fits the range it will > > use > > > that. > > > > > > If your range is just a single version, that means only that version will > > > do, hence it becomes a hard specification. > > > > > > Now having said all that, ranges have - to date - proven problematic. In > > > general it is better to avoid ranges at all... and that includes hard > > > version numbers. > > > > > > Hopefully in Maven 5.0.0 we can find a way to make ranges at least > > > usable... but the reality is ranges are a hard problem in and if > > themselves. > > > > > > > > > > > > > > > -- > > > > Elliotte Rusty Harold > > > > elh...@ibiblio.org > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > -- > > > Sent from my phone > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- > Sent from my phone -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
