On 22-Jun-08, at 12:41 AM, Ralph Goers wrote:
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.
You are used to Apache, Eclipse is not a Utopia and has managed to do
it pretty well. It's a practical upshot of dire need, it's not a "nice
to have" when you have such a large ecosystem, it's a requirement.
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.
I disagree, there are lots of projects that have that notion
engrained. I'm not saying that you are not free to lock down your
version but lots of people use ranges in OSGi with commercial and
Eclipse-based dependencies and they have success.
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.
I fully understand the configuration and behavioral changes also need
to be taken into account.
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.
Where did I say anything resembling the assumption that this happens
everywhere? I'm simply stating it's not as rare as you might think.
I'm also saying use ranges where it makes sense and there is a
difference in how the ranges are used in development versus runtime
and here I'm specifically talking about OSGi. After testing something
and passing through QA it would obviously be not very useful to let
the range calculate something differently after it had been tested.
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.
I'm not disagreeing with you, and if that is what you need then you
just specify that known set in your dependency range. You were saying
it's not supported in the POM, but all you need to do is state the
values in the ranges that you know yourself to be valid for your
project. As you update, leave the previous version in the range if you
know it to be compatible and add the next one.
I wasn't in anyway implying the information is good enough anywhere
but a few places to rely on the "within a major version this remains
API (and behaviorally) compatible." rule. You learn pretty fast where
this is possible or not.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kirosawa
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
