Sorry, if I am being overly naive...
Not naive. You simply having been involved in a large enough project, or collection of projects that depend on each other. Or in distributed teams in different cities. You want each team to work on independent sub-project. Some dependencies are fixed, like external OSS tools, some are highly fluid like the internal ones your sub-project depends on. These are developed in parallel, and you very often need their latest. That's were project dependencies is important. Having to pull 20 CVS modules to build the dependencies yourself is not a good thing. Having an Ant target called dependencies.update that pulls in the Jars (and native libs and headers in my case), sets up the path correctly, and doing with transitive dependencies is simply necessary. The alternative is a huge mess, really. The whole thing is controlled by properties set centrally, with possible overrides by sub-project. This whole thing was home grown before Ivi and m2. I couldn't get Maven to work for me, and it wouldn't have dealt with the native stuff anyway. That, and the fact that deploying Maven to the users would not have worked. An Ant based, organically grown solution, was the only thing that worked. No dependency management tool I've seen so far in the Java world deals with platform-specific native stuff (when you do JNI), or with CruiseControl that must run on 4 or 5 different platforms in parallel. Either your development model is one big ball of wax, as I call it, or you modularize it, but then dependency management creeps in, and it can be a killer if not dealt with. This my own experience working on a collection of very large scientific applications implemented in Java, with a lot of legacy native code underneath. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
