On 5/25/11 3:48 AM, Stephen Connolly wrote:
On 25 May 2011 08:04, Jörg Schaible<[email protected]> wrote:
John Casey wrote:
On 5/24/11 8:25 AM, Brian Fox wrote:
2011/5/24 Arnaud Héritier<[email protected]>:
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.
Exactly.
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...
What if that POM is used as a parent in some other project? Pinning the
version in a parent would change the meaning of that dependency
(slightly), right?
No doubt, pinning would be a nice thing to be able to do, but I think
it's tricky to get right.
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
