Repository WAS Re: Goals was: Re: Supporting OSGi Bundles in the Java Module System
Stanley M. Ho
Stanley.Ho at sun.com
Tue Jun 17 16:51:36 PDT 2008
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.
More information about the jsr277-eg-observer