From bryan.atsatt at oracle.com Tue Jul 8 10:14:10 2008 From: bryan.atsatt at oracle.com (Bryan Atsatt) Date: Tue, 08 Jul 2008 10:14:10 -0700 Subject: Deployment module export... Message-ID: <4873A062.7010308@oracle.com> 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 From abrock at REDHAT.COM Thu Jul 10 00:47:57 2008 From: abrock at REDHAT.COM (Adrian Brock) Date: Thu, 10 Jul 2008 09:47:57 +0200 Subject: Deployment module export... In-Reply-To: <4873A062.7010308@oracle.com> References: <4873A062.7010308@oracle.com> Message-ID: <1215676077.3676.8.camel@warjort> 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 From bryan.atsatt at oracle.com Mon Jul 14 10:34:39 2008 From: bryan.atsatt at oracle.com (Bryan Atsatt) Date: Mon, 14 Jul 2008 10:34:39 -0700 Subject: Deployment module export... In-Reply-To: <1215676077.3676.8.camel@warjort> References: <4873A062.7010308@oracle.com> <1215676077.3676.8.camel@warjort> Message-ID: <487B8E2F.4010308@oracle.com> 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 >> >> From Stanley.Ho at sun.com Mon Jul 21 20:28:28 2008 From: Stanley.Ho at sun.com (Stanley M. Ho) Date: Mon, 21 Jul 2008 20:28:28 -0700 Subject: Deployment module export... In-Reply-To: <487B8E2F.4010308@oracle.com> References: <4873A062.7010308@oracle.com> <1215676077.3676.8.camel@warjort> <487B8E2F.4010308@oracle.com> Message-ID: <488553DC.3090306@sun.com> 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