Validiating JAM files

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Validiating JAM files

david.bristor
Hi folks,

In yesterday's meeting, I offered that while adding support for embedded JAR
files, it might be reasonable to also fix

6571510   (repo) Throw error if a JAM file contains a JAM file

Stanley suggested that it would be a Good Thing if all kinds of JAM validation
were done only once and ideally at the same time.  Section 5.7 mentions checks
that "can" be used: are they required to be done, i.e, "must" instead of
"can"?  Anyway, below is the list from the spec section 5.7, and my
impressions on each.

* The filename of the module archive must have .jam, .jam.pack.gz, or .jar
extension.

Not checked during LocalRepository.install() nor URLRepository.initialize(),
but otherwise OK w/ those repositories.

* The module archive must be in the JAM file format. i.e. a jar file with the
MODULE.METADATA file under the MODULE-INF directory.

Checked via RepositoryUtils.getMetadata().

* If the module archive is signed, its entries must be consistently signed by
same set of signers.

Not checked AFAIK.

* The metadata of the module definition must follow the file format of the
.spkg file.

Not checked AFAIK.

* The module name must be present in the metadata of the module definition.

Not checked AFAIK.

* If the module version is specified in the metadata of the module definition,
it must follow the versioning scheme.

Checked in Version.valueOf()

* If version constraints are specified with the imports in the metadata of the
module definition, they must follow the versioning scheme.

Checked via Version.valueOf()

* If the main class is specified in the metadata of the module definition or
in the manifest of the module archive, the class must be present in the module
archive.

For URLRepository, we want to defer this check until the JAM is actually
downloaded.  For LocalRepository, we can check earlier.

* If the import policy class is specified in the metadata of the module
definition, the class must be present in the module archive.

Ditto the previous.

I plan to file bugs on the above late this week, unless there are objections
or, even better, you let me know that one/more of the above are already
implemented ;-)

Thanks,
        Dave
_______________________________________________
modules-dev mailing list
[hidden email]
http://mail.openjdk.java.net/mailman/listinfo/modules-dev