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

[Stanley M. Ho]

Adrian Brock wrote:
> 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.

As you mentioned in another thread, "all we really want to do is to PUSH 
a ModuleDefinition/Content to the jsr 277 module system such that we can 
get back a Module/Classloader with the imports resolved." I don't think 
you really meant to change the behavior of the existing repositories 
(e.g. bootstrap, etc.), but to make it easy to create a new repository 
by extending from a stock implementation and override some of its 
behavior. If I misunderstand you, please let me know.

The repository API in the current draft requires many methods to be 
overridden in order to build a fully functional repository 
implementation. The use case you mentioned is to build a simple 
repository at runtime that all it does is to return ModuleDefinitions; 
it doesn't has a real physical repository under the cover, and it 
probably doesn't support install/uninstall and all the other methods. In 
this case, I agreed that the API probably requires too much work for the 
implementors, and I will look into this issue to see if some 
simplifications can be made in the API.

- Stanley