WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
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.
JBoss, a division of Red Hat