开始受不了Eclipse

它在编译一个新类时，总是先清空全部的classes。如果这时别人的一个类凑巧编译不过去，这各类又凑巧在新类前编译，那你就别想使用新类了。

当然，这时可以采用删除有问题的类的方法。

但有时项目很大，从eclipse的提示伤根本看不出是那些类有问题，那就惨了。新的类总是没有class产生。

为什么eclipse会这样？我在首选项里改成手动编译、禁掉自动编译都不行。哪位知道能不能有其它办法解决？我这里又急又恨，谢谢啦！

一个类的依赖类都不对，那么你觉得这个类你应该让它编译通过吗？



？？？？？

不，我觉得是这样理解的。

在JB中，新写了类C，它依赖类B，项目中还有其它类A、AA等(不跟C、B有任何关系)，那么你可以单独编译B，然后编译C，然后使用C就行了。

但Eclipse它不这样，它会对整个project进行编译，就是A、AA这些用不到的类它也去产生class。

问题的根源就在于，它会先删掉所有的classes(项目checkout时)，然后试图重新编译。如果凑巧A、AA这些在B之前编译且编译不过去，那就不能产生C这个class了。

JB是你用什么，就编译什么。我想这是比较合理的。

不会的，只要C没有依赖A和AA，而B也没有依赖A和AA，那么就算A和AA编译错误，也不会影响生成B.class和C.class

这怎么可能呢？速度还能受得了，只有在rebuild project 时才会重新编译的。

Try Again & Again............ &Good Luck.

我不知道你为什么痛恨eclipse的增量编译功能, 但是我觉得这个功能恰恰是他值得称道的功能之一.
eclipse在文件系统中有一个文件关联映射表, 一个文件发生改动时, 它会把所有相关文件都编译一边, 这在WSAD5.1中的jsp文件和其他文件也是这样做的.
这样可以保证你开发的系统至少没有编译错误.

而我觉得在实际开发时就不能允许系统中存在编译错误, 也许你在发布时候对你的系统没有什么影响. 但是是否想过, 既然一段程序存在错误,他就没有存在的必要.删除他就是必然的.

还有一个问题, 在团队开发的时候, 通过CVS或者clearcase来协调团队开发的时候, 你把自己有问题的程序发布上去, 会给你的开发伙伴造成很大的困扰和影响, 因为他很难确定错误是否是他自己程序的.  所以我自己在以前的开发团队里规定是没有经过测试的代码是不允许上载到CVS的, 更别说有错误的代码了. 这是绝对禁止的.  另外, 关于持续集成, 我以前的开发团队在项目中后期几乎每天发布一个可运行的测试系统. 如果你发布的程序有问题, 那么测试人员很难对功能进行测试, 而且有事也很难定位程序发生错误的位置和原因.


>>但有时项目很大，从eclipse的提示伤根本看不出是那些类有问题

那应该是你不会使用他的过滤功能. 你可以看看. 
其实在这句话中你就应该体会到这个功能的优点, 你每次都保证你的程序没有错误, 那么你就很容易定位新的错误在那里.

我坚持一点, 允许错误存在的程序, 是没有生存理由的程序.

对，就是你说的这种问题。我们目前的项目光开发人员就有100，每天提交上去的代码不能全部是正确的，可能有一下两种情况：

1、本身就编译不过去，被误提交，又没有从cvs上删除；
2、本地可以编译，但引用了第三方class，没有上传该lib。

其中第二类问题大量存在，你任何时候对项目整体编译的时候，是一大片红。这非常让人难受。但这是对项目cvs的管理问题，以我们大多数人使用的jb来说，他可以容忍这种情况——即，错误的归错误，但我不用就没有问题。

而eclipse则不能容忍，主要是项目第一次checkout的时候，它要对整体编译。如果前面有些类无法编译过去，它确实会导致后面的即使无关的类的class也不能产生。Robin说不会出现这种情况，但我知道我们的项目中就是这样的，我只有把那个包report/v2里面的源码删掉，才会继续；但这个report/v2跟我自己的类没有关系。另外Tomcat朋友误会我的意思了，当然不是每次都编译项目，那谁受得了？但我猜测第一次checkout project的时候会有这个动作；并且如果第一次是不成功的话以后每次启动eclipse时会重复检测上次没有编译过的类，速度很慢。

我昨天跟组长谈过这个问题，eclipse好像本身就要求提交到cvs的代码是正确的，单独的lib也要上传到项目的lib中，不然对其它人的影响太大了。我认为这应该作为一个管理规范来在每一个具体项目中执行。

eclipse在refresh and cvs update时是重新编译的，在修改了一个类后可以是自动增量编译的。

关于LIB的问题，可以用每日纪录文件的方式用人工保证，可以有据可查，我觉得100人的团队，让系统来保证也挺难的。

另外补充一点，不应该所有的团队成员都存取一个CVS路径，这是麻烦的开始。
这需要做好先期的设计和命名规范，每个小组只对自己的模块负责。
用到的公用接口（抽象类和接口）等层次上的结点是要给相关小组都要一份的，测试先也要围着这些公用接口转先。

Eclipse的CVS插件有branch这个概念，应该是做类似的事情。

但这样的话同步比较麻烦，尤其是各小组之间互相调用对方模块的动作比较多的发生时。总之是需要强化对cvs的管理，而不是听之任之。

刚才重新检查了一下cvs，看到很多java source出现什么一行两个分号、方法不throws Exception等简单错误，真是让人痛心！