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
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 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 wrote:
>>>
>>>
>>>
>>>> So, in my quest to take Maven completely internal, I'm still
>>>> grappling with a coup
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.
/server1
true
http
proxy.somewhere.com
8080
proxyuser
somepassword
www.google.com|server1
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
> > 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
> >>
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 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 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.
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 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 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 --&g
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 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 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 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
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 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
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
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
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
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
On Thu, Jan 29, 2009 at 9:27 PM, Merv Green 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
