On Sun, 2008-05-25 at 18:28 +0200, Giovanni Azua wrote: > Hi Simon, > > Many thanks to you all for the replies! > > The issue here is reliability and reproducibility of the builds. > > 1) Locking down versions is needed for reproducibility of the builds. If > maven decides silently for you what the resolution of conflicts is going to > be, most likely you will end up with a runtime time bomb just waiting to > blow. Very likely one of the two dependencies (A or B) will fail with > whatever the C selected version C is. IMO the most sensitive thing to do in > this scenario would be to have maven breaking the build explaining the > conflict and letting the user fix the dependencies. If maven silently > decides, the only provision developers have against runtime troubles is > having high test coverage in place, assuming high test coverage is usually > wishful thinking.
Building of poms is already deterministic, as long as no dependency has a SNAPSHOT version [1]. It is an error in maven if a dependency is specified without a version. The version can be a "recommendation" type version, ie no range specified, but even with this it is still 100% deterministic which version you get. Having poms for library projects lock down their dependencies to an exact version would be a nightmare. It would soon be completely impossible to assemble any set of jars which have compatible dependencies. By your rule, any lib that declares a dependency on commons-logging 1.1 would be unusable with any lib that declares a dependency on commons-logging-1.1.1. But they *are* compatible. When you start a new project, ie create a pom with a set of direct dependencies, Maven's transient dependency resolution *deterministically* pulls together a set of libs that have a pretty good chance of being what are needed. It is possible that there are some incompatibilities in there, but the top-level pom can then tweak things as needed. As pointed out in earlier replies, a dependency declaration with a *lower depth* overrides others, so declarations in the top-level pom override all transient declarations (except ones with ranges). And "mvn dependency:tree" shows exactly what is going on. A decent set of unit tests for a project *is* the correct way to handle this situation, verifying that the selected libs do function together correctly. > > 2) Using md5sum is a safer way to ensure that the same specific release is > being pulled e.g. an scenario like the one explained in the OP. Using md5sum > also favors reproducibility, and it is specially useful in places where the > same release version of a component is re-released several times (I work in > one of those places) whereas in maven it implies you diligently provide a > new different version each time. AFAIK there is nothing in Maven that > prevents from re-releasing the same version number/label several times, > therefore it is a Pandora Box against reproducibility of builds. The main maven repository has a policy of never overwriting a release. When version X of a library is installed into the central maven repository, you can 100% rely on that never changing. The only exception is a SNAPSHOT release. But those don't promise repeatable builds. It is strongly recommended that you follow the same policy for your own repositories. Don't re-release artifacts with the same version number (except for SNAPSHOTs). You can probably enforce this by setting the appropriate UMASK for your repository, ie making sure that files in the repository do not have write permission. I suppose it might be nice to be able to write <dependency> <groupId>example</groupId> <artifactId>widget</artifactId> <version>[1.2]</version> <md5sum>DEADBEEF</md5sum> </dependency> and have an error if the downloaded file doesn't match the checksum. That would indeed be an absolute check that the file is the expected one. But it only works for "locked versions" such as [1.2], and therefore is of no use in poms for libraries of any sort. I suppose maven could offer a tool that works like mvn dependency:tree but outputs the checksums. Then that could be pasted into the top-level pom.xml file as a real paranoia check. But I doubt many people would take advantage of that. If you are in a really secure environment where you need to be sure that the jars in the repo are not being modified, then you need to run your own repository instead. Use a "repository manager" to pull down the files your project needs into a temporary "unsecure" location, then move them to the secure repository, validating them in whatever manner you need. Then all builds can be run against your own secure, guaranteed stable repository. [1] And this is easy enough to check, just by running "mvn dependency:list", or using the maven-release-plugin. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
