Last week I had the opportunity to hang with Paul Gier, members of the product team, and some Maven thought leaders to discuss best practices for the EJB3 and Application Server builds.
Some history: we initially wanted to introduce the AS "component matrix" as an independent listing of all thirdparty dependencies to be used in the runtime. My hope was that this could be relied upon by external projects to ensure we'd run unit tests against the correct component versions. Unfortunately, to be consumable by both AS and external projects means that component-matrix would have to live outside of AS, leading to one of two unhappy scenarios:
1) We release this thing N times a day and update AS accordingly
2) AS would depend upon a SNAPSHOT (absolutely not)
After Maven 2.0.9 the "import" dependency scope was introduced, which is essentially a hack allowing us to *compose* dependencyManagement information from many POMs. Using this allows us to remove component-matrix as a parent, and instead we can now split out subsystems' versioning information to be defined by the subsystems themselves. This approach is called a "Bill of Materials" (BOM).
Currently we define our dependency chain via the "ejb3" and "as-int" modules, but really we need branches (one per runtime target) to define the pieces which make up our subsystem.
So for EJB3, I propose:
...with *branches* for each runtime target. In effect this would be the only place we branch, as the components themselves are always cut from trunk.
Then we can remove org.jboss.ejb3 stuff from component-matrix in AS and let them import our BOM. Similarly, our own components can bring in this metadata safely (as it'll be externalized) and either use the depMgt defined or ignore it. When we want to do integration testing on *upcoming* stuff, we can override the AS build using a command-line property to use a SNAPSHOT of the EJB3 BOM.
IMO the way forward for AS is for all subsystems to provide a BOM, and let AS compose them together using import scope.