Le dim. 26 sept. 2021 à 19:40, Tibor Digana <tibordig...@apache.org> a
écrit :
> Scope=system is not like the Maven has proposed its biggest strength with
> Maven dependencies and GAV. This scope should be deprecated or even
> removed.
>
Assuming it is true - if you reread this thread you will see it is not, it
is not different than file:// repositories or https:// repositories since
maven has no idea what is behind.
Point is users need that feature so how do we propose them to solve it long
term.
Note that saying with a new version "we dropped it cause it was not a good
idea" would be a shame but also not helping to solve a real life issue so
please help me to refine a *solution* instead of saying you don't care of
users - i know you didnt say it like that but it is what it means for users
so Im emphasing users PoV which is the only thing we should focus on,
technical details are just there to serve them at the end.
> Dňa pi 24. 9. 2021, 16:43 Romain Manni-Bucau <rmannibu...@gmail.com>
> napísal(a):
>
> > Hi all,
> >
> > wonder if there is any reason to see this warning when using a jar in the
> > project in system scope:
> >
> >
> > [WARNING]
> > [WARNING] Some problems were encountered while building the effective
> model
> > for io.yupiik.foo:foo:jar:0.0.1-SNAPSHOT
> > [WARNING] 'dependencies.dependency.systemPath' for foo:bar:jar should not
> > point at files within the project directory,
> > ${project.basedir}/m2/lib/bar.jar will be unresolvable by dependent
> > projects @ line 71, column 19
> > [WARNING]
> > [WARNING] It is highly recommended to fix these problems because they
> > threaten the stability of your build.
> > [WARNING]
> > [WARNING] For this reason, future Maven versions might no longer support
> > building such malformed projects.
> > [WARNING]
> >
> > since the absolute path starts with a "in project" path the build will be
> > stable, the jar will be resolvable etc so there is no reason for the
> > warnings nor maven to not support it in a future version.
> >
> > Is it just due to fixing the "tools.jar" dependency (where the warning is
> > relevant) or is there another rational behind that and the warning is
> not a
> > bug?
> > If so i'm concerned there is no real alternative until you get a m2 https
> > server which is not always an option so the last sentence requires us to
> > work toward a solution (that said it will likely be the same so I'd
> prefer
> > to drop the warning if the dpeendency is in the project).
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
>
