RE: Maven for the internet afraid
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
Re: Maven for the internet afraid
Chris Helck wrote: Could you clarify the security requirement? It sounds like you don't want unverified jars entering the development space. Is this correct? That is essentially correct. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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
RE: Maven for the internet afraid
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
Re: Maven for the internet afraid
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
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
RE: Maven for the internet afraid
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 activetrue/active protocolhttp/protocol hostproxy.somewhere.com/host port8080/port usernameproxyuser/username passwordsomepassword/password nonProxyHostswww.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: paradeofh...@gmail.com To: users@maven.apache.org 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
RE: Maven for the internet afraid
That's one reason why I run Nexus locally when I travel, because the offline mode breaks lots of plugins. -Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Friday, January 30, 2009 10:28 PM To: users@maven.apache.org Subject: RE: Maven for the internet afraid you're going to have to reconfig ALL your plugins to use a localRepository this is a massive PITA and documentation is thin maven expects a clear path to ALL scp or sftp or https servers 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. Subject: RE: Maven for the internet afraid Date: Fri, 30 Jan 2009 22:04:36 -0500 From: bri...@reply.infinity.nu To: users@maven.apache.org This use case was exactly what the Procurement in Nexus was designed to support. It allows you to definitively control the artifacts used by your builds. The only alternative is to manage it my hand, which is labor intensive and error prone. http://www.sonatype.com/products/nexus -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Thursday, January 29, 2009 11:28 PM To: users@maven.apache.org Subject: Maven for the internet afraid Asking this embarrasses me, but must be done. I work for a company where the internet terrifies Them. They want to use Maven, but they think it should never go online, so they want a locked down internal repository containing whatever artifacts some couple hundred developers might need. Can we, as I believe, not effectively use Maven this way? If so, what are the alternatives? I see a few: 1. Only worry about the release bundle Compare dependency reports in continuous integration to some approved jar list, flagging anomalies along the way. Once ready for release, run some thorough check on the jar-with-dependencies. 2. wget all of Central A blunt instrument, but it would more or less work. How, though, do I go to the people who vet jars and say, Hey, someone might someday need some of these... 3. Build against some proxy repo for a while, then block it Obvious problems ensue. - 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 _ Windows Live(tm): E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_ 012009 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for the internet afraid
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
Re: Maven for the internet afraid
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
RE: Maven for the internet afraid
This use case was exactly what the Procurement in Nexus was designed to support. It allows you to definitively control the artifacts used by your builds. The only alternative is to manage it my hand, which is labor intensive and error prone. http://www.sonatype.com/products/nexus -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Thursday, January 29, 2009 11:28 PM To: users@maven.apache.org Subject: Maven for the internet afraid Asking this embarrasses me, but must be done. I work for a company where the internet terrifies Them. They want to use Maven, but they think it should never go online, so they want a locked down internal repository containing whatever artifacts some couple hundred developers might need. Can we, as I believe, not effectively use Maven this way? If so, what are the alternatives? I see a few: 1. Only worry about the release bundle Compare dependency reports in continuous integration to some approved jar list, flagging anomalies along the way. Once ready for release, run some thorough check on the jar-with-dependencies. 2. wget all of Central A blunt instrument, but it would more or less work. How, though, do I go to the people who vet jars and say, Hey, someone might someday need some of these... 3. Build against some proxy repo for a while, then block it Obvious problems ensue. - 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
RE: Maven for the internet afraid
you're going to have to reconfig ALL your plugins to use a localRepository this is a massive PITA and documentation is thin maven expects a clear path to ALL scp or sftp or https servers 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. Subject: RE: Maven for the internet afraid Date: Fri, 30 Jan 2009 22:04:36 -0500 From: bri...@reply.infinity.nu To: users@maven.apache.org This use case was exactly what the Procurement in Nexus was designed to support. It allows you to definitively control the artifacts used by your builds. The only alternative is to manage it my hand, which is labor intensive and error prone. http://www.sonatype.com/products/nexus -Original Message- From: Merv Green [mailto:paradeofh...@gmail.com] Sent: Thursday, January 29, 2009 11:28 PM To: users@maven.apache.org Subject: Maven for the internet afraid Asking this embarrasses me, but must be done. I work for a company where the internet terrifies Them. They want to use Maven, but they think it should never go online, so they want a locked down internal repository containing whatever artifacts some couple hundred developers might need. Can we, as I believe, not effectively use Maven this way? If so, what are the alternatives? I see a few: 1. Only worry about the release bundle Compare dependency reports in continuous integration to some approved jar list, flagging anomalies along the way. Once ready for release, run some thorough check on the jar-with-dependencies. 2. wget all of Central A blunt instrument, but it would more or less work. How, though, do I go to the people who vet jars and say, Hey, someone might someday need some of these... 3. Build against some proxy repo for a while, then block it Obvious problems ensue. - 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 _ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_012009
Maven for the internet afraid
Asking this embarrasses me, but must be done. I work for a company where the internet terrifies Them. They want to use Maven, but they think it should never go online, so they want a locked down internal repository containing whatever artifacts some couple hundred developers might need. Can we, as I believe, not effectively use Maven this way? If so, what are the alternatives? I see a few: 1. Only worry about the release bundle Compare dependency reports in continuous integration to some approved jar list, flagging anomalies along the way. Once ready for release, run some thorough check on the jar-with-dependencies. 2. wget all of Central A blunt instrument, but it would more or less work. How, though, do I go to the people who vet jars and say, Hey, someone might someday need some of these... 3. Build against some proxy repo for a while, then block it Obvious problems ensue. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for the internet afraid
On Thu, Jan 29, 2009 at 9:27 PM, Merv Green paradeofh...@gmail.com wrote: Asking this embarrasses me, but must be done. I work for a company where the internet terrifies Them. They want to use Maven, but they think it should never go online, so they want a locked down internal repository containing whatever artifacts some couple hundred developers might need. Can we, as I believe, not effectively use Maven this way? It _can_ work, and it's actually a very good idea. You are not alone. :) Run a repository manager (Archiva, Nexus, Artifactory) internally, and tightly control its contents. Establish some process for developers to request uploads to the repo, and have the team responsible for that go through the motions of retrieving the artifacts, verifying the signatures, etc., then uploading. You can usually upload through the web interface of the repo manager. For larger uploads (a plugin and its bunch of dependencies) I've had good luck using the assembly plugin to package all the artifacts in remote repo format, then copying that into the managed repo. Where I am, a governance board controls open source and third party dependencies. They review the license as well as consider whether it's something that they want used within the development organization. Access to external repos is prevented by the settings.xml in our custom Maven distribution, so that everything builds against the approved artifacts in the internal repos. If there's a really huge new project coming on, you might configure a separate repo and let that proxy central for a while, then shut it down and go through everything it has proxied to determine what needs to be moved into the approved repo. HTH, -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
