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 <[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]
