modulepath and classpath mixture

[Peter Levart]

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? 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