maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support
Just wondering, is this the expected behavior?
DefaultProblemTest is on the *classpath* and I wouldn't expect that these
entries would have any effect on the modulepath entries. I would expect
that the packages between modules are checked, and that all these packages
are exposed to the classpath; no extra check if classpath packages are in
conflict with module packages.
The message says ' in *another* module', but this directory is not a
module, which makes it extra confusing.
thanks,
Robert
On Thu, 17 Mar 2016 20:51:32 +0100, Robert Scholte <rfscho...@apache.org>
wrote:
Hi,
it seems that simply adding -addmods ALL-MODULE-PATH isn't enough to
compile the test-sources, and some already referred to it.
Here's the compiler error:
maven-builder-support/src/test/java/org/apache/maven/building/DefaultProblemTest.java:[1,1]
package exists in another module: maven.builder.support
Let me quote Alan from one of the first responses on this thread:
"For the tests then I assume they are in the same packages as the
sources under src/main/java, is that right?
In that case I think you will want to compile the tests as if they are
part of the module:
javac -Xmodule:m -d testclasses/m -mp m.jar test/java/...
where m is the module name and the module (with sources in
src/main/java) has already been compiled and then packaged as m.jar. The
-Xmodule:<module> option tells the compiler that you compiling the test
classes as if they are part of module m. There is no module-info.java in
the test tree."
To me it seems like the need for knowing the module name keeps returning.
This increases the need for a proper implementation of the
maven-compiler-plugin as a multirelease JAR.
The pattern as shown during FOSDEM showed that the idea works, but it is
not solid enough.
And the next question would be: can Maven (or actually Plexus
ClassWorld) handle this?
I'll need to work out the things to be done and try to get more Maven
developers involved.
thanks,
Robert
On Wed, 16 Mar 2016 21:55:01 +0100, <mark.reinh...@oracle.com> wrote:
2016/2/27 3:25 -0800, rfscho...@apache.org:
I noticed[1] that -addmods already has a special option: ALL-SYSTEM
What I'm looking for is something like ALL-MP or ALL-MODULEPATH, which
simply exposes all modules on the modulepath to the classpath. The set
of
moduleEntries on the modulePath are already chosen with care and are in
the end all required to be able to compile the test-classes without the
need of knowing the name of the module being used to compile with.
We added a special ALL-MODULE-PATH token to the -addmods option, with
this description now in JEP 261 (http://openjdk.java.net/jeps/261):
As a further special case, if `<module>` is `ALL-MODULE-PATH` then all
observable modules found on module paths are added to the root set.
`ALL-MODULE-PATH` is valid at compile time when compiling classes in
the
unnamed module, and at run time when the main class of the
application is
loaded from the class path into the unnamed module.
This change is in Jigsaw EA build #4647 (https://jdk9.java.net/jigsaw/).
Please try it out and let us know what you think.
- Mark
