External repositories listed in centrally deployed poms?

[Mykel Alvis <my...@weirdness.com>]

Note: I know this sounds a bit like whining.

As a point to generate discussion, I'd like to take a pulse of the group
(and vent a tiny bit).

Having profound difficulty getting maven past my companies firewall, I'm
forced to jump through tiny flaming hoops in order to get even the simplest
builds to work. Currently, it involves what is probably a Career Limiting
Decision on my part, namely that I duplicate my internal repository setup at
home using Proximity and take the source home with me to acquire the
required assets using an unrestricted internet connection.  I then bring the
caches assets back into the office and deploy them to our internal proximity
instance.

Needless to say, this is cumbersome, fraught with peril, and not something
I'd like to keep doing, but it's working (mostly).

As a basis for discussion, I assert the following as given:

1. Maven needs to be accepted in enterprise computing environments for
growth purposes.
2. Most, and all in my experience, enterprise computing environments live
firmly entrenched behind firewalls.
3. Navigating beyond firewalls seems hit-and-miss (I never used to think
this, until it started happening to me and I started paying attention to
other peoples problems with it).
4. In a commercial environment, it is especially important to control what
assets that are accessible to developers, generally for legal reasons.
5. Once a maven application's codebase reaches a certain size, it becomes
even more important and difficult to control those assets due to transitive
dependencies.
6. Every enterprise group I've dealt with for maven use (5 now) have no
intention of allowing their developers free and open access to Internet
based resources.
7. Using an inward-facing caching proxy (like Archive or Proximity or the
maven-proxy) is the correct solution to the problems spawned by #3 and #4

I recently acquired a dependency from central that had a dependency (also in
central), that depends on artifacts (in central) but which defines
(apparently unnecessary) external repositories within the dependency's
parent POM. Why is this such a big deal? Because it means that in order to
prevent the build from failing (non-catastrophically), it's necessary to
pick through a series of parent poms and mirror any listed repositories
internally because I'm mandated to maintain a tight lockdown on assets.
Since it's difficult for me to acquire these assets while I'm in the office,
this isn't that big of a deal as long as I don't mind the build failing.
And solving the issue (this time) was very simple, but it does mean that I'm
mirroring central on the same data cache as the indicated repository
(codehaus in this case), which may come back to bite my behind some day.

My solution:
Central's server (although not necessarily central itself) mirrors many (but
not all) of the major publicly accessible repos (dev java net, eclipse,
codehaus, etc).
Please don't deploy poms into central that list external repositories when
the dependencies they would acquire from the external repo are available on
central.  I'm all for making the build fully portable (even though I
obviously can't do that from work), but making the build less brittle is
also one of the basic drivers for using maven, IMO.  If you're using a
distributable dependency, send it on to central and remove other
repositories from that.  It minimizes the impact to those of us unfortunate
enough to be forced to manually manage their dependency sets and go through
reams of paperwork to attempt unhindered access to m2 repos.

Is codehaus expected to be generally accessible as a repository?
I seem to recall something about plugins heading off to codehaus for assets,
but I can't seem to locate it right now.  If so, I'll need to modify my
proxy a bit.

Anyone have any alternative solutions to this?  Comments on my set of givens
above?  Good oatmeal cookie recipes?

Re: External repositories listed in centrally deployed poms?

[diroussel <na...@diroussel.xsmail.com>]

Christian Goetze-3 wrote:
> 
> ... get screwed by one guy outside accidentally including a dependency 
> with encumbering licensing. That's the big drawback of the automatic 
> inclusion of transitive dependencies.
> 

But maven is powerful enough to allow you to report on the licenses of all
projects in the transitive dependency.

I don't think the current dependencies report does this, but if it bothers
you it wouldn't take long to write.
-- 
View this message in context: http://www.nabble.com/External-repositories-listed-in-centrally-deployed-poms--tf2908859s177.html#a8218063
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: External repositories listed in centrally deployed poms?

[Christian Goetze <cg...@miaow.com>]

Just would like to add my agreement with Mykel's position.

The problem is that you can have the best developers in your world, and 
still get screwed by one guy outside accidentally including a dependency 
with encumbering licensing. That's the big drawback of the automatic 
inclusion of transitive dependencies.

I am very lucky to be in an environment where I actually can download 
anything fron anywhere, but I still remain uncomfortable with this 
aspect of maven. For one, I need to trust the community that it won't 
change anything down the road, and furthermore I need to keep snapshots 
of the repository image for reliable build reproduction purposes.

I believe running maven without at least some proxy setup is asking for 
trouble, even in the most liberal environment.
--
cg

Mykel Alvis wrote:

>> I still maintain, as I have said in other threads, you should audit
>> not enforce lock down.
>
>
>
> Why is that?  It doesn't seem a particularly valid method in my current
> environment, but I'm willing to listen.
>
> I think my developers are competent for the most part, given that 
> they're a
> fairly large group broken into several pieces. But essentially to a
> (gender-nonspecific pronoun) they are not competent with maven, build
> processes in general or the reasons behind the controls associated with
> those processes.
>
> I disagree about the lockdown vs. audit question, but I don't completely
> disagree...except when I'm obligated to do otherwise by the terms of my
> employment.  Like at each  commercial environment that I've worked in for
> the last several years.
>
> I think audits usually work to handle dependency issues, and recommended
> them prior to release.  But my current working dependency set is now over
> 1000 artifacts, and that's just a bit too much to ask. Plus, a couple of
> times before I got here an artifact slipped through the audit cracks so
> caching proxies are the only choice that I can see.   I'm charged with
> working on an "accepted asset" list that would scan checked in poms and
> report checkins that had dependencies not on the list, but that's a few
> steps down the to-do list.
>
> I should also note that there was no instance of distribution of 
> disallowed
> artifacts at previous employers, but they had identical policies.
>
> IANAL, but I do try to keep up with the legalities associated with 
> licensing
> and if you're a largish firm that sells software and somebody catches on
> that you've distributed something unacceptably then it's your buttocks in
> the fire.  That fire would also, very likely, include the firing of 
> me. :)
>
> As for locking down what can and can't be downloaded, it's a moot point.
> Even while I've been mandated to restrict maven's use of external 
> repos, I
> can't help but do it since maven can't actually reach external repos from
> any build host that isn't part of the domain (which includes my entire 
> build
> farm). :(
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: External repositories listed in centrally deployed poms?

[Barrie Treloar <ba...@gmail.com>]

> > I still maintain, as I have said in other threads, you should audit
> > not enforce lock down.
>
>
> Why is that?  It doesn't seem a particularly valid method in my current
> environment, but I'm willing to listen.

>From my understanding, Maven currently has no capabilities to lock
down these artifacts so if you want such a solution you need to go
through the burning hoops you are suggesting and even then I don't
think you will get to the solution you desire.

I often find the desire to "lock down and control" is a knee jerk
reaction to a trust/knowledge issue and that the amount of up front
effort required to put these controls in place far outweighs the
benefits especially when any problems are exceptions not the norm.

Your goal is to verify that your projects are using sanctioned artifacts.
The reasons for this are likely:
1) to provide a stable architecture which you can test against
2) ensure license conformance

Option 1) Somehow lock down maven to only use the sanctioned versions
Effort: Huge

Option 2) Automate the audit process to confirm that your projects use
sanctioned versions
Effort: Less than Huge.

So I would choose to automate the audit process because it is less effort.
The bonus being I have a report that shows the results of the audit,
with a lock down approach there may be some way to circumvent the lock
down.

The only environments I can't see this working for are high security
environments with trusted/untrusted networks. I don't have a solution
for that.

> I think my developers are competent for the most part, given that they're a
> fairly large group broken into several pieces. But essentially to a
> (gender-nonspecific pronoun) they are not competent with maven, build
> processes in general or the reasons behind the controls associated with
> those processes.

I have the same problem but for the most part they don't need to know
this level of details.
They can get away with mvn eclipse:eclipse and the dependencies
correctly setup by a configuration controller or the solution
architect of the project and defined in parent poms.

But providing training is always a good thing because the developers
really should have an appreciation of this process.

> I disagree about the lockdown vs. audit question, but I don't completely
> disagree...except when I'm obligated to do otherwise by the terms of my
> employment.  Like at each  commercial environment that I've worked in for
> the last several years.
>
> I think audits usually work to handle dependency issues, and recommended
> them prior to release.  But my current working dependency set is now over
> 1000 artifacts, and that's just a bit too much to ask. Plus, a couple of
> times before I got here an artifact slipped through the audit cracks so
> caching proxies are the only choice that I can see.   I'm charged with
> working on an "accepted asset" list that would scan checked in poms and
> report checkins that had dependencies not on the list, but that's a few
> steps down the to-do list.

An artifact slipping through the cracks is most likely the result of
oversight by someone.
It would take a super-human effort to manually audit 1000 artifacts
with zero defects.

> IANAL, but I do try to keep up with the legalities associated with licensing
> and if you're a largish firm that sells software and somebody catches on
> that you've distributed something unacceptably then it's your buttocks in
> the fire.  That fire would also, very likely, include the firing of me. :)

There has been talk before about a license manager/scanner.
Since all of the artifacts on the repositories are open source the
only problem would be if the license was one of those that cause your
developed software to also become open source and this is the type of
thing that a licence report could provide.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: External repositories listed in centrally deployed poms?

[Mykel Alvis <my...@weirdness.com>]

On 1/2/07, Barrie Treloar <ba...@gmail.com> wrote:
>
> > 4. In a commercial environment, it is especially important to control
> what
> >assets that are accessible to developers, generally for legal reasons.
> and
> > I often took them at face value until quite recently.  But my latest job
> has
>
> I still maintain, as I have said in other threads, you should audit
> not enforce lock down.


Why is that?  It doesn't seem a particularly valid method in my current
environment, but I'm willing to listen.

I think my developers are competent for the most part, given that they're a
fairly large group broken into several pieces. But essentially to a
(gender-nonspecific pronoun) they are not competent with maven, build
processes in general or the reasons behind the controls associated with
those processes.

I disagree about the lockdown vs. audit question, but I don't completely
disagree...except when I'm obligated to do otherwise by the terms of my
employment.  Like at each  commercial environment that I've worked in for
the last several years.

I think audits usually work to handle dependency issues, and recommended
them prior to release.  But my current working dependency set is now over
1000 artifacts, and that's just a bit too much to ask. Plus, a couple of
times before I got here an artifact slipped through the audit cracks so
caching proxies are the only choice that I can see.   I'm charged with
working on an "accepted asset" list that would scan checked in poms and
report checkins that had dependencies not on the list, but that's a few
steps down the to-do list.

I should also note that there was no instance of distribution of disallowed
artifacts at previous employers, but they had identical policies.

IANAL, but I do try to keep up with the legalities associated with licensing
and if you're a largish firm that sells software and somebody catches on
that you've distributed something unacceptably then it's your buttocks in
the fire.  That fire would also, very likely, include the firing of me. :)

As for locking down what can and can't be downloaded, it's a moot point.
Even while I've been mandated to restrict maven's use of external repos, I
can't help but do it since maven can't actually reach external repos from
any build host that isn't part of the domain (which includes my entire build
farm). :(

-- 
I'm just an unfrozen caveman software developer.  I don't understand your
strange, "modern" ways.

Re: External repositories listed in centrally deployed poms?

[Barrie Treloar <ba...@gmail.com>]

> 4. In a commercial environment, it is especially important to control what
>assets that are accessible to developers, generally for legal reasons.
and
> I often took them at face value until quite recently.  But my latest job has
> driven home the need to maintain tight control on the dependency chains and
> anything that opens that up is anathema to my current happiness.
> The focus on central is obviously because of it's implict inclusion in the
> super pom.  Effectively, it's difficult to remove central as a repo, and
> therefore isn't something you'd do lightly.  Thus anything unnecessary that
> makes an artifact from central more complex is ....ummmm..... an unncessary
> complexity. :)

I still maintain, as I have said in other threads, you should audit
not enforce lock down.

By attempting to control and lock down what can and can't be
downloaded you are just asking for trouble.

It is far easier to assume that your developers are competent and
using sanctioned versions of artifacts and to audit this fact.  Only
when the audit fails do you fix the problem.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: External repositories listed in centrally deployed poms?

[Mykel Alvis <my...@weirdness.com>]

On 1/2/07, Wayne Fay <wa...@gmail.com> wrote:
>
> I believe the Maven dev team has a fairly strict "all dependencies
> should exist on Central" policy for their own artifacts (don't quote
> me). However it is unreasonable to expect that all artifacts in


Too late!  GMail quoted you!  It wasn't me!

You're certainly right about the reality of the situation, but it has
definitely come up at the last three sites I've worked as a concern of
management, not of the developers.  In my current case, it's the current
version of the site plugin that depends on jetty that defines additional
repos in it's parent's pom.  It doesn't depend on them, it just defines
them.  All of the artifacts needed are mirrored to central, but probably not
at development time and likely not at deployment time, which is probably
very convenient from outside this oubliette I'm working in now.  I know that
I certainly haven't ever had an issue with it until I ended up behind a
firewall with no way out.
Finally, of course, it's a part of the overall "the metadata needs to
improve" thread that runs through the lists occasionally.

I'm not quite sure how you deal with the following issue:
> Artifact ABC lives in java.net repo
> ABC pom.xml points to java.net repo for its dependencies (X, Y, and Z)
> Java.net repo is mirrored to Central
> ABC pom.xml on Central now points to java.net repo for its
> dependencies, although they should generally also exist on Central due
> to the mirroring



For my purposes, depending on how complex the issue was, I'd probably
redeploy the artifact on my internal repositories with a modified pom.  Much
like the way  I'm doing it now, it's clearly not optimal but it does allow
me to limit my remote accesses.  If it's a lot of stuff to host, then it's a
lot of stuff to deal with and that's just that.  It's not that I won't do
the hosting, I just want to be able to automate the process of it.  Using a
proxy, I can build a locally accessible cache that doesn't need to make
outside trips.

Frankly, I simply don't see the need for the several multiple remotes. I
undertand the motivation behind them (i.e. control), but I don't necessarily
agree with it.  Since there's not an "Accept this pom" segment of the maven
build process, if the pom is off a bit (or worse, blatantly wrong) you're
left with tracking down what's awry in the project metadata.  This was one
thing maven helps us avoid.
I suppose that's whey they call it work and pay us to do it... :)


Or would you expect the "mirror java.net to Central" process to alter
> all the pom files and remove the java.net repo references?


I'm not sure what I expect, other than that I have ideals that I never
expect to reach. :)

Ideally, any artifact deployed to central would have a pom that precisely
defines its dependencies and nothing else.  We implicitly depend a great
deal on these dependencies during the course of development, and admittedly
I often took them at face value until quite recently.  But my latest job has
driven home the need to maintain tight control on the dependency chains and
anything that opens that up is anathema to my current happiness.
The focus on central is obviously because of it's implict inclusion in the
super pom.  Effectively, it's difficult to remove central as a repo, and
therefore isn't something you'd do lightly.  Thus anything unnecessary that
makes an artifact from central more complex is ....ummmm..... an unncessary
complexity. :)

Mykel


> On 1/2/07, Mykel Alvis <my...@weirdness.com> wrote:
> > Note: I know this sounds a bit like whining.
> >
> > As a point to generate discussion, I'd like to take a pulse of the group
> > (and vent a tiny bit).
> >
>

Re: External repositories listed in centrally deployed poms?

[Carlos Sanchez <ca...@apache.org>]

On 1/2/07, Wayne Fay <wa...@gmail.com> wrote:
> I believe the Maven dev team has a fairly strict "all dependencies
> should exist on Central" policy for their own artifacts (don't quote
> me). However it is unreasonable to expect that all artifacts in
> Central depend solely on other artifacts available on Central. I agree
> with you in principle -- I just don't see it happening in the real
> world.

That's the policy right now for upload bundles. The problem is with
files coming from synced repos.

>
> I'm not quite sure how you deal with the following issue:
> Artifact ABC lives in java.net repo
> ABC pom.xml points to java.net repo for its dependencies (X, Y, and Z)
> Java.net repo is mirrored to Central
> ABC pom.xml on Central now points to java.net repo for its
> dependencies, although they should generally also exist on Central due
> to the mirroring
>
> Or would you expect the "mirror java.net to Central" process to alter
> all the pom files and remove the java.net repo references?
>
> Wayne
>
> On 1/2/07, Mykel Alvis <my...@weirdness.com> wrote:
> > Note: I know this sounds a bit like whining.
> >
> > As a point to generate discussion, I'd like to take a pulse of the group
> > (and vent a tiny bit).
> >
> > Having profound difficulty getting maven past my companies firewall, I'm
> > forced to jump through tiny flaming hoops in order to get even the simplest
> > builds to work. Currently, it involves what is probably a Career Limiting
> > Decision on my part, namely that I duplicate my internal repository setup at
> > home using Proximity and take the source home with me to acquire the
> > required assets using an unrestricted internet connection.  I then bring the
> > caches assets back into the office and deploy them to our internal proximity
> > instance.
> >
> > Needless to say, this is cumbersome, fraught with peril, and not something
> > I'd like to keep doing, but it's working (mostly).
> >
> > As a basis for discussion, I assert the following as given:
> >
> > 1. Maven needs to be accepted in enterprise computing environments for
> > growth purposes.
> > 2. Most, and all in my experience, enterprise computing environments live
> > firmly entrenched behind firewalls.
> > 3. Navigating beyond firewalls seems hit-and-miss (I never used to think
> > this, until it started happening to me and I started paying attention to
> > other peoples problems with it).
> > 4. In a commercial environment, it is especially important to control what
> > assets that are accessible to developers, generally for legal reasons.
> > 5. Once a maven application's codebase reaches a certain size, it becomes
> > even more important and difficult to control those assets due to transitive
> > dependencies.
> > 6. Every enterprise group I've dealt with for maven use (5 now) have no
> > intention of allowing their developers free and open access to Internet
> > based resources.
> > 7. Using an inward-facing caching proxy (like Archive or Proximity or the
> > maven-proxy) is the correct solution to the problems spawned by #3 and #4
> >
> > I recently acquired a dependency from central that had a dependency (also in
> > central), that depends on artifacts (in central) but which defines
> > (apparently unnecessary) external repositories within the dependency's
> > parent POM. Why is this such a big deal? Because it means that in order to
> > prevent the build from failing (non-catastrophically), it's necessary to
> > pick through a series of parent poms and mirror any listed repositories
> > internally because I'm mandated to maintain a tight lockdown on assets.
> > Since it's difficult for me to acquire these assets while I'm in the office,
> > this isn't that big of a deal as long as I don't mind the build failing.
> > And solving the issue (this time) was very simple, but it does mean that I'm
> > mirroring central on the same data cache as the indicated repository
> > (codehaus in this case), which may come back to bite my behind some day.
> >
> > My solution:
> > Central's server (although not necessarily central itself) mirrors many (but
> > not all) of the major publicly accessible repos (dev java net, eclipse,
> > codehaus, etc).
> > Please don't deploy poms into central that list external repositories when
> > the dependencies they would acquire from the external repo are available on
> > central.  I'm all for making the build fully portable (even though I
> > obviously can't do that from work), but making the build less brittle is
> > also one of the basic drivers for using maven, IMO.  If you're using a
> > distributable dependency, send it on to central and remove other
> > repositories from that.  It minimizes the impact to those of us unfortunate
> > enough to be forced to manually manage their dependency sets and go through
> > reams of paperwork to attempt unhindered access to m2 repos.
> >
> > Is codehaus expected to be generally accessible as a repository?
> > I seem to recall something about plugins heading off to codehaus for assets,
> > but I can't seem to locate it right now.  If so, I'll need to modify my
> > proxy a bit.
> >
> > Anyone have any alternative solutions to this?  Comments on my set of givens
> > above?  Good oatmeal cookie recipes?
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: External repositories listed in centrally deployed poms?

[Christian Goetze <cg...@sensage.com>]

Wayne Fay wrote:

> Or would you expect the "mirror java.net to Central" process to alter
> all the pom files and remove the java.net repo references?

I think that they should not contain explicit location references at 
all, relying instead on the locations defined in the poms traversed 
previously in your transitive dependency search.

I also think that the maven proxy solution should be advocated, if not 
required, and that the maven proxy should be an integral part of maven, 
not something fabricated by third parties.
--
cg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: External repositories listed in centrally deployed poms?

[Wayne Fay <wa...@gmail.com>]

I believe the Maven dev team has a fairly strict "all dependencies
should exist on Central" policy for their own artifacts (don't quote
me). However it is unreasonable to expect that all artifacts in
Central depend solely on other artifacts available on Central. I agree
with you in principle -- I just don't see it happening in the real
world.

I'm not quite sure how you deal with the following issue:
Artifact ABC lives in java.net repo
ABC pom.xml points to java.net repo for its dependencies (X, Y, and Z)
Java.net repo is mirrored to Central
ABC pom.xml on Central now points to java.net repo for its
dependencies, although they should generally also exist on Central due
to the mirroring

Or would you expect the "mirror java.net to Central" process to alter
all the pom files and remove the java.net repo references?

Wayne

On 1/2/07, Mykel Alvis <my...@weirdness.com> wrote:
> Note: I know this sounds a bit like whining.
>
> As a point to generate discussion, I'd like to take a pulse of the group
> (and vent a tiny bit).
>
> Having profound difficulty getting maven past my companies firewall, I'm
> forced to jump through tiny flaming hoops in order to get even the simplest
> builds to work. Currently, it involves what is probably a Career Limiting
> Decision on my part, namely that I duplicate my internal repository setup at
> home using Proximity and take the source home with me to acquire the
> required assets using an unrestricted internet connection.  I then bring the
> caches assets back into the office and deploy them to our internal proximity
> instance.
>
> Needless to say, this is cumbersome, fraught with peril, and not something
> I'd like to keep doing, but it's working (mostly).
>
> As a basis for discussion, I assert the following as given:
>
> 1. Maven needs to be accepted in enterprise computing environments for
> growth purposes.
> 2. Most, and all in my experience, enterprise computing environments live
> firmly entrenched behind firewalls.
> 3. Navigating beyond firewalls seems hit-and-miss (I never used to think
> this, until it started happening to me and I started paying attention to
> other peoples problems with it).
> 4. In a commercial environment, it is especially important to control what
> assets that are accessible to developers, generally for legal reasons.
> 5. Once a maven application's codebase reaches a certain size, it becomes
> even more important and difficult to control those assets due to transitive
> dependencies.
> 6. Every enterprise group I've dealt with for maven use (5 now) have no
> intention of allowing their developers free and open access to Internet
> based resources.
> 7. Using an inward-facing caching proxy (like Archive or Proximity or the
> maven-proxy) is the correct solution to the problems spawned by #3 and #4
>
> I recently acquired a dependency from central that had a dependency (also in
> central), that depends on artifacts (in central) but which defines
> (apparently unnecessary) external repositories within the dependency's
> parent POM. Why is this such a big deal? Because it means that in order to
> prevent the build from failing (non-catastrophically), it's necessary to
> pick through a series of parent poms and mirror any listed repositories
> internally because I'm mandated to maintain a tight lockdown on assets.
> Since it's difficult for me to acquire these assets while I'm in the office,
> this isn't that big of a deal as long as I don't mind the build failing.
> And solving the issue (this time) was very simple, but it does mean that I'm
> mirroring central on the same data cache as the indicated repository
> (codehaus in this case), which may come back to bite my behind some day.
>
> My solution:
> Central's server (although not necessarily central itself) mirrors many (but
> not all) of the major publicly accessible repos (dev java net, eclipse,
> codehaus, etc).
> Please don't deploy poms into central that list external repositories when
> the dependencies they would acquire from the external repo are available on
> central.  I'm all for making the build fully portable (even though I
> obviously can't do that from work), but making the build less brittle is
> also one of the basic drivers for using maven, IMO.  If you're using a
> distributable dependency, send it on to central and remove other
> repositories from that.  It minimizes the impact to those of us unfortunate
> enough to be forced to manually manage their dependency sets and go through
> reams of paperwork to attempt unhindered access to m2 repos.
>
> Is codehaus expected to be generally accessible as a repository?
> I seem to recall something about plugins heading off to codehaus for assets,
> but I can't seem to locate it right now.  If so, I'll need to modify my
> proxy a bit.
>
> Anyone have any alternative solutions to this?  Comments on my set of givens
> above?  Good oatmeal cookie recipes?
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org