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

Reply via email to