On 1/2/07, Wayne Fay <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
