我要被老外气崩溃了

扯淡！ 原因也许不在于分几个项目这个分歧吧

ken说过的话  谁敢不服

我也在想如果能找到个规范是不是能说服他们。 Netbeans向导和例子生成出来的缺省J2EE架构就是分成这几个项目的。

agree, 以前也碰到过这个问题，按照功能模块去划分项目，后来问题太多。但是C/S结构也不划分似乎说不过去。
EJB3.1允许war中存在EJB应该也是归一这个想法。

举个例子，在common项目里面可能会存在一些通用工具，依赖于client/server下面的实现。就像SLF4J那样。
另外，像log4j.xml在客户端和server端可能有不同的配置。如果都放在一起，调试的时候就强制用同一个文件，方便吗？打包的时候再分开？

另外client和server端的目录结构会有不同，混合起来也可能造成冲突。

重构的时候的确会有些麻烦，特别是common更改的时候，必须要所有项目checkout出来才能实施，保证不出错。所以只有四个项目。

据说很多外包公司的项目都是两位数。。。。。

像JBoss/Eclipse/Hibernate这样的项目，里面子项目无数，咱们就不去赶时髦了。
这种一个巨无霸的项目好像在以前很流行，严重怀疑是C/C++时代的产物。

比较欣赏前面一位老兄的说法：在制度上就不给他们犯错的机会。这是人治和法制的区别。

谢谢，我也喜欢看infoQ, 虽然能看懂的不多
用module方式开发，可能需要更多的项目啦～～

我觉得所谓的多个工程，本质上是看它是否有多个build脚本。
eclipse可以指定任意多的src目录，所以你搞一个或多个eclipse工程没有本质区别。
至于版本控制系统下，一颗代码树要简单得多。
你们的分歧到底在哪里呢？

多少个工程对ant/maven都是小菜一碟。对于maven,可能多个项目会更简单。

如果混合在一个eclipse项目里面，运行客户端会带上server端的class, 同样运行server端会带上客户端的class.
俺们server不是war, 是自己写的main方法启动。
对于俺们的项目来说，代码量很庞大。一个大项目会很笨重，refresh一次就要很久。
另外客户端打包成client.jar，依赖common.jar, server端运行server.jar, 依赖common.jar

对了，server还有一些code-gen, 不build不会有code-gen的代码出来，编译不过，客户端也跟着遭殃跑不起来。。。。。

ray_linn老大不在，哈哈
其实lz的问题在Visual Studio里边很easy的，一个solution下多个project，客户端、服务器甚至安装程序都可以作为子project，而且都可以统一管理，重构什么也很方便，svn也是一颗代码树..这个貌似啥netbeans、eclipse都做不到哦

再瞎说就揍你！Netbeans/eclipse的J2EE开发都有类似logic, 最后打包成EAR.

vs跑这里来找扁啊