Deployment module export...
bryan.atsatt at oracle.com
Mon Jul 14 10:34:39 PDT 2008
I believe that ModuleArchiveInfo.getFileName() would only get you a
reference to the metadata file, not the content, and it is allowed to be
null as currently defined.
Since Repository implementations should be free to store in whatever
format they choose, assuming that a deployment module can be
re-constructed from the various apis seems like a very weak alternative
to an explicit, well specified "export" method.
Adrian Brock wrote:
> Couldn't somebody already do this with
> something like:
> public void export(Repository repository)
> URL repoURL = repository.getSourceLocation();
> for (ModuleArchiveInfo archive : repository.list())
> URL url = createRemotableURL(repoURL, archive.getFileName());
> Or is the archive's "fileName" only meant to be a logical
> On Tue, 2008-07-08 at 10:14 -0700, Bryan Atsatt wrote:
>> I believe we need a mechanism to extract a deployment module from a
>> Repository. This would enable:
>> 1. Provisioning systems to copy from a remote repository to a local
>> 2. Migration of all content from one repository to another.
>> 3. Backup of repository content regardless of implementation.
>> 4. Tooling to gather dependent deployment modules into a larger
>> deployment unit.
>> Given that Repository.install() currently takes a URL parameter, it
>> would be nicely symmetrical if Repository could produce a URL (for a
>> given ModuleDefinition) that could be passed directly to install(). For
>> Repositories that act as a front end for a remote store, returning such
>> a URL may be a little extra work, but the underlying mechanisms are
>> already required. For local Repositories, if we recommend that
>> implementations keep the original deployment module as a separate file,
>> then a simple "file:" url can be returned. (Modulo the usual unspecified
>> valid lifetime issue inherent in most URLs.)
>> // Bryan
More information about the jsr277-eg-observer