modulepath and classpath mixture

[Richard Opalka]

Hi,

    I just solved it by adding -Xmodule option:

javac -Xmodule:java.annotations.common -sourcepath src `find -type f 
-name *.java`

Rio

On 03/22/2016 11:29 PM, Richard Opalka wrote:
> 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