On Sun, 22 Jun 2008 18:16:37 Ralph Goers wrote: > This is one of the problems that has bothered me for a while. It makes > no sense for a project to say I'm compatible with 3.8.x. How in the > world could they know that? The dependent project might release a new > 3.8.x release that isn't compatible. Thus, for any kind of version range > to have any meaning, projects must declare what prior versions they are > compatible with using a declaration that isn't part of the current pom > syntax. Then when a project specifies a dependency on 3.8.1 if there is > a 3.8.2 that specifies it is compatible with any prior 3.8.x release it > would be fine to use 3.8.2 in the project with the dependency. Without > such a specification, in my opinion version ranges aren't particularly > useful. I get around this by wrapping a well defined version around a strict range e.g.
i have a special pom project that holds the version of spring that all my projects should use currently at 7.1 which says use 2.0.7 so all my projects use a range of <dependency> <version>[7,8-!)</version> <groupId>my.domain.constraint</groupId> <artifactId>my.domain.constraint.spring</artifactId> </dependency> and my.domain.constraint.spring is defined in brief as <project ...> ... <dependency> <version>[2.0.7]</version> <groupId>org.springframework</groupId> <artifactId>context</artifactId> </dependency> ... </project> the only overhead to this is a few extra artifacts with no code... hardly a major... there is also the added bonus that you have a convenient place to control exclusions like... commons-logging having read more of the thread... most of the apache projects are small and have fairly simple trees you can get away with locking vrsion down simply. In my case the trees are fairly horendous and using various pattern and refactoring techiniques was necessary to get clean consistent trees. It does mean that I encapsulate the the third party version as shown above and it also lets me guarantee that dependency graph produced by spring, hibernate, jmx, etc etc is the same when used in all my other projects. Each time there is a new release I can just do depedency:resolve and/or depedency:tree and make sure the trees look the same and then run tests on all my projects against the new version to ensure nothing breaks. If something does I can decide to bump the major version of the 'constraint' project or fix the problem in the broken project... i don't think that you can ever make a generic solution to this problem you always need a flexible solution close to home, because ultimately you need to manage when and where things change if you ever hope to produce stable software in a timely fashion. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
