Review request: jpkg -m option takes both classes and resources
Chris Hegarty
chris.hegarty at oracle.com
Mon Nov 14 08:15:59 PST 2011
Mandy,
Can the sun.java.launcher.module.boot property (in java.c) be cleaned up
to remove the resources directory/jar? I don't think this has been used
for a while, unless it is part of exploded modules?
I scanned the webrev and it looks fine. I'll try to spend some more time
reviewing it tomorrow.
-Chris.
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.
>
> Thanks
> Mandy
>
>
More information about the jigsaw-dev
mailing list