modulepath layout and version number in output directories

[Jonathan Gibbons]

Sahoo,

There is a very strong desire to have the structure of the javac outpuit 
directory mirror the structure of the source directory.  This is to 
support build tools like Ant that rely on a relatively simple time stamp 
comparison between source and derived file.

So, while it may be attractive to have the version number in the output 
directory structure, it is not desirable to do so in the source 
directory structure, where revving the version would mean renaming 
source files, causing unnecessary headaches for source code management 
systems.

-- Jon


On 03/21/2012 10:33 PM, Sahoo wrote:
> Hope to see some response from relevant developers...
>
> On Monday 19 March 2012 09:35 AM, Sahoo wrote:
>> According to [1], for an input source structure like:
>> src/m1/module-info.jar #let's say m1's version is 1.0 in 
>> module-info.java
>> src/m1/...
>> src/m2/module-info.java #let's m2's version is 2.0 in module-info.java
>> src/m2/...
>>
>> javac -d modules -modulepath modules `find src -name "*.java"` 
>> produces following output directory structure:
>>
>> modules/m1/module-info.class
>> modules/m1/...
>> modules/m2/module-info.class
>> modules/m2/...
>>
>> Since every module has always got a version (if not explictly 
>> specified, there is always a default version), is there not a benefit 
>> in encoding the version number in output directory structure? e.g., 
>> how about the output directory structure looking like:
>> modules/m1/1.0/module-info.class
>> modules/m1/1.0/...
>> modules/m2/2.0/module-info.class
>> modules/m2/2.0/...
>>
>> The example in [1] that uses multiple module versions recommends 
>> encoding version number in src directory structure (e.g., src/m1-1.0, 
>> src/m2-2.0, etc), but I am not so sure how practical it is. How often 
>> do we find version number encoded in svn or hg or cvs directory name?
>>
>> Thanks,
>> Sahoo
>>
>> [1] http://openjdk.java.net/projects/jigsaw/doc/ModulesAndJavac.pdf
>