modulepath and classpath mixture

[Robert Scholte]

On Tue, 22 Mar 2016 13:06:05 +0100, Peter Levart <peter.levart at gmail.com>  
wrote:

>
>
> On 02/24/2016 08:30 PM, Robert Scholte wrote:
>> On Wed, 24 Feb 2016 09:52:06 +0100, Alan Bateman  
>> <Alan.Bateman at oracle.com> wrote:
>>
>>>
>>> On 23/02/2016 21:10, Robert Scholte wrote:
>>>> :
>>>>
>>>> If I understand this correctly I need to know the module name.
>>> Has there been any discussion around having the module name in the  
>>> POM?  From the mails then it sounds like the project is mostly  
>>> "unaware" that it is creating a module. The other thing that comes to  
>>> mind is the source layout and whether it will get to the point where  
>>> the module name is in the file path. I'm mostly thinking of multi  
>>> module projects where one might have the source to multiple modules in  
>>> the same source tree.
>>>
>>> -Alan
>>
>> The name of the module with not end up in pom-4.0.0, it'll simply break  
>> the xsd and would have effect on all other tools/IDEs/etc depending on  
>> the pom.
>> The only place where one might specify the module name is in the  
>> configuration of the maven-compiler-plugin.
>> In Brussels we talked about multimodules, but it makes more sense that  
>> 1 Maven project contains zero or one module-info[1].
>> And yes, I think a MavenProject will probably be unaware of its own  
>> module name. It knows its source roots and outputdirectories (for both  
>> main/java and test/java) and the packaged jar. Based on the  
>> availability of the module-info in one of these locations it knows how  
>> to construct the commandline arguments.
>> At least, this is what I'm hoping to achieve.
>>
>> thanks,
>> Robert
>>
>> [1] https://twitter.com/rfscholte/status/694599731515899904
>
> Hi Robert,
>
> Why do you want to support tests that "inject" classes into packages of  
> main artifact? Is this mainly because that's how it is done today?

Yes, that's why. The success of modularization depends on the ease of  
migration. Javac already comes with a lot of options and flags to make  
this possible, it is Mavens task to set these with the right values. My  
current opinion is that I don't want to force users to add module-info  
files to the test sources, but the module structure of the main sources  
should be respected.
If you want a separate module for testing, that's up to you. If people  
want to patch the main module, that fine too. If javac supports it, then  
Maven should support that too.

thanks,
Robert

> With modules I would rather create tests in its own module and use  
> qualified exports from otherwise concealed packages of main module to  
> give tests access to types that are not accessible otherwise. This  
> however means that main module would have to use public qualifier on  
> types and members to allow test module to access them. In effect  
> substituting the package-private-nes with partly concealed packages to  
> enable testability.
>
> Perhaps jigsaw should realize that testabililty is an important aspect  
> to support. Forcing tools to compile a suitable set of javac and java  
> options to compile or inject new classes into an existing module and  
> augment it's dependencies is not very pleasant. Maybe this could be  
> supported with a little twist to the accessibility rules. Let me borrow  
> a rough idea that already circulated this list a while ago and modify it  
> to fit on the top of jigsaw accessibility rules.
>
> Suppose that a qualified export of a package to the specific module(s)  
> could be augmented with say a "private" keyword:
>
> module my.mod {
>      requires ...;
>      export private my.mod.internal to my.mod.test;
> }
>
> module my.mod.test {
>      requires my.mod;
>      requires junit;
> }
>
> ...which would not only export the package to the specific module(s),  
> but also enable access to package-private types/members of that package  
> from the target module(s) as though those types/members were public for  
> them and for them only.
>
> It would only be possible to specify "private" keyword with qualified  
> exports - not with unqualified.
>
> Would that be against any jigsaw goals?
>
> Regards, Peter