将GWT添加到Web应用程序。其他开发人员抱怨编译时。我应该告诉他们什么?

尝试使构建更智能化(如果还没有的话):只有在客户机源代码更改时,才应该重新编译GWT(客户机)部分。我想,主要是你改变了这个源代码,所以其他开发人员不会感受到痛苦。

警告:当然,如果你的客户源与现有项目共享代码(我想,它是服务器端的Java项目),那就不管用了。。但是在您的案例中,也许您应该避免共享代码:即使这违反了dry(不要重复自己)原则,但是要意识到如果不使用gwt,您无论如何都会违反它。

但是,如果你 做 重用服务器项目中的代码,那么您就有了一个很好的参数,为什么要使用GWT。

如果开发人员为了开发应用程序而必须编译整个GWT东西(所有排列),那是非常痛苦的。从GWT2开始,您可以将webapp项目配置为在“开发模式”下运行。它可以直接从Eclipse(Google插件)启动,这要归功于内置的Jetty容器。在这种情况下,只编译请求的资源,并且过程是增量的。我发现在Seam+RichFaces+GWT应用程序中,这种非常方便的-GWT编译开销在开发周期中非常小。

当涉及到应用程序构建时,有几个选项可以加速GWT编译。以下是检查表:

• 禁用Soyc报告
• 使可能 draftCompile 跳过某些优化的标志
• 通过调整 localWorkers 标记:在多核CPU上构建时可以稍微加快速度
• 编译有限的排列集:例如,仅用于开发期间使用的浏览器,仅用于一种语言

但是,webapp的发布版本应该禁用draftcompile。同时,所有的laguage变量都应该被启用。maven配置文件对于构建的参数化非常有用。

使用gwt而不是json/jquery的原因是什么?

我会问同样的问题,因为你需要什么,GWT可能是不合法的需要。

以我的经验,我完全理解你的抱怨。GWT是一种很好的技术,它有很多好处。它也有缺点,其中之一就是编译时间长。GWT编译器进行了大量的静态代码分析,并且它不是具有数量级解决方案的东西。

作为一个开发人员,世界上最令人沮丧的事情是长时间的开发部署测试周期。我知道你的开发者的感受。

如果GWT的技术优势值得的话,您需要做出一个体系结构决策。如果是这样,您的开发人员将需要适应这项技术,并且有许多解决方案可以使开发更加容易。

如果有充分的理由使用GWT而不是纯JavaScript,那么您应该告诉他们这一原因(技能、针对非常难以实现的问题的调试、不想处理浏览器兼容性等)。如果没有好的理由,也许他们会生气。

我自己使用GWT,我知道这个编译时间:—)

如果您使用GWT在JavaScript小部件或类似的工具中实现简单,那么您可能应该考虑改用JavaScript。

您正在使用什么工具来编译项目?

很久以前我用过 蚂蚁 而且,当GWT应用程序(客户端代码)的所有源文件都没有更改时,就不调用GWT编译器任务,这已经足够聪明了。

但是,在那之后我用 马文 这是真正的痛苦,因为它的插件不认识到代码没有改变,GWT编译运行了一遍又一遍,无论是否需要。

我建议你 蚂蚁 对于GWT项目。另一种方法是重写maven插件,或者让开发人员习惯于长编译时间。