So a standalone build, just defines itself as the only primary component.
A federated build allows you to "extend" other top level builds.
Another example of federation would be to develop two builds together.
e.g. the cache developers might build a workspace like:
<project> <extends name="jbossas"/> <extends name="jbosscache"/> </project>
Allowing them to build jbossas and jbosscache from source together.
This would automatically override jbossas's inclusion of jbosscache as a binary
inclusion and make it a source project alongside the other jbossas components.
This brings in other configuration requirements.
e.g. the jbossportal federation only wants jbossas as binaries, whereas the
jbosscache federation wants it as source.
So we need a configuration option that makes this explicit:
<project> <info id="portal" description="JBoss Portal" repository="http://repository.jboss.com" cvsroot="cvs.forge.jboss.com/cvsroot/portal" </info> <extends name="jbossas" type="binary"/> <component name="bb"/> <component name="wiki"/> etc. </project>
There are other requirements where the extension will be of mixed type,
1) Portal wants to include the license information, docs from jbossas
2) Portal does not want to run all the unit tests for jbossas when they run
their unit tests
Getting more complicated, the custom cache federation will probably only
want to run tests for components where cache is actually used?
You could even imagine the cache project wanting to make a workspace
that "automagically" includes all the components/builds where the cache module is imported. Which would be good for cutting down the regression testing overhead
but would be bad for people "fixing" tests rather than fixing the problem.
What about defining the release structure - a responsibility previously held by the toplevel build. Is this no longer the case?
I haven't got to the "release" part yet.
So there needs to be a clear mapping of the names used in the references such as extends, component to both the binary and source repositories. There also needs to be a definition of the structure for a component source and binary tree.
In terms of a project wanting to import the docs/licenses/* or another component, this is just an alternate artifact reference to the binary repository as I see it. The docs would also seem to be more of a release level reference. The licenses I would expect to be a general feature of a common thirdparty target that pulled the binaries from the repository.