And the staleness is another killer on the: "oh why don't we use DNS records to resolve the repository" because what if foobar.org do not renew their domain, now all the org.foobar artifacts will just drop off the net and we have no means to inject a repo for them again...
I think dropping <repositories> and using social pressure to "get thee to central" is probably the best worst long term solution On 26 June 2014 15:18, Paul Benedict <pbened...@apache.org> wrote: > 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 > > > > >
