Jason van Zyl wrote:
In the world where there is some rigour in that the said project
doesn't change the API within a major release they know very well. In
Eclipse a great deal of care is taken to make sure that APIs don't
change within a major release of the platform and ranges in
dependencies are usually specified as ranges that allow the
consumption of new versions within a major release version. We're not
accustom to this here at Apache because there just isn't that level of
rigour yet.
There are at least hundreds of various software projects that could
possibly become a dependency to a given software development project.
While it is great that Eclipse takes great care to maintain some measure
of compatibility between releases but the same can't be said of the vast
majority of things a project could be dependent on. While it would be
great to live in a Utopian world where API compatibility is rarely, if
ever, broken, that isn't the world we will be living in for the
forseeable future. Expecting a project to understand all the
compatibility issues of its dependencies is not only unreasonable and
burdensome, it is impossible when those dependencies can dynamically
change due to version ranges.
Ironically, although Eclipse might take great care at maintaining
compatibility, none of its components have ever found their way into one
of my projects.
While commercial vendors might be better I've encountered many of the
same issues with them. They will do a "major upgrade" once every 18
months or so and break compatibility if it suits their needs. Only point
upgrades (purely bug fixes - no new features) are guaranteed to be
compatible. Remember, breaking compatibility doesn't necessarily require
an API change. It might involve a configuration change, a change in a
database schema, changes in its dependencies that impact your project in
other ways, etc.
Frankly, even if version ranges worked as above I'd still probably
not use them during a build simply because I want to specify exactly
what is used in the build.
A lot of people probably do too, but that's not what you've been doing
with the POMs you use now I'm willing to bet. Almost everyone with the
mechanism we have now can be subject to exactly what you describe
above without knowing it. Most people don't know the "1.0" in their
POMs doesn't actually mean use "1.0" all the time.
If that's what you think then you forget why I've been so slow in
actually converting my projects from Maven 1 to Maven 2 (which I finally
found the time to do by the way). We used the jar override feature in
Maven 1 to specify the version of EVERY dependency. I wasn't able to
convert to Maven 2 until we could accomplish the same thing - which we
are now able to do in a much better way.
However, if simply specifying a specific version in a managed dependency
doesn't guarantee that the specified version of that dependency is used
then I see three problems:
1. The documentation isn't clear enough.
2. I need to modify my managed dependencies to specify the start and end
of the version range to the same version.
3. Since most people don't expect this behavior one would normally
consider it to be a bug. Certainly forcing people to have to do the
previous step is downright awful. It would be much better to provide an
option that forces only the specified version to be used.
However, it would be great to know that multiple projects have
dependencies on incompatible versions of the same thing. It would
also be great to have reports that indicate which dependencies could
be safely upgraded.
It should be the exception that it changes in a major version.
That's all well and good but it completely misses the point. If you
really think that Maven can cause every possible project that a project
might list as a dependency to do things "correctly" you are going to end
up very frustrated. Maven needs to deal with the world as it is.
Again, I will reiterate. IMO, without projects declaring themselves
which prior versions they are compatible with no version ranging scheme
will ever be able to produce a build you can be even close to 100%
confident in. As always, you are free to disagree.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
