Could you clarify the security requirement? It sounds like you don't want unverified jars entering the development space. Is this correct?
We have simple production builds (no site, no reports). My maven1 cert repository has 210 jar files, 150 of them are external. How are you going to validate this many files? This is a lot of effort just to support a build process. I like maven, but perhaps Ant would be simpler? -C. Helck -----Original Message----- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Sunday, February 01, 2009 5:18 PM To: Maven Users List 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 <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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org ********************************************************************** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the "Information") is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates ("ICAP") or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
