I agree with Jorg. Furthermore, I have found repositories addresses change overtime. I *don't* want this information in the POM either because it becomes stale. It's not really build information, per se, as it is Maven connection information. I have to fallback to modifying my settings.xml when I encounter one of these situations -- which is "smell" enough of this very issue.
Cheers, Paul On Thu, Jun 26, 2014 at 9:11 AM, Jörg Schaible <joerg.schai...@swisspost.com > wrote: > Hi Mark, > > Mark Derricutt wrote: > > > In last weeks dev hangout I raised the idea of removing <repository> > > elements due to some issues with them regarding mirrors etc which was > > somewhat negatively received, however I've been thinking about this a > > bit and came up with an interesting idea earlier in the night whilst at > > a gig. > > > > One of the problems I'm often seeing is that: > > > > 1) a project uploads their artefact to a repository ( mostly maven > > central ) > > 2) 90% of their dependencies are available from the repository in > > question > > 3) 1 critical dependency is not - which ultimately means you can't > > build......if you have a mirror setup > > > > (usually because you've not noticed a <repository> declaration which you > > need to configure in your nexus/arifactory/archiva etc. ) > > > > The idea I had is three fold: > > > > 1) Fallback on original repository when a mirror doesn't resolve > > > > When maven is checking for a repository for an artefact, and using a > > mirror - if that artefact can't be found, maven should retry using the > > original repository directly with builds warnings. > > > Very bad idea. Especially if the original repo is not/no longer reachable > and you have to wait for a timeout. And you can no longer control with an > Archive Manager what actually is used from where. > > > > 2) Deploy transitive runtime dependencies along with your release > > > > We currently have the <distributionManagement> section of a pom > > declaring the deploy repository. If we added a new `deploy-dependencies` > > goal to some plugin and updated maven-release-plugin with a this in its > > default deployment goals, I think some magical things could happen: > > > > - Find the _runtime_ dependency tree of your project > > - Check which artefacts don't exist on the deployment repo > > - Deploy those artefacts out to the repository - essentially an > > implicit mirroring your dependencies. > > > > At the same time, modify the POM reader to add the repository defined in > > `<distributionManagement>` as a `<repository>` for discovering > > dependencies. > > > > Any thoughts on this? Since it's now 12:32am, _hopefully_ I'll be awake > > in time to join the discussion tomorrow to raise this idea. > > > And suddenly we have all kind of stuff in public repos that are not allowed > to be distributed. > > IMHO, the best option *is* actually to remove the <repository> elements. > > - Jörg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
