@Martin: you are right they are orthogonal in terms of design but as soon as you get the set notion you don't need the others and I prefer to not multiply the way to do which is always confusing. Since the dependency option does not work generally speaking, I'm clearly on the other side *if we think JPMS needs any more advanced support than today* which is still something I'm not sure.
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 jeu. 2 nov. 2023 à 11:04, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-11-02 à 10 h 49, Romain Manni-Bucau a écrit : > > > this assumes all plugins + runtimes will use the exact same option > > whereas this is generally not true so must be configured per mojo when > > forking and in jvm.config when not forking so I don't see any work > > done at dependency/artifact level working on jvm ecosystem. > > > It can be combined with your Set proposal. I'm starting to see the Set > more like an orthogonal aspect rather than a competing proposal. The > proposed <type>module</type> and <add-exports> elements would apply to > the default Set. For the common case where the same options are applied > to all plugins, that would be sufficient. If different options need to > be applied to some plugins, then Set could be defined with different > <type> and <add-exports> values. > > Martin > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
