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
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 <[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). >
