you can stage the process
online hours Server1 pulls any/all necessary poms/jars/wars/ears/properties
8am server1 run every AntiVirus on the planet against downloaded files
9am server1 becomes accessible locally
Now you can set your localRepository to server1 e.g.
<settings>
<localRepository>/server1</localRepository>
</settings>
<!-- if no basic authentication is required setup server1 to be a non-proxied
hosts -->
<proxies>
<proxy>
<active>true</active>
<protocol>http</protocol>
<host>proxy.somewhere.com</host>
<port>8080</port>
<username>proxyuser</username>
<password>somepassword</password>
<nonProxyHosts>www.google.com|server1</nonProxyHosts>
</proxy>
</proxies>
advice?
Martin Gainty
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business
of Sender. This transmission is of a confidential nature and Sender does not
endorse distribution to any party other than intended recipient. Sender does
not necessarily endorse content contained within this transmission.
> Date: Sun, 1 Feb 2009 17:17:56 -0500
> From: [email protected]
> To: [email protected]
> Subject: Re: Maven for the internet afraid
>
> 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]
>
_________________________________________________________________
Windows Live™: E-mail. Chat. Share. Get more ways to connect.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009
