maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <>
Subject Re: [Jigsaw] classpaths and modulepaths
Date Sun, 03 Jan 2016 17:59:25 GMT
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.


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  
> <>:
> > What changes to MavenProject do you have in mind?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message