Repository WAS Re: Goals was: Re: Supporting OSGi Bundles in the Java Module System

[Adrian Brock]

On Wed, 2008-06-11 at 22:31 -0700, Stanley M. Ho wrote:
> >> 3) QoS - what tools are available for the repository
> 
> The Java Module System implementation will come with a standard tool to 
> manage module archives in the repository, e.g. install/uninstall, etc. 
> Is there any particular aspect of the tools support that you are 
> concerned with but currently not possible in the draft API?
> 
> >> 4) Location - file system/url based, etc.
> 
> This is handled by the ModuleContent abstraction described above.
> 
> > * Developing a full repository just to define a different archive
> > format is too much (e.g. legacy javaee deployments)
> 
> I would like to know what you think about the draft API to see if it is 
> still too much to develop a repository.

The question is how easy is it to do all this overriding of
repository implementations to change behaviour and 
not loose some aspect of the behaviour.

e.g. To programmatically create a module like on the other thread.

The tools of a repository are not defined by the spec,
and there is no repository.install(ModuleContent)
instead I would create a (possibly dummy) URL backed 
by a jam file stream (or whatever format the repository understands).

But does that really do what I want? If I'm mapping a legacy
file to a module definition at runtime, I probably don't 
want to install it in the JDK  repository implementation 
since it will copy it to some disk location.

The next time I reboot my runtime, I would have to delete it
and recreate it otherwise it might be stale.

This is all so I can enable use the tools that come with the 
JDK repository implementation and possibly other behaviour
like Bryan's resolving Module imports to Package imports.
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx