We've been using a custom-made component-based build system for many years, built using a number of Ant scripts, and we'd really like to move to something more standard. We'd like to go with Maven, Subversion and Nexus, but our build processes are a little different from the usual and it would be nice to know what is the 'right' way to address some of the versioning issues.
Our applications are made up of a few dozen components, some of which are shared between projects and some of which are project-specific. Each of these components currently has a 4-component build number "major.minor.patch.build". When building a component, its build number is incremented. A new major, minor or patch version resets the build version to zero. I'm happy to change a dot to a hyphen, and I'd also be perfectly happy for that build number to be a Subversion revision number, but I'm not happy to go for a SNAPSHOT-style date/time: try telling someone your latest version is "3.6.0.20110507170144". The 'released' version of a component is the last build number that component is built with. Once a component has been 'released' it cannot be built as a new version; the rest of the version number needs to be incremented. This is somewhat like Maven's release process except that we do not want to renumber or rebuild the components for release; integration and system tests will reveal when a project (and its constituent components) are ready for release, and we're not going to re-run the entire test suite on a functionally identical build. It would be nice to protect a 'released' component from being rebuilt but that's hardly mandatory. Obviously, when a component is built and its build number incremented, all dependencies need to have their version numbers updated and be rebuilt. It would be nice if the dependencies could automatically pick up the 'latest' version of a major.minor.patch dependency version; I understand this can be done using Maven version ranges. When doing a 'real' build I would like the components to be 'tagged' in Subversion with the built version numbers and for that tag to reference the actual set of build dependencies (rather than a version range). Ideally, I'd have a Subversion style: Component-name |- trunk |- branches |- |- 1.0.0 |- |- 1.0.1 |- |- 1.1.0 |- tags |- |- 1.0.0-0 |- |- 1.0.0-1 |- |- 1.0.1-0 I would also like to be able to do 'test' builds without tagging; maybe the tagging should be separate so I can try to build the whole lot to my local repository, and if the build is successful and all automated tests pass along the way only then update Nexus and tag in Subversion. What I want, therefore, is a system in which, for a set of top-level components to be built, it would then evaluate the set of transitive dependencies of those components as specified in Subversion (not Nexus or the local repository), work out the complete list of out-of-date components to build and then build all of those components such that the top-level components represent the current state of Subversion. Plainly, if the build is up-to-date with Subversion, nothing should be built. I accept that this is a job for Python, but I am wondering how much of this process can be done with Maven without cluttering the per-project POMs, even if minor modifications need to be made. Thanks in advance, David McCabe --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
