Hi,
I'm experiencing the same problem locally.
When trying to build Oracle provided maven artifact from sources, namely
http://search.maven.org/#artifactdetails|javax.annotation|javax.annotation-api|1.2|jar
the build fails on JDK9 (with Jigsaw) with message:
./src/javax/annotation/Priority.java:42: error: package exists in
another module: java.annotations.common
package javax.annotation;
^
1 error
How is Jigsaw javac going to deal with such compilation scenarios?
Rio
On 03/22/2016 10:23 PM, Robert Scholte wrote:
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
