You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.
This page describes the architecture of the Seam 3 build system. The most significant change from Seam 2 is that the core is replaced by CDI (JSR-299). CDI provides a foundation for creating portable extensions. This is reflected in the Seam 3 build system, which is now setup using a module project structure.
pick-and-mixstrategy
The Seam 3 build is entirely based on Maven 3. Each Seam module is a separate project, with it's own release cycle. Each Seam module is a multi-module project contains the api, implementation, examples and documentation.
This has the potential of leading to a lot of duplicate dependency metadata. To stick to the DRY principle, all dependency management for runtime dependencies is defined in a BOM (bill of materials), which is a imported by the parent POM of the Seam module project. The BOM additionally specifies exclusions so that no module has to worry about getting unwanted artifacts (because of bad repository metadata).
In addition to keeping the POM files in the Seam project clean, the BOM has the added benefit that it defines a sanctioned and tested dependency matrix for developers. That way, there is no question about what version of a library is recommended. It's all there in the BOM.
The BOM also provides an easy way to test different versions of a module - simply by overriding the version of the BOM used, you can switch versions of dependencies. The version of the BOM in use may always be set by specifying -Dseam.version=X.Y.Z.Q.
Additionally, plugin metadata and test dependency management metadata is centralized in the Seam parent POM, which is the parent for all Seam module project parent POMs. This split is maintained to allow a user to import the runtime dependencies without having our test and plugin dependencies foisted upon them.
Sometimes a Seam developer may need to update or add a dependency. To add a dependency, the developer should add the dependency version to their module's parent POM <dependencyManagement>, and the dependency to the necessary modules. Having tested the dependency, they should then add the dependency to the Seam BOM or the Seam Parent - guidelines are above.
To update a dependency, the developer should add the dependency version to their module's parent POM <dependencyManagement> and test the update. They should then update the version in the Seam BOM or Seam Parent - see guidelines above.
Periodically, a new version of the BOM and parent will be released. Developers who make significant updates should email the dev list, asking for a release. At this point, all version updates will be reviewed.
Developers should watch the commits to the BOM and parent POM, and if they notice an update that won't work for their module, open a discussion with the commiter.
A Simultaneous Release is release of the entire Seam stack, with the assurance all modules included in the release have been tested to work together.
To provide a Simultaneous Release, the BOM is updated to include the correct versions of the Seam modules, and dependencies. This BOM is then released, and used to create the distribution zip, verify the examples etc.
You will have noticed that there is potential for cycles in the dependency graph, as the BOM references Module A, Module A imports the BOM, and the BOM in turn references Module A, which could cause confusion as to which version of a module to use. Maven uses a nearest-first rule to establish the version of a module, which means that the version specified in the first BOM imported will be used.
The Seam parent and the BOM have different release cycles (with the BOM being released more often than the parent), and so are kept in different SVN roots.