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. -- Regards, Igor On Sun, Jan 3, 2016, at 12:35 PM, Robert Scholte wrote: > getCompileModulepathElements() and getTestModulepathElements() > > Based on a modulePath you can (re)calculate the classPath, but not the > other way around. > > Actually, I think there's a small design flaw when a MavenProject > contains > getCompileClasspathElements() and getTestClasspathElements(). These are > only interesting for java projects. This exposes the problem that a > change > of the JDK behavior would probably need a new version of Maven. > Assuming this isn't required with every new major version of a JDK, > adding > these methods to MavenProject would be fine. > > Robert > > Op Sun, 03 Jan 2016 18:09:52 +0100 schreef Igor Fedorenko > <i...@ifedorenko.com>: > > > What changes to MavenProject do you have in mind? > > --------------------------------------------------------------------- > 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
