modulepath and classpath mixture

Richard Opalka ropalka at redhat.com
Tue Mar 22 22:29:09 UTC 2016


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 <rfscholte at 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.reinhold at oracle.com> wrote:
>>
>>> 2016/2/27 3:25 -0800, rfscholte at 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


More information about the jigsaw-dev mailing list