On 25 May 2011 08:04, Jörg Schaible <joerg.schai...@scalaris.com> wrote:
> John Casey wrote:
>
>>
>>
>> On 5/24/11 8:25 AM, Brian Fox wrote:
>>> 2011/5/24 Arnaud Héritier<aherit...@gmail.com>:
>>>> Before talking about a specific change in the model like the addition of
>>>> mixins (which may be cool but not critical) did we :
>>>> - studied that we had everything necessary to manage new versions of
>>>> POMs with something a little bit dynamic inside the core and all that is
>>>> necessary on repositories side ?
>>>> - studied if we couldn't start by really simple issues that may already
>>>> do a very useful 3.1 version like the addition of global exclusions ?
>>>>
>>>
>>> I didn't read the proposal in detail yet, but my initial concern was
>>> on pom compat as well.
>>
>> I think doing some sort of on-the-fly translation into a 4.0.0 POM
>> purely to be deployed for backwards compat would be enough here...though
>> we may want to explore how we could make Maven smart enough to say, "I
>> can't read this POM, use a later version" or somesuch...
>
> Hmmm. And what about semantical compatibility? E.g. if a newer pom version
> declares global excludes, the resulting target might be completely different
> if you build with an older Maven version. This might even be the case if one
> of the dependencies is using a newer POM only. I just want to emphasis that
> such a change is not of technical nature only.

The idea is that the 4.0.0 pom that gets deployed would have all the
donkey work of emulating global excludes done for you, so the 5.0.0
pom would have the global excludes and the 4.0.0 version would have
all the dependencies with the necessary excludes added to each
dependency that requires it.

I think it will also be necessary to rethink dependencies somewhat,
with respect to ranges at least.

I think that releases should pin ranges, and such a pinning would
simplify the generated 4.0.0 pom because we don't have to worry about
a dependency being pulled in by a different version of something that
didn't have the dependency at the time of deployment...

By pinning though I'm not sure whether we want to hard pin, e.g.
<version>[1.0.0]</version> or soft pin, e.g. <version>1.0.0</version>

I have not seen a good use of hard pinning outside of a container that
can handle hard pinning, e.g. OSGi, and even then I may want to
override the hard pin with the 1.0.1 bug fix release, so I suspect we
just want to soft-pin versions

>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to