我注意到最近我们的xpages应用程序构建/编译时间已大幅增加。清洁应用程序甚至可能需要几乎整整一分钟。
这是一个非常复杂的应用程序，有一些控件（自定义控件和java控件）和许多遗留代码（js，ls，java），但类似的应用程序构建在纯ecplise与相同的Java代码（这是只有部分此应用程序更改）在不到3秒的时间内清理......
我已经使用rcp调试控制台做了一些研究，并注意到清理时有一些疯狂的流量总计达到15000个事务（而且这个数据库只有300个包含代码的设计元素！）
日志看起来像是一遍又一遍地重复：
... [1240：0007-03E0]（13586-124 [14561]）OPEN_NOTE（REPC12579BB：0033C2FE-NT00003052,00400000）：0ms。 [48 + 17446 = 17494]
[1240：0007-03E0]（13587-124 [14562]）OPEN_NOTE（REPC12579BB：0033C2FE-NT00006C12,00400000）：1ms。 [48 + 32118 = 32166]
所以我的问题是：
这是否意味着xpages构建器写得非常糟糕或者我不知道什么？
答案 0 :(得分：1)
您在做项目 - 构建还是项目 - 全部构建。如果后者并且您打开了多个NSF，则构建将针对所有应用程序运行。您可以在Package Explorer中关闭应用程序。
当你说有300个设计元素时，那是你在Applications Navigator中看到的数字吗？请记住，正在构建的实际文件的海洋中只有一滴水。 Package Explorer将显示每个XPage和Custom Control都有其他Java和xsp-config文件。这些是从您在XPage和Custom Control设计元素中看到的XML标记编译而来的Java类。但这并不是所有的建设。服务器或本地数据库无法运行.java文件。它需要运行为相关平台编译的.class文件。此外，还有其他.class文件需要在编译时合并到应用程序中，可以通过在Package Explorer视图中选择Project - Properties来查看。如果您有本地化，则每个XPage / Custom Control的每种语言仍有更多文件。当然还有像xsp.properties，激活器.java文件和.class文件这样的文件。
XPage构建器可能看起来很糟糕，因为这些文件需要创建。但它实际上非常聪明，因为我们不需要编写Java而我们不需要定义应用程序所依赖的所有相关Java文件。我们不需要为各种控件创建新的XSPInput或任何Java类。我们可以拖放，从漂亮的面板设置属性，为我们提供下拉菜单或布尔选择器等。没有这些，每次保存后应用程序的构建时间会更快，但开发时间会更慢。
答案 1 :(得分：1)
它毕竟出现了构建时间问题的解决方案 - 它是新的Domino Designer 9.升级到公测版后，构建时间急剧下降（仅几秒钟）！