Deployment module export...

Bryan Atsatt 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.

// Bryan

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());
>       process(url);
>    }
> }
>
> Or is the archive's "fileName" only meant to be a logical
> identifier?
>
> 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 
>> instance.
>> 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.)
>>
>> Thoughts?
>>
>> // Bryan
>>  
>>     



More information about the jsr277-eg-observer mailing list