RFR: jpkg contents/show commands

Mandy Chung mandy.chung at oracle.com
Mon May 21 23:15:21 PDT 2012


Chris,

> This change adds two new commands to the packaging tool. 'jpkg show' 
> and 'jpkg contents', which came up on this list a few weeks ago. 
> For now, 'contents' and 'show' are only added jpkg, but I could see 
> that these may be useful before installing a module into the module 
> library, so could be applicable to the jmod command also? Or just jmod? 

Showing the contents of a given jmod file would be useful and
it can provide a way to check if the packaged jmod file contains
the contents as expect without the need to extract the contents.
For the 'show' command, what you have is to show module-info.
How do you expect the show command is used?  I can imagine that
jpkg info might be useful to show the information about the jmod
file such as size of each section (compressed and uncompressed),
and number of subheaders / entries, etc for validation.

jpkg is the packaging tool to create jmod, deb, and other formats
such as ips, rpm, and modular jar.  While the contents and show
commands only apply to jmod files (and possibly modular jars),
I think it's fine to add these commands in the jpkg tool since I
see these commands will typically be used for validating the contents
and run by those who create the jmod file.
For other native packaging format, it will use the native
packaging tool to list the content and show the package information.

The contents command currently lists all entries in a given jmod
file sorted by their name.  So files in one section may be mixed
with files in another section, e.g. native libraries, configuration
files may be buried among the class entries.  It's also hard to
tell which file belong to which section.  Would it be better to
list the contents by section?

Commands.java L92: should this static method simply be
package-private method?

Files.java L363: extra space can be removed.

Librarian.java
   L109-110: how about wrapping these 2 lines differently
   for better readability?
      try (OutputStream fout =
             (ops.equals("-") ? System.out
                              : new FileOutputStream(ops)))

   L219: a space to separate '|' and 'IOException is missing
   to be consistent with the existing convention as in L259.

   L553, 557, 561: '[...]' in the jmod usage output means
   optional.  It's a bit confusing to see "jmod [list|ls] .."
   to show the short form of a jmod command.  How about:
      jmod list [-v] [-p] [-R] [<module-id-query>]
        or ls
      jmod identify
        or id
      jmod remove [-f] ...
        or rm

   Not ideal and any other better way?

ModuleFile.java - the refactoring made it not easy to review but
the chnage looks okay to me.  Minor nits:
   L351: I think IAE is fine.
   L429, 459: 4-space indentation
   L686: a space is needed between while and '('.  Better
   to rename the variable 'b_read' to 'bytes' or 'count'?
   L693: space after (DataOutput) can be removed.

Is there any new test added for these?

Mandy

On 5/17/2012 10:04 AM, Chris Hegarty wrote:
> This change adds two new commands to the packaging tool. 'jpkg show' 
> and 'jpkg contents', which came up on this list a few weeks ago.
>
> http://cr.openjdk.java.net/~chegar/jigsaw/jpkg_contents.00/webrev/
>
> Also, included is various cleanup and restructuring, especially to 
> ModuleFile, to put in place a structure to more easily support new 
> compression algorithms. Specifically LZMA. I have a prototype from 
> last year I need to rebase.
>
> For now, 'contents' and 'show' are only added jpkg, but I could see 
> that these may be useful before installing a module into the module 
> library, so could be applicable to the jmod command also? Or just jmod?
>
> If these new commands are to stay in jpkg long term we should probably 
> change the command that builds the jmod/deb files to create/build, so 
> 'jpkg create ... jmod'.
>
> Two specific implementation changes to draw attention to in the webrev:
>  1) ModuleFile.java (L535 new  file). Resources were never being
>     deflated in the module library. They are now.
>  2) Sean,
>     Can you verify the changes to changes to Singer and
>     ModuleFile.SignatureSection? All jigsaw signing related tests pass.
>
> -Chris.



More information about the jigsaw-dev mailing list