Module-file format (DRAFT)
Mark Reinhold
mr at sun.com
Wed Jan 27 14:51:32 PST 2010
> Date: Sat, 23 Jan 2010 07:07:45 -0500
> From: roger.riggs at sun.com
> Current development environments and runtimes are expected to support
> automated discovery, distribution and verification. This is made
> possible when the artifacts completely describe themselves and their
> dependencies. This information is used to establish and verify
> assumptions and invariants needed to support robust operation. It is
> no longer acceptable to require a user to establish or fix a valid
> configuration.
Completely agree.
> The kinds of information are needed are:
>
> * End user identification of the module, icon, languages supported, etc.
> * Dependencies of native code - instruction set/versions,
> OS name/version, specific drivers or other native code packages.
> * Hardware dependencies - is there a keyboard, screen size, type of
> networking, etc.
> * Ownership and rights - vendor, license term either for user or
> automated verification
> * Etc.
>
> In the JAR format, the manifest was available as a full extensible
> place to record additional information. Its main drawback was having
> to search the JAR to find it and the requirement to encode as text.
Yep.
> This meta information is needed for communication between the IDE,
> distribution server, and runtime at least. Jigsaw itself does not need
> to define the meta data semantics. Incorporating an extensible
> placeholder into the distribution format can enable a single artifact
> to keep the information consistent and available.
Much (though not all) of the above information can be expressed as
annotations in a module's module-info file. I suspect the rest can be
provided as part of the packaging process, but we'd have to work through
the use cases.
- Mark
More information about the jigsaw-dev
mailing list