 |
CC's Build System
Other Information
| Maven Definitions |
| Jelly Scripting Hints |
Automatic Versioning of Java Projects
Now that we've gone through all of the preliminaries, here's the meat of the system to create repeatable versionable builds. The process is complicated because it is intended to support a mixed use system where some developers will change over gradually to the new system while some users are already using it. Gradual change over is necessary to support legacy systems and applications.
The use case is a new intern developer that just started and a project manager informs the developer that project 'xxx' has a bug in it. The developer is tasked with tracking down the bug, fixing, and releasing the fix. The developer doesn't know anything about Maven and very little about CVS. If the developer doesn't know enough about CVS to checkout the files, the php developer sitting in the next cubicle can help out.
Intended end-use of our system:
What the developer can do:1. Checkout the Projects/Builds directory
The Builds directory contains the main files inherited by subprojects
such as project.xml, project.properties, maven.xml, and version_map.xml.
It will also contain main project minimal build files.
2. Run parseproject goal on a main project in the Builds directory
This will download the dependency code projects as well.
For an experienced developer, the projects might already be in progress,
so setting the download property to 'no' would allow the developer to use
the in-progress projects and incorporate them into the released project.
3. Modify projects and commit changes to cvs if needed.
4. Clean the project and run ccscm:catalog goal.
5. Run ccscm:version-project to update project.xml, file_catalog.xml, ../Builds/version_map.xml
There are several ways to use this goal:
1. Use version numbers for the file_catalog.xml file from cvs
This assumes that all files have been checked into cvs,
are up to date, and the file_catalog has been created.
2. Specify the project version with the ccScm.project.version property
This also assumes that all files have been checked in, up to date
and the catalog has been created.
3. Use the createmap goal by setting ccScm.use.map=yes. We want
to use this option so that on a major project, we can change all
dependency versions to the current versions. This will
assume that all sub-projects have already been versioned.
Our newbie developer should use the ccScm.project.version property to create a new version
of everything, so if there is a problem, the previous version can be retrieved fairly easily.
6. Run jar:deploy or ccjnlp:deploy to deploy the jars or jnlp application.
The above case is a very simple example of the basics of our system and already it has a number of steps to remember. In reality, a more experienced developer would want to use the mapping facilities of the ccScm plugin to make cross-references and the latest builds of subprojects available to all projects that can be built from that time forward.
Here is an image from a presentation I did about this process. It really is not any clearer than the above description, but it does show the level of complexity. The inner box shows the steps for each subproject that should be run for any subproject that is modified. The outer box is the steps run for the top level project.
Click here for the split up sections from the presentation that describes the above diagram in more detail.
Below is an example of how this process would be used.
Case Example:
Project Portfolio:Dependencies:
Domain
Security
Security
Framework
OTrunk
JDom
Jug
XMLTypes
Domain
Security
Security
Framework
FrameworkView
Framework
Swing
XMLBeans
Ozone
Data
Framework
DataGraph
Framework
Data
Framework
Graph
Framework
Swing
Graph
Framework
Swing
FrameworkView
Framework
Swing
Sensor
Framework
Waba
SensorNative
Framework
Sensor
So, let's say Framework needs to be modified and we want a new portfolio version
from this modification. The first five steps remain the same.
1. Checkout the Builds directory
cvs co Projects/Builds
2. Run parseproject on the Portfolio project in the Builds directory
cd Projects/Builds/Portfolio
maven -Dmaven.scm.cvs.root=:ext:eblack@xeon:home/buildspace/CodeBank parseproject
3. Modify Framework project. Add files to cvs if required and commit all changes.
cd ../../Framework
<Do any modifications>
cvs commit
4. Clean the Framework project and run ccscm:catalog
maven clean ccscm:catalog
5. Run ccscm:version-project on Framework to update the project.xml and
file_catalog.xml files
maven -DccScm.project.version=4.5.3
-Dmaven.scm.cvs.root=:ext:eblack@xeon:home/buildspace/CodeBank
ccscm:version-project
6. Run ccscm:createmap on Framework to update main map
maven ccscm:createmap
7. Run ccscm:version-project on main project if changing project version.
This does not need to be done if the main project version is
staying the same, but there are very few reasons to not update
the main project version if any dependencies have changed.
cd ../Portfolio
maven -DccScm.project.version=2.7.0
-Dmaven.scm.cvs.root=:ext:eblack@xeon:home/buildspace/CodeBank
ccscm:version-project
maven ccscm:createmap
8. Run ccscm:version-project on main multiproject (Portfolio) to update
projects and main map. Run ccscm:get-classpaths to create dependency
catalogs.
cd ../Builds/Portfolio
maven -Dgoal=ccscm:version-project,ccscm:createmap
-DccScm.use.map=yes
-Dmaven.scm.cvs.root=:ext:eblack@xeon:home/buildspace/CodeBank
multiproject:goal
It may be necessary to run jar:install as a multiproject goal and
run offline, or modify specific project.xml files to have specific
versions for dependencies if not in repository.
9. Clean the projects (multiproject goal, etc) and commit the files
that have been created from the last step.
10. Run jar:deploy or ccjnlp:deploy to deploy the jars or jnlp application.
Step #6 should really be run on all projects that depend on Framework if the change is important enough.
That is a very painful process and prone to errors due to forgotten steps or steps run out of order. To remedy the difficulty level but to maintain the standard process, I stripped away all Maven tasks from the user to bring it back to the process of checkout, build, checkin for developers with all the remaining steps handled by a deployment web interface.