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 <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 > > > > >
