We envision a process where we periodically reevaluate our needs,
gathering all artifacts we'll use until the next assessment.
In summary, that is simply impractical; we need a different approach.
Saying that at work lately, I've felt like Cassandra, but I'll be glad
to admit if I'm wrong...
Tamás Cservenák wrote:
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 <[email protected]> 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:[email protected]]
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 <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
