2009/11/16 Kalle Korhonen <kalle.o.korho...@gmail.com>: > There's been quite a few threads on declaring Maven repos in poms, > most of them referring to Brian's blog post > http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/. > I agree with that 100%, but as you mention Brian, it's not black and > white for open source projects. I ran into the same issue again while > working on http://bamboo.ci.codehaus.org/browse/TYNAMO-SEEDENTITY-1. > The module depends on some artifacts located in Jboss repo. Their repo > is not synched to repo1 but artifacts originating from JBoss may or > may not be deployed to repo1 depending on version and project. I'm > naturally running my own nexus instance for my team's needs but > anybody else just checking out the module from svn or a CI system that > I'm not in control of (as in this case, it's Codehaus Bamboo instance) > will have a problem building this module. > > To avoid "burning the entries forever into my released POMs" I figured > I could just the declare the repositories in a profile, for example > named "repositories". Technically they would still be in the pom but > wouldn't be used in normal dependency resolution, only if the user > specifically activated it. Since I typically never depend on external > snapshots, the profile would only be needed roughly once per set-up, > and it would also be easy to document and users to use. Brian, others, > do you think this would be a good idea for best practice? Better than > declaring them by default or not declaring them at all (and thus > either trying to strictly use only modules available in repo1, > lobbying required libs to be deployed to repo1 or just having to > document this for users and lobbying CI administrators to proxy > additional Maven repos)?
The issue is that some repositories have different versions of artifacts deployed for the same version number. If you download the artifact from repoA it will never be re-downloaded even if repoA is no longer in your list of repositories and repoB has a different binary. This is especially an issue with java.net, but other (non repo1.maven.org) repositories have the same issue. We even have the issue internally, there are one or two artifacts that, for historical reasons (when we built with m1) have versions with a different binary from the artifact on repo1. Our internal nexus instance resolves these for us, and we have verified that the differences are just that our version was compiled with java 1.4.2 on dd/mm/yyyy with debug info off and optimization on, while the public one was compiled with java 1.4.1 on d2/m2/yyy2 with debug info on and optimization off.... But there are bigger conflicts out there (especially on java.net). repo1 may be a mess, but it's the only repo with rules, and as such, your build will be more stable if you only depend on repo1. -Stephen > > Kalle > > --------------------------------------------------------------------- > 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
