Review request: jpkg -m option takes both classes and resources

[Alan Bateman]

On 10/11/2011 04:48, Mandy Chung wrote:
> The jpkg command currently takes the -m option to specify the 
> directory containing the classes for a module and takes the -r option 
> to specify the directory containing the resources.  Classes and 
> resources must be in separate directory which is different than what 
> we (Java developers) generally do (compiled classes and resources are 
> placed in the same build directory).  To create a jmod file from an 
> existing Java project, it has to separate the classes and resources 
> from a build directory to run the jpkg command which is rather annoying.
>
> This change removes the -r option and have the -m option to take both 
> classes and resources.
>
> Webrev:
>     
> http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jpkg-dash-r-option.00/
>
> Many files and tests are touched due to the rename of ModuleFileFormat 
> to ModuleFile and ModuleFileFormat.Writer to ModuleFileWriter.  Since 
> several tests are updated for this change, I took the chance to change 
> -source 7 to -source 8 and update other tests as well.
>
> The main change is:
> 1.  ModuleFileWriter (was ModuleFileFormat.Writer) - I refactored the 
> existing implementation so that it can process a given directory of 
> both classes and resources in a clean way.
> 2. Rename ModuleFileFormat to ModuleFile and I leave the Reader 
> implementation as it is.  Sean mentioned in the past that the 
> ModuleFile class should be made immutable and need some clean up.  
> Some work to be done in the future.
> 3. Rename the ModuleFormatTest01.java to ModuleFileTest.java.   I 
> rewrote half of the code and keep some existing utility functions.  
> The new ModuleFileWriter implementation only  writes a CLASSES section 
> if there is at least one class file other than module-info.class.  I 
> had to fix this test as the existing implementation always creates a 
> CLASSES section which is a bug.  But there is no clean solution.  Also 
> initially the test tests both regular jmod files and signed jmod files 
> which duplicates the code.  I changed ModuleFileTest.java to take an 
> input argument and if set, it will run the same set of test cases but 
> sign the jmod file.  So ModuleFileTest.java is now a jtreg test to 
> test regular jmod file and SignedModuleFileTest.sh will run 
> ModuleFileTest with an input argument to test the sign jmod file case.
I went through the webrev, except that I only skimmed the "new" 
ModuleFileWriter (as refactoring ModuleFileFormat.Writer and moving into 
its own source file at the same time makes this a bit awkward to 
review). I don't see any any obvious issue. FileCompressor and 
ClassFileCompressor extending ByteArrayOutputStream is a bit odd because 
they are output stream but don't have OutputStream in the name. Also 
getInstance suggests that they can return any instance but a new 
instance is required each time.

One question, does classanalyzer's Modularizer need resDir now?

-Alan.