[modules-dev] Validiating JAM files

[Dave 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