一种不好的开发方式

如果项目之间的确有独立性，那当然应该拆分开；
话说，难道你的IDE连自动把多个项目打成war部署的能力都没有？

怎么感觉是山寨版的maven管理

把项目拆分成很多项目 maven管理项目不是就这样用吗  然后要测试就写测试类,否则就把改动的jar包install 然后tomcat:run

感觉什么事情过犹不及，简单最好，感觉MAVEN就是处理这种事情的

用ant实现了一个maven。。。
不过楼主别不习惯工程分这么细，很多maven项目的模块也分得很细的。

不是分工细不细的问题，分工细怕啥。我是发愁帖子里提到的3个现实的问题，怎么办？

假设项目A引用项目B，你为什么要使用B的jar包？eclipse的Java Build Path不是可以直接加projects吗？打war包不是可以自动把项目B自动打成jar放到你的项目A的WEB-INF/lib下吗？

感觉lz还是不会使用工具的问题。

工程大了，不拆没办法玩的

果断转到maven

整个项目的核心问题是设计与管理的问题。
应不应该拆呢？多半是应该拆的。但是拆得好不好呢？从现在看肯定是没拆好。
这种拆分的项目需要非常好的项目协调和开发能力。而且你们没有稳定的模块API码？开发版和稳定版没有分支吗？只能全打包测试没有单元测试和自动集成测试吗？
如果没有足够的架构设计和项目管理协调能力，这么拆就是找死的行为。

你说的这些问题有些就不是问题的

第一个：如果写代码按下ctrl+s保存，使用IDE的自动编译部署，工程大了，会很崩溃了，编译部署一次花个几十秒，几分钟的，岂不崩溃了。项目小的时候使用IDE的自动编译部署很方便，因为用时就一两秒，感觉不到的。

第二个：上面已经很多人说了，依赖的问题，不影响什么。至于你说的晚上一合并编译就出问题，那说明是变了api，接口等内容，这个需要项目前期定好规范和交流内容。即使同一个工程，如果项目前期不定好沟通的规范，同样会出现。

第三个：在项目前期的开发阶段，这是没办法，你即使将这些所有合并成一个工程，编译的时间也是不会减少的。上面说过，你提的解决办法是稳定的才打包，对于java工程来说，打不打包是一样的，只是为了方便管理。所以在不在稳定的时候打成jar包这个是没关系。

你们的项目需要引入的是：

1、自动构建工具，晚上或者是定时进行项目构建。

2、对于构建出的问题，然后制定相应的管理规范。比如：对于不稳定的代码，不能运行的代码不要提交等。