Lessons Learned From M1 Build And How to Improve Build Structure.
alexsmirnov Jul 15, 2010 2:10 PMM1 build structure has some pitfalls ( and advantages as well ), so I wish to bring all my things together there. Until 4.0.Final 9 or even up to some 4.0.x release ) the main goal for build structure should be maximum development speed, so most om my suggestions targeted for that aim.
Good things:
- stable project root that is not changed often ( hope, we would stop on v 8 for a while ).
- Bill Of Materials projects.
- release script.
Pitfalls:
- internal branch/tag/merge structures. Unless you are working with a single project ( that not is an option until RF framework API will be stabilized ) it's more convenient to check out whole root project and work with it as a working copy. Internal tags/brunches multiplies size of the working copy ( 3-4 times after M1 tag ), increases network traffic and slows down svn operations. Also, it's hardly possible to use these structures for development branches or backport fixes to the tags if it affects more then one module. Many tools ( svn clients, IDEs, Maven, and tools like svnmerge/hgsvn/git-svn ) cannot be used directly because they does nut expect these structures.
- Exposed number of Maven projects. Some components have up to 7 projects ( bom,parent,root,api,impl,ui,dist) for just 3 java classes. That slows down builds ( I have about 10 minutes to build whole project, and it's going to be worse as more components included in UI library ), that wastes developer time for error fix iterations. As a result, it's more likely to commit broken code into repository. Also, the number of required projects in IDE increased dramatically, that makes hard and slow any refactoring operations that affect couple of modules.
- Complicated build configurations. I got 70 ( sic! ) parameters in effective pom for framework implementations - most of them just describe paths to the current in the trunk/tags/branches folders.
- Tricky release and deployment process.
Suggestions to improve:
- Move core project code into the 'trunk' folder, that contains only the files included into release source distribution, with the same layout. It should be available to build whole project by the single command. No internal t/b/t structures there. In the future, we can extract some projects into the modules with separate tags and brunches and make links in repository to preserve trunk structure, similar to MyFaces 'current'.
- Change 'trunk' code requirements. It should always contain stable code only, pass build and all tests on the Hudson server. Therefore, developers that are working with a single module can relay on nightly builds, and these builds can be used by QA to start release tests early. Any development that is going for the time more then a few hours and could affect many modules should be done as development branch and merged into the trunk after local tests only. Any errors on continuous integration server should be fixed immediately.
- put projects that is not intended to be included into distribution ( sandbox, internal examples, and QA projects ) in the 'modules' folder. It's questionable there to create tags and branches for these modules - using t/b/t folders in the module or create them in the global tags/branches folders.
- Reduce the number of maven project as possible. Use the single framework (api/impl) project only, single 'docs','examples', and 'archetypes' folders. To distinguish classes related for different components, put them into different packages ( I'll add necessary changes to CDK ).
- do not use build parameters to tune the current versions of modules but separate pom.xml in tags/branches. For the linked modules, version to include into build can be changed by svn link target.
- Create 'development' build profile that skips goals that not required for build iterations ( enforcer checks, documentation/javadoc builds )
Estimated build structure:
/tags
/archive - for pre 3.2.x releases ?
/branches
- everything goes to brunch there
/development - temporary development branches.
/trunk
archetypes
cdk ( lin to the CDK module in the future.
maven-plugin
generator
.....
bom - only versions of richfaces artifacts and its runtime dependencies should be defined here.
docs
- all docs goes here.
examples
parent - build configuration and non-runtime dependencies.
core
api
impl
ui
ui-foo
ui-external -> link to module.
........
ui-zzz
dist - library assembled here.
/modules
richfaces-parent
sandbox
QA-projects
zzz-module
[cdk]