the point is that if you open, as you mention, a system you always end up having compatibility matrix - no plugin except yours will read your meta - so this becomes a nightmare for end users, whereas when there is a standard way - no built-in extensibility - then you never have this issue and it is generally better for users. I'm still on the side to make it easy for users even if it costs a bit more to us and plugin dev.
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 lun. 23 oct. 2023 à 12:05, Christoph Läubrich <m...@laeubi-soft.de> a écrit : > > Exactly the opposite right? > > of what? > > > If we do that then a particular plugin can use that but all others > > will don't read it right > > Whats "right" depends on the context, at least one don't need a new > discussion/extension for each use case, also most of these discussions > cover the needs of the maven-* plugins but often forget custom plugins > that have other demands apart from "everyone can use this for everything". > > > until you rewrite the full maven plugin ecosystem > > Usually such things don't touch really *everything" and especially this > will not require a rewrite for anything but the same as a new <whatever> > element would need beside that <whatever> will always only cover one > specific use-case, while allowing generic extensibility would allow to > cover a wide range of use-cases. > > Am 23.10.23 um 11:34 schrieb Romain Manni-Bucau: > > Le lun. 23 oct. 2023 à 11:31, Christoph Läubrich <m...@laeubi-soft.de> a > > écrit : > > > >> I always wished there was support for generic <properties> element in > >> <dependency> this can then be literally used for everything in an > >> extensible way. > >> > >> <dependencies> > >> <dependency> > >> ... usual stuff ... > >> <properties> > >> <usages>module</usages> > >> <whatever>...</whatever> > >> <properties> > >> </dependency> > >> </dependencies> > >> > > > > Exactly the opposite right? > > If we do that then a particular plugin can use that but all others will > > don't read it right so ultimately you reach the exact opposite of what > you > > aim for until you rewrite the full maven plugin ecosystem which is > > obviously not the goal IMHO. > > > > > >> > >> Am 23.10.23 um 11:24 schrieb Martin Desruisseaux: > >>> Le 2023-10-20 à 20 h 43, Romain Manni-Bucau a écrit : > >>> > >>>> that said, on my side, not sure JPMS will be widely adopted anytime > >>>> soon so can be a false problem. > >>>> > >>> I think that this is a chicken-and-egg problem: some peoples renounce > to > >>> JPMS because tools support is poor (at least in Maven and Gradle), and > >>> tools don't improve their support because they think that JPMS is not > >>> widely-used. We sometime see in mailing lists or blogs blames saying > >>> that JPMS is half-backed, while actually the problem lies in the tools. > >>> > >>> Regarding the original proposal, I would suggest an amendment for > >>> addressing more problems at once: not only agent, but also doclet, > >>> annotation processor and one aspect of JPMS. Instead of an <agent> > block > >>> in <dependencies>, I suggest a new <usages> element inside <dependency> > >>> saying where to put that dependency. Example: > >>> > >>> <dependencies> > >>> <dependency> > >>> ... usual stuff ... > >>> <usages>module</usages> > >>> </dependency> > >>> </dependencies> > >>> > >>> Where <usages> can contain a comma-separated list of the following: > >>> > >>> class, module, processor-class, processor-module, doclet, agent > >>> > >>> where > >>> > >>> * class and module are mutually exclusive, > >>> * processor-class and processor-module are mutually exclusive. > >>> > >>> This is not exactly the same as the existing <type> element because > >>> <type> changes the artifact to use (main versus test) without changing > >>> where to put it (class-path versus module-path), while the proposed > >>> <usages> is the converse. > >>> > >>> Martin > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
