Re: system path dependency warning, accurate or not?

2021-09-26 Thread Romain Manni-Bucau 
Le lun. 27 sept. 2021 à 00:14, Bernd Eckenfels  a
écrit :

> I don’t agree aboot the constructed repository case, they are intended to
> be shared. But I do agree that Maven should offer a new method to deal with
> such non transitive build dependencies (but just a side note: often you can
> use other plugins to access external resources they will not have that
> warning)
>

This is why this warning is inaccurate:

1. for a "leaf" build it is fully useless
2. it only handles one trivial case but all repository or extensons cases
are ignored so at the end not having it is good for dev but does not mean
you are not in the same case

Are you thikning about a kind of project.canbeImported=true|false meta?
Since we are stucked to model version 4.0.0 I'm not sure it will help so
guess project provider just have to ensure it is documented somewhere.
An open question is, even if I only met leaf case with this pattern, is it
always a leaf case? jdk.tools is a good example of a library using that so
I guess there can be libraries using proprietary jars - not 100% sure.
Overall the point is: why do we assume dev are not good enough to read that
system scope is dangerous if used by default/without careness, think they
are able to understand what they do at that stage and only use it when they
should. If they are not, i'm not sure using conventions is good for them
since they will not be able to understand the build at all, isn't it?


>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Romain Manni-Bucau 
> Gesendet: Sunday, September 26, 2021 8:15:30 AM
> An: Maven Developers List 
> Betreff: Re: system path dependency warning, accurate or not?
>
> Yep but it is not consistent since it is the same with  but
> there is no warning. So means that if you use system path or a custom
> repository  you have to use redefine it anyway in your project.
> So if you think the warning should stay, it should be there for all
> projects depending on anything else than central, no?
>
> The thing is that in 90% of the cases, projects doing that don't have the
> choice and are most of the time dev leaves so it is fine.
> So it is very bothersome to have this false positive warning and it is
> worrying for dev to have the last sentence so I'd like a solution for these
> projects.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 26 sept. 2021 à 03:15, Bernd Eckenfels  a
> écrit :
>
> > I don’t know what your warning reads, but mine says „will be unresolvable
> > by dependent projects“
> >
> >
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Romain Manni-Bucau 
> > Gesendet: Saturday, September 25, 2021 7:50:07 PM
> > An: Maven Developers List 
> > Betreff: Re: system path dependency warning, accurate or not?
> >
> > You have a point for downside projects - which is *not* what the warning
> > says (once again the message is technically wrong ;)).
> >
> > So what is the solution?
> >
> > Fix the message + document inline repo usage which is fully out of the
> > warning but has the same pitfall?
> >
> > Le sam. 25 sept. 2021 à 17:42, Bernd Eckenfels 
> a
> > écrit :
> >
> > > Hello,
> > >
> > > I am a Repo user and despise binaries in git, therefore I would not run
> > > into this problem. It also means you might be outside of the maven
> > > conventions.
> > >
> > >  However I can see that you might need in expectional cases to access
> > > dependencies inside the project directory for building. But the warning
> > is
> > > exactly that: if some other project depends on yours, they won’t be
> able
> > to
> > > resolve. Maybe it is better to turn the local dependency into a new
> type
> > > compile-file, then it is not needed by your dependent projects (and  it
> > > should not produce a warning). Alternatively, maybe make it a plug-in
> > > dependency?
> > >
> > > So all in all, the warning is a good thing unless we have a way to not
> > > export that dependency into the consumer transitive tree (as those
> don’t
> > > know anything about your base)
> > >
> > > Gruss
> > > Bernd
> > > --
> > > http://bernd.eckenfels.net
> > > 
> > > Von: Michael Osipov 
> > > Gesendet: Saturday, September 25, 2021 9:04:22 AM
> > > An: dev@maven.apache.org 
> > > Betreff: Re: system path dependency warning, accurate or not?
> > >
> > > Am 2021-09-24 um 23:43 schrieb Benjamin Marwell:
> > > > Hi Michael!
> > > >
> > > > Setups like "${project.basedir}/m2/" are a common thing.
> > > >
> > > > While "system" scope was probably invented to use system
> > > > (i.e. jdk-related) jar files, but otoh
> > > > it is the only way to pull

Re: system path dependency warning, accurate or not?

2021-09-26 Thread Bernd Eckenfels 
I don’t agree aboot the constructed repository case, they are intended to be 
shared. But I do agree that Maven should offer a new method to deal with such 
non transitive build dependencies (but just a side note: often you can use 
other plugins to access external resources they will not have that warning)

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Romain Manni-Bucau 
Gesendet: Sunday, September 26, 2021 8:15:30 AM
An: Maven Developers List 
Betreff: Re: system path dependency warning, accurate or not?

Yep but it is not consistent since it is the same with  but
there is no warning. So means that if you use system path or a custom
repository  you have to use redefine it anyway in your project.
So if you think the warning should stay, it should be there for all
projects depending on anything else than central, no?

The thing is that in 90% of the cases, projects doing that don't have the
choice and are most of the time dev leaves so it is fine.
So it is very bothersome to have this false positive warning and it is
worrying for dev to have the last sentence so I'd like a solution for these
projects.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 26 sept. 2021 à 03:15, Bernd Eckenfels  a
écrit :

> I don’t know what your warning reads, but mine says „will be unresolvable
> by dependent projects“
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Romain Manni-Bucau 
> Gesendet: Saturday, September 25, 2021 7:50:07 PM
> An: Maven Developers List 
> Betreff: Re: system path dependency warning, accurate or not?
>
> You have a point for downside projects - which is *not* what the warning
> says (once again the message is technically wrong ;)).
>
> So what is the solution?
>
> Fix the message + document inline repo usage which is fully out of the
> warning but has the same pitfall?
>
> Le sam. 25 sept. 2021 à 17:42, Bernd Eckenfels  a
> écrit :
>
> > Hello,
> >
> > I am a Repo user and despise binaries in git, therefore I would not run
> > into this problem. It also means you might be outside of the maven
> > conventions.
> >
> >  However I can see that you might need in expectional cases to access
> > dependencies inside the project directory for building. But the warning
> is
> > exactly that: if some other project depends on yours, they won’t be able
> to
> > resolve. Maybe it is better to turn the local dependency into a new type
> > compile-file, then it is not needed by your dependent projects (and  it
> > should not produce a warning). Alternatively, maybe make it a plug-in
> > dependency?
> >
> > So all in all, the warning is a good thing unless we have a way to not
> > export that dependency into the consumer transitive tree (as those don’t
> > know anything about your base)
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > 
> > Von: Michael Osipov 
> > Gesendet: Saturday, September 25, 2021 9:04:22 AM
> > An: dev@maven.apache.org 
> > Betreff: Re: system path dependency warning, accurate or not?
> >
> > Am 2021-09-24 um 23:43 schrieb Benjamin Marwell:
> > > Hi Michael!
> > >
> > > Setups like "${project.basedir}/m2/" are a common thing.
> > >
> > > While "system" scope was probably invented to use system
> > > (i.e. jdk-related) jar files, but otoh
> > > it is the only way to pull in artifacts
> >
> > Why aren't they installed locally or deployed to a hosted repo?
> > This breaks our convention over configuration.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: system path dependency warning, accurate or not?

2021-09-26 Thread Romain Manni-Bucau 
Le dim. 26 sept. 2021 à 19:40, Tibor Digana  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 
> 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  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
>

Re: system path dependency warning, accurate or not?

2021-09-26 Thread Tibor Digana 
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.

Dňa pi 24. 9. 2021, 16:43 Romain Manni-Bucau 
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  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>