modulepath and classpath mixture

[Robert Scholte]

> 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