To be able to do this effectively, we would need a tool that tells us when there is a newer version available in a remote repository. When a newer version is available, a developer (or a continuous integration tool) can change their local copy of the code to use the newer version and test compatibility with that version and if all is ok, commit the change.
I think the problem we are seeing is more due to uncontrolled SNAPSHOTs rather than the concept itself. For example, a lot of the problems we see go away when OpenEJB is rebuilt. This implies two things:
1) there is too much coupling between the projects
2) when changes are made new jars are not posted to the online repo quickly enough, combined with the performance of the online build being so slow that people are building offline and don't see new versions even when they do get posted
The first of these will require time to solve.
One of the factors with the second is the number of repo locations (because developers do not have write access to a central repo) and the unpredictable performance of the main repo at ibiblio. By moving to one central repo with good performance I believe we will address both of these.
Currently, all developers are exposed to updates to SNAPSHOTS and sometimes the build can be broken for days. If you don't have a backup of your previously building code (and repository?), one is in trouble if they want rebuild (e.g. an offline build) a working version.
I haven't thought this through too much, but have never felt comfortable with SNAPSHOTs. Could versioned dependencies help us here?
The problem I think we will run into is an overabundance of versions - at the extreme one for every commit. That is the problem that SNAPSHOTs were intended to solve by allowing one shared version that could be overwritten combined with an automatic download mechanism.
Now that we have a central way to change the project version, one option might be for developers to work with a "DEV" version that never leaves their local machine. Because this is not a SNAPSHOT we would eliminate the continual polling of the remote repo for artifacts that are being built allowing for an online build that would pick up new third party/sister jars. The committed version number would be SNAPSHOT so that the automated build process (or anyone working with a fresh checkout) would see the latest version which is known to have built (ok, is supposed to have built).
A developer may get in trouble if they have a lot of uncommitted work and someone posts a new snapshot. Hopefully that would get fixed by an svn update and rebuild; if not, there are likely to be conflicts that need to be resolved anyway. This problem is of course reduced by committingn frequently :-)
The big upside though is that this should make the build more reliable for end-users.
-- Jeremy
