Build system goals
Build System Goals
This is an attempt at setting a more well defined direction for the build system within JBoss. Up until now the goals of jboss builds have been vaguely defined as "reproducible builds" and "migrate to maven". So the goal is to first figure out what reproducible builds really means and create a clear direction by opening up the discussion. Hopefully this will get everyone on the same page and make it easier to understand why certain changes take place and how the small changes fit into the bigger picture.
Reproducible builds
Maven in general takes the approach that release builds need to be reproducible, and snapshot builds do not. It seems clear that being able to reproduce just release builds is not enough for the needs of the JBoss projects. It should be easy to track down any build, including snapshots and determine how they were built (what svn revision, maven version, java version, etc), and use this information to re-run the same build.
The ideal solution for this would allow a build to be run, on hudson for example, and deployed to the snapshots server. With nothing more than a pointer (url? artifact/groupId/version?) to the pom and the jar(s) on the snapshot server, Hudson should be able to re-run the same build using the same version of maven, java, the OS, and the same svn revision as the original build.
In order to accomplish this, the first thing that needs to be done is to record the necessary information during a build (MRELEASE-352). This should be done during an early stage (validate?) of the build. The information should then be recorded somewhere that it can later be accessed, possibly as a separate file, or possibly in the jar manifest. The svn revision can be gathered from the existing buildnumber-maven-plugin. The svn revision then becomes available through a property.
The second step involves changes to Hudson. Hudson would need the ability to read the build information and automatically set up an environment similar to what was used in the original build. Then the correct svn revision would be checked out and the project could be rebuilt. As a final step, Hudson would compare the generated artifacts to those in the repository and give information about whether they match.
Keeping dependencies up to date and in sync during development
There is a constant struggle to keep dependencies up to date while developing. The maven model of using snapshots has several problems, and doing tagged releases for every build is not practical. The ideal solution would allow the developer to easily choose between development snapshot dependencies and more stable release versions.
There is currently some work being done on the versions maven plugin that might help to make it a little easier to keep dependencies up to date. There is a goal to search for newer versions of dependencies and update the pom accordingly.
It would also be useful to be able to easily compare dependency versions between two projects (JBBUILD-512). This would allow component developers (ejb3 for example) to quickly compare the versions of their dependencies to those of another project such as JbossAS. In the future this type of feature might be integrated into IDE plugins.
Dependency Resolution
In order for builds to be completely reproducible, dependencies must be resolved in exactly the same way from one invocation to the next. This can be an issue when the artifacts are not ordered in the same way for each build. Maven is currently undergoing changes in its dependency resolution component. It is likely that changes in dependency resolution will continue for some time to come, so this requires that we must track what version of maven was used to build the application, and require that this same version be used to reproduce the same build.
Maven has limited support for version ranges, but it is not practical for the pom of a released project to include any version ranges. Because if the pom does contain ranges, then any change in the repository could mean a change in the build. So either a snapshot of the repository would have to be saved, or all ranges would have to be resolved to the actual version used.
Simple/reliable release process
The ideal solution would be to have two options available at any given time: a completely automated release using Hudson (or a local developer workstation when needed), or a more manual step by step process that allows the developer more fine grained control over the release process.
One of the problems with the current release plugin is that a "dryRun" release build is not exactly the same as a "prepare", and a "prepare"; build is not exactly the same as a "perform". And occasionally a successful dry run or prepare step can still result in a failed perform.
Comments/Feedback are welcome as always!