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
