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