well chicken-egg or just lack of need (from my window the people you reference are very few and mainly testers)
anyway, if we go with the "usages" path we can want to enable a < dependenciesSet> definition containing <dependencies> wrapped in a scope (<dependencySet><module><dependency>....</></></>) this way you can reference a dependency set in a plugin or even main dependencies (import all). That said, as mentionned, it does *not* solve the issue for agents due to the inheritance nature where order will be lost until we add an order attribute/element....and ultimately we are already way more complicated than the existing solution which works well so I still think we are running after a horse which already passed the finish line. 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 à 11:25, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > 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 > >
