Not sure I understand. Are you talking about compiling, and more specifically, invoking maven-compiler-plugin, on maven-settings-builder and maven-settings projects or something else? If you are talking about invoking maven-compiler-plugin on several interdependent projects, can you explain how adding modulepath info to MavenProject is going to help?
-- Regards, Igor On Sun, Jan 3, 2016, at 02:30 PM, Robert Scholte wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
