Hi Ralph,

Ralph Goers wrote at Freitag, 12. Dezember 2008 04:23:

> I agree with this. But even with managed dependencies there are still
> problems. Even though you have dictated the version you really have no
> idea if it is compatible with the version needed by the artifact
> trying to use it.

you do never know. I doubt that a lot of projects actually try all revisions
of a dependency that are supposed to be compatible. Standrad procedure is
to declare one and use it for release. If you have 3 dependend artifacts
and all of those declare a dep to commons-lang in distinct versions, I
actually prefer no ranges here, since then I know at least what was used to
create the released artifact. It is my knowledge that I may *normally*
safely override the version in the depMgmnt section. However, I cannot be
*sure*. There might be always some undefined/changed internal behaviour in
commons-lang which exposes a problem now in one of the dependent artifacts.
Point is that even the party that produced one of those artifacts only
tested one special version of commons-lang and it does not really help you
if they declare their artifact to be compatible with a version range, since
they also only make an assumption.

> I have been advocating for some time that 3.0 support "requires" and
> "provides". Jason has assured me that it will make it into one of the
> 3.0 milestone releases. When used by artifacts this would allow Maven
> to pick the latest version from a range that provides all the required
> attributes. When used with a managed dependency it could report an
> error if the artifact being overridden has incompatible requirements
> with the managed dependency.
> 
> With 2.0.x no one should expect any real improvement in this as it
> would break too many things.

The only reason why I would use a version range is for known incompatible
artifacts like ASM where you can define a range for 1.x, 2.x or 3.x.

- Jörg


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

Reply via email to