modulepath and classpath mixture

[David M. Lloyd]

The only rational solution to this problem is to completely forego the 
JDK's capabilities and generate the file exclusively from the build 
tooling.  I expect that at some point we'll end up with a series of 
tools which construct the exports list from annotated package-infos, the 
requires list from a mapping or static list in the build, and a bunch of 
build- and application-system specific miscellany besides.  I don't 
believe that any nontrivial program is likely to bundle a 
module-info.java source file all, which makes me wonder if there's 
actually a point to having support for it at all.  Why write it when you 
can generate it, and at the same time, keep all your build-related 
information in one spot?

On 03/08/2016 02:06 PM, Paul Benedict wrote:
> Robert, it's sounds like a chicken-and-egg problem. You need the module
> name to compile but don't know it until you have compiled.
>
> Too bad this file isn't XML so that any tool could read the module
> information outside of compiling. That's what I advocated for a long time
> but that battle has been lost.
>
>
>
> Cheers,
> Paul
>
> On Tue, Mar 8, 2016 at 1:36 PM, Robert Scholte <rfscholte at apache.org> wrote:
>
>> On Mon, 07 Mar 2016 14:53:28 +0100, Sander Mak <sander.mak at luminis.eu>
>> wrote:
>>
>>
>>> I don't think I understand the issue here. Using -Xpatch doesn't change
>>>> the module declaration or export. It can be used to override or augment the
>>>> module content, it just can't override the module declaration. It can be
>>>> used in conjunction with -XaddReads and -XaddExports to read additional
>>>> modules or export additional packages. For example, if a patch adds types
>>>> to a new package then you could export that package with -XaddExports. If
>>>> the patch injects tests into an existing package then those tests might
>>>> have new dependences and requires compiling or running with
>>>> -XaddReads:$MODULE=junit for example.
>>>>
>>>
>>> I was playing around with exactly this yesterday, and this is what I
>>> ended up with:
>>>
>>> javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \
>>>
>>> -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit
>>> \
>>>        -mp mods:lib-test \
>>>        -d mods-test/javamodularity.easytext.algorithm.naivesyllablecounter
>>> $(find src-test -name '*.java')
>>>
>>> java -Xpatch:mods-test \
>>>
>>>   -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit
>>> \
>>>
>>>   -XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit
>>> \
>>>       -mp mods:lib-test \
>>>       -addmods
>>> javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \
>>>       -m org.junit/org.junit.runner.JUnitCore
>>> javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest
>>>
>>> Which patches my application module to contain a unit test, and then
>>> exposes my application module to junit at runtime (which is used as
>>> automatic module here). This works as expected.
>>>
>>>
>>> -- Sander
>>>
>>
>> When translating this to Maven it assumes that Maven is aware of the
>> module name of the project is it building.
>> Up until now that's not true. Developers specify the moduleName in the
>> module-info.java and it doesn't make sense to ask them to add the same
>> modulename to the pom (it that was possible) or the maven-compiler-plugin
>> configuration. Instead Maven could use some new java9 APIs to discover the
>> moduleName, but that would imply that from now on maven-compiler-plugin
>> requires Java9 runtime. I don't think that's the way we want to go right
>> now. Several Maven plugins have their own kind of multi-release pattern
>> where some codeblocks depend on a specific Maven version, but we really
>> want to avoid this.
>> I hope we can find a way where Maven can simply refer to the
>> classes-directory or the jar for some java/javac arguments where one would
>> now need to be aware of its module name.
>>  From Mavens point of view the output directories are facts, dependencies
>> from the pom.xml too, as is the packaged artifact name & location, the
>> content of java files are a mystery and not of any interest (at least in a
>> classpath world ;) ).
>>
>> thanks,
>> Robert
>>

-- 
- DML