+1
Thinking about it - I like the idea of a (for lack of a better name)
~/.m2/resolutions.xml that provides control over the resolver.
First thoughts that come to mind:
- missing or empty file - existing 2.x behaviour, -SNAPSHOTS resolved
across the board.
- profile based (optional?)
Maybe something like:
<resolutions>
<resolution>
<groupId>com.smxemail.*</groupId>
<artifactId>.*</artifactId>
<snapshots>
<enabled>true</enabled>
</snapshots>
</resolution>
<profiles>
<profile>
<id>release</id>
<resolutions>
<resolution>
<groupId>.*</groupId>
<artifactId>.*</artifactId>
<snapshots>
<enabled>false</enabled>
</snapshots>
</resolution>
</resolutions>
</profile>
</profiles>
</resolutions>
As much as I hate mavens use of elements only, the above conforms to the
current "standard" - a somewhat mix between a dependency and a repository
definition. I like the notion of enabling resolution based on profile,
which is already an accepted way of dynamically altering pom resolution.
What do you guys think of something like this? If something like this was
adopted, would it be doable for 3.0? ( having no clue as to how many layers
of maven these things affect ).
mark
--
Pull me down under...
On Thu, Sep 16, 2010 at 1:10 AM, Jason van Zyl <ja...@sonatype.com> wrote:
> > The approach that I could think of to sufficiently address this issue
> requires quite some rework of the settings.xml or better a different file in
> order to not break side-by-side use of Maven 2.x and 3.x. Given that we want
> to release 3.0 soon, I will probably just rollback the changes for MNG-3092
> and restore 2.x behavior, i.e. always include snapshots in ranges, and
> postpone a more robust solution to 3.1.
> >
>
> +1
>
> This is just more consistent with 3.0 being backward compatible, and making
> the whole scenario of SNAPSHOTs for CI and integration and blocking them
> from releases will take some more thinking. Only one person has complained
> but I posit 95% of Maven users aren't going to try Maven 3.x until 3.0 is
> released.
>
