I don't see how you can have both an ask-first approach and not some business process to handle it. The recommended setup we like to see is to let developers have access to the repos, but keep the official builds behind the Nexus Procurement repo so that you are sure what is officially built. It's the best of both worlds. If they really insist on being 100% offline, then you are stuck with a completely manual process that will be bureaucratic regardless of the existence of a tool or not. It simply isn't practical to try and pull down all 80gb of central and every other repo you might ever want and then hide in a corner hoping you never need something more. It has to be a balanced approach.
-----Original Message----- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Sunday, February 01, 2009 2:14 PM To: Maven Users List Subject: Re: Maven for the internet afraid I need to clarify my question. The security people at my company certainly want the finest-grained control possible over artifacts, that is, an ask-first model where they approve each individually. I don't question that we can force Maven into this mindset, but whether we can do so without significantly hindering its usefulness. For us, a reactive approach like what Nexus's procurement mechanism assists with will inevitably turn artifact approval into an agonizing bureaucratic process at exactly the wrong times for developers. To ensure that relatively arcane corners of dependency resolution do not hamstring them in the midst of coding frenzies, I need a big-bang approach to front-load the repository. Basically, how can I minimize the pain when someone tries to use an already approved artifact in an unanticipated configuration? Incidentally, I have been happily experimenting with Nexus for a little while now. Good work. > In short, two handy URLs: > http://books.sonatype.com/nexus-book/reference/procure.html > http://blogs.sonatype.com/people/2009/01/nexus-professional-what-is-procurement/ > > > Hope helps, > ~t~ > > > On Sat, Jan 31, 2009 at 9:36 PM, Merv Green <paradeofh...@gmail.com> wrote: > > >> So, in my quest to take Maven completely internal, I'm still grappling with >> a couple of use cases: >> >> 1. Gathering plugin dependencies >> >> We have some list of approved plugins we somehow decide we need. For each, >> we want to populate our repo with any artifacts those plugins might require >> in use. >> >> During the approval process we create dummy projects to exercise each >> plugin, then we build those projects against a proxy repo and declare >> whatever landed in the proxy kosher. That step rubs me wrong because I feel >> like Maven is resolving plugin dependencies based on the plugin's >> configuration for a particular project, and we'll easily miss some use >> cases, ending up with an incomplete repository. >> >> Wendy, apparently has a better way that uses the assembly plugin, but I >> don't quite understand it. Could you illustrate? >> >> >> 2. Different dependency configurations >> >> Say we like artifact A, so we create a project, P that depends on A. >> Declared dependencies are like so: >> >> P --> A >> A --> B, C >> B --> D-v1 >> C --> D-v2 >> >> So we bundle P's dependencies in remote repo configuration and upload to >> the approved repository, which now includes A, B, C and D-v1. >> >> Some time later, a developer depends on only C, and the project refuses to >> build. How do you all handle this? >> >> >> In any case, thank you all for the encouragement that we might not be as >> crazy as I think. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
