Eclipse主要插件Lomboz介绍

配置JDT和Lomboz


在你利用Lomboz作为你的J2EE项目的开发工具之前，你必须完成以下的配置工作。

第一步：Java

首先必须明确，新建Java项目的输出文件和源代码的形势。

从菜单“窗口”―〉“首选项”中打开首选项对话框，并展开左侧树中的“Java”条目，选择“构建路径”。将“源和输出文件夹”的内容从“项目”更改为“文件夹”，源文件夹名“src”，输出文件夹名“bin”。修改后，选择“应用”按钮保存修改，如下图：

第二步：Lomboz设置

　大多数应用服务器使用标准Java编译器（javac）编译JSP文件，javac包含在标准JDK的tools.jar中（而非JRE的tools.jar）。

　所以必须正确选择JDK的tools.jar文件,它通常位于标准JDK的安装目录下的“lib”文件夹下。
Enable JSP Syntax checking 如果你有大量的JSP文件，并且在你每次保存的时候不想检查它们的语法，那么这项功能将会非常有用。缺省情况下此功能是被选中的。如果你不需要这样的功能，可以将此功能去掉并“应用”保存。

　Server restart 如果在你重新布署工程后，你的应用服务器没有能够重新装载你的Web容器或EJB容器，那么使用此项，将会非常有用。选择此功能，Lomboz会帮你在重新装载容器后，启动你的应用服务器。这项设置对于使用Tomcat的你来说也许会非常有用。

　Update server classpath and deployment parameters此功能使Lomboz能检查和锁定工程的Classpath和已选择的工程布署工具。如果你改变了一个服务器的定义那么此项功能会非常有用。缺省情况下此功能是被选中的。如果你不选中此项，那么每次你在改变了服务器的定义的时候你都不得不去检查和锁定一下你的工程的Classpath。

Select Code Generation Plugin

　Lomboz 3.0支持可扩展代码插件。你可以选择一个支持生成EJB代码和注释的插件。Lomboz所提供的默认插件是"XDoclet"。

重要内容：

Use application server classpath

　这个功能会使你在启动应用服务器的时候使用您下一步服务器定义中的Classpath。它将不会使用你所建立的Java工程中的Classpath。

　如果你不选择此功能，那么Lomboz将使用你Java工程中的Classpath去启动应用服务器。这样的缺点是Web容器或EJB容器的将会出现两次的Classpath。一次是Eclipse的Java工程中，另一次是EJB的Jar和Web的war。这将造成意想不到的类装入问题，如果你有过这样的经验，那么就会使你确定要选择这个功能。
第三步：服务器定义

　Lomboz能够适应几乎所有的Java应用服务器。为了使Lomboz创建一个正确服务器地址的脚本你需要设定一些参数。你设置的这些参数被当作启动服务器和寻找本地部署Web应用和EJB应用的文件的默认设置。

　这些服务器配置文件被存放在Lomboz插件目录下的一个名叫“servers”的文件夹下，当需要定义的时候Lomboz都会扫描这个文件夹。


下一步就是检查和设置这些服务器的定义。

尽管已经为这些参数预先定义了一些值，这些默认值并不符合你所需要的配置。

重要的一点是在进行了更改后一定要记住“应用”你的更改，使之保存。
Properties page

打开首选项对话框，选择Lomboz下的Server Definitions，然后按照以下步骤进行更改：

选择Servers Types中你要是用的服务器，然后更改相应的服务器所在目录和Classpath变量的内容：

Classpath page

　接下来就是查看在服务器启动时，那些库是必须加载的。我们在之前设置的Classpath variables已经被应用在这里（笔者提示：上一步应用之后，确定关闭首选项，重新打开首选项，Classpath variables被应用）。你可以在这个列表中增加或删除，服务器启动时必须加载的库，但必须记住任何修改之后都要“应用”。


第四步：验证Classpath variables

　验证这些变量是否被设置，方法是打开“首选项”对话框，展开Java条目，选择“构建路径”―〉“类路径设置”条目，你应该看到你所设置的变量已经被加入到列表中，如图：


第五步：对于EJB开发的Xdoclet配置

　Xdoclet 仅支持 Java2 JDK ,不支持1.1的老版本

　确保JDK的Lib目录下的tools.jar文件在classpath变量中

　确保JDK的Bin目录在Path变量中
　Lomboz观念表明J2EE应用开发是一步接一步完整的开发过程。所以，它必须包含应用开发过程的所有阶段，诸如：编码，编译，部署，测试，调试等。

　一个符合J2EE规范的程序相对于一个普通Java程序的区别在于应用程序被部署在根据Web应用和EJB应用所组织的有标准组件的包模式中，一部分这样的应用程序构成了企业级应用。

　依照J2EE的规格标准，这些Web和EJB应用有着很好的定义和标准的结构，这些结构形成了J2EE应用中“Modules”的内容。对于这些“Modules”，一个应用服务器提供和管理运行环境。一个应用服务器能够同时管理很多modules。

　“Development must be a reflection of the end goal, the production environment”.

　一个企业级的应用是由很多modules组成的，所以一个符合J2EE规范的工程必须能够在同一时间操作多个modules。这些modules不会与它们产生的副本有任何不同。
“Developers must not be limited with our restricted views of how things should happen”.

　我们经常倾向性的去想我们所积累的经验能解决开发者遇到的大多数问题。但是这样想是存在漏洞的。因为对于每个工程来说开发者还要注意很多细节。我们正试图利用Lomboz的自动化使这些问题能提早的发现。开发者能观察和修改Lomboz的行为通过自定义的设置。

这里有三种方式让你通过使用Lomboz为你的工程增加J2EE的特性：

　New J2EE Projects: 新建J2EE工程，这个选项适于你刚开始建立一个J2EE工程，J2EE工程向导将帮助你设置你工程中的一些重要的内容。

　New J2EE Module: 新建J2EE Module,这个选项适合你想为你已经存在的工程增加新的Web和EJB Module。J2EE Module向导将会在你的工程中创建一个新的Module。这个选项可能需要额外步骤去确定你的Java Build Path(classpath)是否包含必要的库文件。
　New Ear Module: 这个选项适合于你想将你的J2EE modules打包成一个应用服务器的文档。EARs 是主要的一个封装工具，它们包含多种多样的Web和EJB modules，它们可以形成一个应用。你可以从你已经存在的Web和EJB modules中组成一个EAR文件。同样，很多应用服务器（例如：WebSphere, Orion, Oracle）并不能很容易的认可独立的Web和EJB modules。对于它们最好的办法配置一个EAR包，并使用它作为主要的部署单元。

　Enabling existing modules: 这个选项适用于你有一些不是用Lomboz创建的Web和EJB modules。通过增加必须的Lomboz成分和符合J2EE规范内容你将可以使它们被看作是J2EE的modules。这个选项可能需要一些额外的步骤去确定你的Java Build Path(classpath)是否包含必要的库文件。  

查看本文来源