Great post. Your right, maven is a great tool, but still has a way to go to make if perfect for most people.
Part of the problem is that release processes are shaped by forces outside of the development team, such as legacy systems, existing team structures, and other sorts of company history. So any tool will have to be flexible. I do have some comments on this ... Christian Goetze-3 wrote: > > Builds are not Reproducible > > This should be the holy grail of every release engineer. Arguably, it > isn't really maven's fault, but rather the fault of the java designers > to rely on a format that includes timestamps (jars). Run mvn install > once, save the artifcats, run mvn clean install again, and the jars will > look different. It requires trust in the system to accept that both > builds are the same. QA engineers are very unwilling to trust - it's > part of their job description. If you wish to reproduce a build, it > would be great if it came out bitwise identical to the original build. > That is indeed a shame, but if the zip file format was not used java adaption might not have been as strong? Perhaps the maven packager could implement your "set the timestamp to be the oldest entry" hack? Alternatively, if the deployment people want to be sure about the contents of a jar, rather than looking at it's md5sum, they should use jarsigning to compare two jars. When signing a jar, only the contents of the files are hashed, not the timestamps. If you have two signed release jars from the same release, but build on different machines, you can compare the two manifest files, or the two digital signatures. See: http://java.sun.com/docs/books/tutorial/deployment/jar/intro.html Christian Goetze-3 wrote: > > Reactor builds are "all or nothing" > I find this annoying too. I have almost 20 modules in my project, and so I hit this often. Just thinking off the top my head, when the build looks at a modules it should: 1) check the "avoid rebuild" feature is turned on in the pom 2) look in target\lastbuild.properties for info about the last build 3) check the current buildVersion matches the one in lastbuild.properties 4) check none of the source files are more recent than the timestamp in lastbuild.properties 5) if it's all ok, skip this module Having the option to build a module and it's dependencies would be great as well. David -- View this message in context: http://www.nabble.com/First-impressions-of-using-maven-%28long%29-tf2921690s177.html#a8216721 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
