>The use case that I've encountered several times is the following:
>- One of my projects needs to use a given plugin with a version higher than
>X because it depends on features introduced or bugs corrected in version X.
>
>
I suspect this is more often a plugin issue than general dependency
problem. In m2, plugins are declared in the POM and are never used as
normal dependencies - and you must generally declare the version of the
plugin you want. This is imperative to making builds reproducible. For
those where it is discovered (there are open issues to actually
implement it for alpha-2), they would be resolved in the POM at release
time.
I suspect that your problem would be solved with this in your company
wide POM:
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.5</version>
</plugin>
</plugins>
</pluginManagement>
Everyone using that current version (everything not released), would be
getting that version of checkstyle, and you'd have one file to update
when that changed.
>Also, I'd love to be able to depend on the last released version of a given
>dependency. That'll allow my continuous build to automatically find out if
>there's a compatibility issue with the latest released dependencies, a la
>Gump. Maybe this is a feature of Continuum but still it impacts the layout
>of the remote repository.
>
>
In general, you could use SNAPSHOTs (which is what gump does). I guess
to only get the latest releases, you'd have to have a repository
containing only releases (which is how Apache separates them now) - but
the current design didn't cover marking a release as the latest SNAPSHOT
(which was briefly noted at the end in a different context). I'll add
this, because I hadn't considered this specific (admittedly unusual!)
use case. This also ties in to the extra note that I specifically
excluded until later - that branches don't really fit the current model.
This is an issue frequently occurring in gump where a project must
maintain two streams.
>I guess this is not really a must-have for the first alpha or beta of m2 but
>I think it makes sense to have it in before a final m2.
>
>
Thanks - I'm sure there'll be plenty more feedback after the first
release. I look forward to it :)
- Brett
