> When integrating artifacts against a snapshot its meaningless just like > giving a tester snapshots is meaningless the result is not deterministic.
You can embed the svn revision into the jar. If you really need to, you can then reproduce the build of any snapshots. Although we have found we have never had to do that. We can nearly ALWAYs reproduce a problem on trunk and fix it there. > one of the biggest hassles I used to have > on projects was people checking in broken code, that would stop other > developers from working. With snapshot dependencies you have exactly the > same problem but worse as you don't need to update or you do. Finding a > stable combination of snapshots and updated working copies is hard and > prone to error. The simple answer to this is to not check in broken code ;-). And I know that is easier said than done. A more lengthy answer is that working with SNAPSHOTS does require a somewhat more mature development environment. For example, having continuous integration and a healthy amount of automated testing finds any broken submissions quickly and allows devs to fix them quickly. Often within minutes of the initial submission. Thus even when trunk is "broken" it is only broken for a very short period of time. If one of your dependencies is a project that isn't that mature yet and still has many "stability" issues, then I would recommend only using proven in releases of that project. But if it's a dependency you can trust, go with SNAPSHOTs. It is a judgement call. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
