Hi Martin, 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.
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 à 10:47, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2023-10-29 à 21 h 36, Romain Manni-Bucau a écrit : > > > Was referencing the options using module names, if you drop the dep or > > reference a package not supported by the module we should be able to > fail. > > > I do not want to distract this thread from the core issue (control on > class-path versus module-path), but I believe that above concern can be > avoided. Lets take --add-exports as an example. The syntax of the option > passed to javac is: > > --add-exports source/package=target > > Where /source/ and /target/ are module names. For example if a project > is a module named "my.project" and that module is using the "org.junit" > module as a dependency, we may want to add the following option: > > --add-exports my.project/my.internal.package=org.junit > > It is possible to design the Maven POM in such a way that those modules > are inferred from the context. The POM could look like this (simplified): > > <artifactId>my-project</artifactId> > <!-- with a module-info declaring "my.project" --> > > <dependencies> > <dependency> > <artifactId>junit</artifactId> > <!-- with a module-info declaring "org.junit" --> > <scope>test</scope> > <add-exports> > <packages> > <package>my.internal.package</package> > <!-- Repeat for other packages to export --> > </packages> > </add-exports> > </dependency> > </dependencies> > > Above would mean: if the JUnit dependency is added on the module-path > (which happens only during tests), then automatically generate > --add-exports options with: > > * The enclosing project ("my.project") as the source module. > * The enclosing dependency ("org.junit") as the target module. > * The specified <package> elements as the packages to exports. > > A similar approach can be applied to other options. That way, module > names do not appear anywhere and the inconsistency risk does not exist. > This proposal does not cover all cases, but would provide a safe and > easy way for probably the majority of cases. If a user needs to specify > different modules than the ones inferred from the context (s)he can > still add the --add-exports option manually on the command-line. > > Martin > >
