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
