I have to agree with Brian: letting developers use the proxy repo, but
CI/Releases the procured repo (which pulls its content from same proxy
repo that devs uses, but "bureaucratic" rules are applied). This IS a
supported scenario.
But, as with many things in our lives, you can play "Unnatural Acts"
(sic!) with Nexus too...
You could even procure a procured repository ("waterfall" procurement? ;)
Set up "central" repo as proxy for central.
Set up a procured-light repo, as procured for devs (with "light" rule
management applied) using central as target.
Set up a "devs" group and put procured-devs repo into it (and possibly
any other "secure" reposes)
Set up a procured-strong repo, as procured for CI/Release (with
"bureaucratic" rule management applied) using "devs" group as target.
...and so on.
That's it. But it would require a lot of beers to explain me why would
you do it :)
Thanks for appreciating Nexus!
~t~
[1] fav TV series, followed by cultic Mighty Boosh
On Sun, Feb 1, 2009 at 8:19 PM, Brian E. Fox <bri...@reply.infinity.nu> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
