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.

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.

Cheers,
Mark

Reply via email to