On Dec 12, 2008, at 3:26 AM, Jörg Schaible wrote:
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.
They shouldn't be declaring the are compatible with a version range.
If you look at linux system you will see provides and requires used
for characteristics of the artifacts. This is the same idea. For
example, various versions of commons-lang might provide commons-lang-
api-1.0, commons-lang-api-2.0 and/or commons-lang-3.0. They would be
free to declare as many attributes that they wish so that your pom can
require them.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
