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!
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221642#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...