On Tue, 2008-12-09 at 00:25 -0700, Jörg Schaible wrote: > Hi Ian, [snip > Nothing can really keep you save from such incompatibilities and problems > anyway. You silently imply that a higher version is always compatible, but > that's also not true (you know). In really worse cases it is like the > incompatible ASM 1.x, 2.x and 3.x series, but even for such an innocent > upgrade from JUnit 3.8.1 to 3.8.2 you might get a surprise, because the > latter uses a method not available in JDK 1.3 runtime. And this does not > cover cases where the groupId for the artifact changes (e.g. > xstream:xstream:1.1.3 com.thoughtworks.xstream:xstream:1.2) or artifacts > are splitted and/or renamed (e.g. avalon:avalon-framwork:4.1.4 to > org.apache.avalon:framework-api:4.3.1 and > org.apache.avalon:framework-impl:4.3.1) or two artifacts deliver the same > classes (commons-logging:commons-logging:1.1.1 and > org.slf4j:slf4j-jcl:1.5.6) or a jar is consumed by a different one (e.g. > org.ajax4jsf:ajax4jsf:1.1.0 into org.richfaces:richfaces:3.1.0) or consumed > even by the JDK (javax.activation:activation:1.0.2 in JDK 6). These are all great examples. But the current practice of choosing the highest mutually acceptable version (absent a mutually acceptable suggested version) rather than the lowest only serves to aggravate the problem, since as projects evolve through successive versions, the odds of backwards incompatibilities increase. If the maven community feels that version ranges are never acceptable, then they should be removed, or at least clearly documented as deprecated. However, if ranges are being kept (and judging from the Mercury docs, it appears they will be), then lets try to make them as useful as possible.
> Therefore it is always the developers task to take care of the complete > dependency tree of a product/project. Of course. But if the developer is depending on a project with a good track record of backwards compatibility (which many have), then it seems only polite to offer them some useful automated support for managing the version of that project. Occasionally, the result will require a manual override, but how is that worse than any of current mechanisms maven provides? - Ian CONFIDENTIALITY NOTICE: This message is intended only for the use and review of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message solely to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone or return email. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
