Again, I appreciate the feedback. All that has been said is already known to me. Builds should always be automated - did not ask this to be different.
I have had the pleasure of working on a project where there was actually too much documentation. Improper documentation resulted in having it introduced in JavaDoc where necessary and having to perform another build. Tests/documentation was part of the release cycle. 3am is also not the time to find out that you want to get your hands on a build and find out that you can't reproduce it and wished you had the binary somewhere. But 'nough said. All this discussion should be in another thread and has little to do with low level action items. -----Original Message----- From: Graham Leggett [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2008 14:44 To: Maven Users List Subject: Re: General Maven questions.... Taub, Jonathan wrote: > I am well aware that some of the things I want to do go against Maven. > However, all is based on personal experience and I don't consider Maven to be > a magic pill. My experience has shown me that too many people rely on > technology and automation to solve everything rather than to add some > proper engineering discipline, process, ability to think out of the box, > and sometime, manual steps. Discipline is the key word, however in order to properly understand discipline, you need to understand people. People will always choose the easiest path *for them*. People will build the binary from their arbitrarily modified and unrepeatable working copy, because it is the easiest thing for them to do. Given the choice between "update the documentation to reflect the new release" and "do nothing", the people will choose "do nothing". Maven has, in the release plugin, come up with a path that it easier to do correctly than it is to do incorrectly. All you need to do is to ensure the pom.xml file is correctly configured. Your release manager then just runs "mvn release:prepare release:perform", and it just works. Adding manual steps does not demonstrate discipline, instead it demonstrates reasons where your build can go wrong. Remember the end result of all of this: it is 3am, your troubleshooter has a production problem, they need to reproduce the problem in their development environment. 3am is not the time to discover that you have "application.jar" and don't know where the source code is. 3am is not the time to discover that the version in source control, wasn't actually the version used to build the binary, and the version in source control doesn't build. Your entire process should revolve around making your troubleshooter's lives easier, and that happens when you make disciplined development the path of least resistance. Regards, Graham --
