Le lun. 27 sept. 2021 à 00:14, Bernd Eckenfels <e...@zusammenkunft.net> 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 <rmannibu...@gmail.com> > Gesendet: Sunday, September 26, 2021 8:15:30 AM > An: Maven Developers List <dev@maven.apache.org> > Betreff: Re: system path dependency warning, accurate or not? > > Yep but it is not consistent since it is the same with <repository> 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 <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 > > > > > Le dim. 26 sept. 2021 à 03:15, Bernd Eckenfels <e...@zusammenkunft.net> 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 <rmannibu...@gmail.com> > > Gesendet: Saturday, September 25, 2021 7:50:07 PM > > An: Maven Developers List <dev@maven.apache.org> > > 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 <e...@zusammenkunft.net> > 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 <micha...@apache.org> > > > Gesendet: Saturday, September 25, 2021 9:04:22 AM > > > An: dev@maven.apache.org <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 > > > > > > > > >
