Convert to Modular JAR

[Paul Sandoz]

Hi,

On Jul 18, 2012, at 4:44 PM, Jaroslav Tulach wrote:

> Hello Paul,
> right, I have not thought about signed modules. The IDE does not need signed 
> modules for its internal purposes. That is why it is always OK to export into 
> unsigned JAR files.
> 
> I've also give second thought to the idea of repository. Now I think the 
> repository should primarily be about listing its content and downloading it to 
> local library[1]. If you want to encourage 3rd party implementations of 
> repositories, it does not make sense to put additional requirements on the 
> implementors. Thus the conversion logic might be too complex to be part of a 
> repository.
> 
> If the conversion is not part of a repository, then it probably belongs to a 
> library (right)? In such case the IDE could always create a library and load 
> necessary modules into it and then do the conversion. 
> 
> -jt
> 
> [1] I hope I am not confusing the repository/library terms again.
> 

Perhaps :-) a library is a "container" where module files are installed and things are optimized for the execution of applications. An entry point (e.g. "class foo.Main") defined in a module will result in running the resolver and production of a configuration, which may fail.

Will NBs need to fetch modules and extract class files for the purpose analysis and *potential* installation into a library?

--

A repository is just a collection of module files with a catalog for fast look up. There are currently two implementations of org.openjdk.jigsaw.Repository, a RemoteRepository that supports the file and http URI schemes for the fetching of the catalog and module files, and a PublishedRepostiory that is a file-based repository that also supports the publishing of module files.

It's quite easy to support the extraction functionality locally in an implementation of Repository [*].

What i think we require to improve matters is to support a local cache of module files fetched from a remote repository (e.g. like ~/.m2/repository). Then extracted classes can also be cached locally. 

Currently the RemoteRepository implementation only caches the catalog. I think it is quite easy to support the caching of module files, which is essentially a file-based repository (as supported by PublishedRepository).

Hth,
Paul.

[*] An HTTP repository could also support an optional extraction feature (easy to describe with a service document) and the RemoteRepository implementation can be smart enough to know what to do .e.g make a GET request or perform the work locally.