Deployment module export...

[Bryan Atsatt]

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
 

[Adrian Brock-4]

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
>  

--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

[Bryan Atsatt]

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
>>  
>>    

[Stanley M. Ho]

Hi Bryan,

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

This method will give you a reference to the actual content. For
example, in the local repository case, this will return a filename of
the actual file in the repository interchange directory. That said, this
method is allowed to return null because the repository implementations
may not always make the content available as a physical file.

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

Fair enough. I will look into adding an API to do this in the next
revision of the API specification draft.

- Stanley