I haven’t worked much with Nexus before, so I’m still trying to work out a product lifecycle that works for us.
I want to be able to export certain sets of repository artifacts from nexus into another nexus container. It looks like the only way to do this, as of now, is to pull artifacts as a set of dependency builds and then deploy them to the new repository. This may be what we have to go with, I was just looking for a better approach.
It looks like mirroring or proxying won’t give us the fine grain control of export that I need.
I see that I can just copy artifacts out of nexus, but I’m not sure how to tell the new nexus container that it is supposed to manage those files.
What I want to do is be able to put a set of artifacts onto a DVD that can be run as a localized nexus instance for the purpose of installing software at a customer site. It appears that for any customer that will allow a connection back to us for software installs, they can be treated with the same install setup we use for QA. The reason to use a nexus deploy instead of an installer is because we need to be able to roll back a “patch install”, as each path/install set would be maintained as a release version. Right now this is all done in custom code, since there doesn’t seem to be an installer that handles rollbacks (with backups) after the install has completed.
This would be a non-standard usecase for Nexus and it strikes me that Nexus would be overkill for your requirements. Any web server can act as a Maven repository, once the files are available in the correct format.
For example, why not burn the desired subset of repository files onto DVD and include a copy of Jetty? Jetty which can be launched from the DVD and serve up the local content over HTTP.