I would really prefer a solution without changing Maven Project,
especially since we're talking about non-generic or language-specific
elements.
However, in my example where maven-settings-builder depends on
maven-settings, how would m-s-b know what the modulePath for m-s is? You
shouldn't ask this information on the compiler-plugin of m-s, since there
should be no logic between plugins. There should be some sort of shared
context and the only reasonable object I can think of is the MavenProject.
Assuming I compiled with -modulesourcepath, should the compiler-plugin
copy all those files to the target/classes directory too, so other plugins
can use it as a pre-java9 project? I hope not, but it would be a simple
solution to keep the classpath in tact, but it doesn't solve the
modulepath problem required by other modules of the multimodule project.
Robert
Op Sun, 03 Jan 2016 18:59:25 +0100 schreef Igor Fedorenko
<i...@ifedorenko.com>:
I agree that getCompileClasspathElements/getTestClasspathElements are
flawed, but I don't think adding
getCompileModulepathElements/getTestModulepathElements is a good idea.
MavenProject is supposed to be generic, and modulepath is something
very specific to java 9. At the same time, compile mojo and surefire can
already derive all they need from project dependency artifacts, so these
two new methods appear to be redundant.
I am also not sure if
getCompileModulepathElements/getTestModulepathElements will be generally
useful for other java-related plugins. For example, I couldn't use
existing getCompileClasspathElements/getTestClasspathElements in takari
lifecycle and I suspect I will not be able to use
getCompileModulepathElements/getTestModulepathElements either.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
