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
