Using Maven for some time it has shown some quirks which make continuous integration basically impossible: 1. Snapshot artifacts must be static (http://jira.codehaus.org/browse/MDEPLOY-77) and should be reproducible; 2. All other artifacts (Alpha, Beta, CR, GA) must be static and must be reproducible (http://jira.codehaus.org/browse/MDEPLOY-82); 3. Dependency resolution must fail if no valid component matrix can be formed (http://jira.codehaus.org/browse/MNG-612); Since there are no viable solutions within the Maven domain I'm looking towards Ivy to see if that can cover these requirements. Ivy has the notion of 'latest.integration' revision with which it can bring in the latest snapshot of a component. During publishing (deploying) the resolved revisions can be written back to an ivy descriptor and put into the repository. Secondly you can also dynamically ask for the 'latest.release' dependencies and thus produce a nightly build based on latest.integration and a milestone build based on latest.release artifacts. To be compatible with Maven Ivy has taken over the same flawed concept of a SNAPSHOT revision (aside from the real Ivy revisions). Meaning that Ivy will handle a dependency of 1.0.0-SNAPSHOT in the same flawed way Maven does. To get it back to static dependencies (latest.integration) we need a custom dependency resolver (https://issues.apache.org/jira/browse/IVY-1036). Releasing components in conjunction with svn is still a very much non-standardized operation. This needs more work. At the end of a resolve phase a conflict manager will determine whether a stable matrix can be formed or not. All of this can be viewed in Ivy reports and graphs. One important missing feature is actually deploying a snapshot artifact. Ivy doesn't do this at all. So to make this I've resorted to using maven-ant-tasks. Which actually makes an interesting combination. Using the custom Ivy resolver I can create a static 'snapshot' descriptor, translate this to a pom.xml and use that to deploy into the snapshot repository. The resulting component is here: http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/ivy/. So would I use this to start a new component? Actually, no. Maven has shown that it's actually nice to have almost no prose to create a new component. With Ivy I have to resort back to ehr.. build magic. :-) But there are two paths that lead beyond this point: 1. create a build.xml which allows for bootstrapping build magic using Ivy 2. use Ivy as a dependency resolver within Maven So a new requirement forms: - to create a new project it must not be required to copy any logic (except the inevitable bootstrap) (hmm, we could actually mandate $HOME/.ivy/bootstrap.xml (before anybody howls, Maven needs $HOME/.m2/settings.xml)) One thing that I'll keep beyond scope (even though it would be cool) is a dynamic component matrix: Suppose A 1.0.0 depends on B 1.0+. Within the repo this is reflected as: A 1.0.0 -> B 1.0.0 Now we release B 1.0.1 and rebuild A: A 1.0.0-2 -> B 1.0.1. In effect the dynamic dependency reflects what can form a compatibility matrix, but since we want a stable dependency chain B 1.0.0 will become an invalid artifact for the matrix. So to really know which components can form a stable matrix you must know all versions that have been tested against component A. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4216114#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...