Eclipse项目布局类路径问题

时间:2012-05-17 21:12:21

标签: java eclipse java-ee ear eclipse-wtp

我目前正在使用Eclipse进行大规模项目。通常,作为一个单独的团队,这些问题不会成为问题,但由于我们的团队不是一个人,我们需要能够分解某些团队成员要处理的项目。

简单来说,假设我有两层要分开: 1.每个DAO都是一个单独的Java项目,需要单独处理 2. Web层服务层包含我们所有的服务端点,并且必须能够引用所有DAO。该层作为动态Web项目在Tomcat上运行,并使用Adobe LiveCycle Data Services作为处理端点创建和管理的部分。

现在,我们遇到的问题是,当我们创建DAO并单独测试它时,它运行得很好。但是当我们将它引入我们的服务项目并尝试运行它时,我们开始得到与我们有两个不同版本的某些jar引用相关的各种问题,因此我们在运行服务器时开始出错。

因此,我们知道我们可以通过拉出问题罐并确保将来再次出现这个问题来解决问题,但正如我之前所说的那样,这是一个大型项目,有多个人正在研究它我们不想花时间在枪口下清除依赖问题。

我们正在寻找有关在何处进行替代解决方案的建议?我们的团队是JavaEE的新手,因此我们对可以用来将所有内容联系在一起的内容没有多大影响,或者它是否是可行的解决方案。我们是否应该考虑将DAO转换为EJB并将它们部署到EAR库中?如果是这样,我们的服务层在哪里,服务层是否能够引用DAO类,因为EJB维护它自己的类路径(从我们读过的内容?)我们是在向错误的路径看,还是我们完全错了在我们目前对JavaEE的理解中?

非常感谢任何帮助。我们仍处于该项目的框架阶段,我们希望确保我们能够长期维护它。

3 个答案:

答案 0 :(得分:2)

我是Maven推荐的第二个。这可以为您的项目结构添加各种理智。

Maven甚至可以通过mvn eclipse:eclipse

生成Eclipse工作区

关于EJB的重要说明。从ava EE 6开始,您不再需要将EJB与Servlet分开,并且可以在war文件中的同一个jar中一起使用它们。

因此可以理解,使用EJB或不再像以前那样对包装或类加载器产生任何影响。这些现在是单独的决定。如果您希望类加载器分离及其带来的复杂性,EAR和类加载器分离现在应该被视为您可能想要使用的功能。大多数应用程序根本不需要它,并且仅仅包含一个包含servlet,ejbs,jpa实体,cdi bean,jaxrs服务以及您需要的任何其他内容的war文件。您可以自由决定如何分离它们,或者根本不想分离它们。

EJB由于事务管理而做了很好的DAO,you don't get from plain Tomcat但可以通过TomEE在Tomcat中使用,并且在Eclipse中正常工作。出于这个原因,您应该考虑使用EJB,而不是出于依赖性原因。

旁注,因为您是Java EE的新手,您可能会发现这有用:

答案 1 :(得分:2)

为了在1人以上的团队中使用Java EE时,我可以建议:

  • 使用Maven管理构建过程和库依赖项。

    Maven学习曲线很小,但是一旦你掌握了它,你将会感激不尽。通过使用Maven,您不再依赖Eclipse来管理类路径。

    我认为在团队合作时,我认为真正有用的是install功能。假设您正在使用EJB模块的1.0版本,比如core-ejb-module-1.0,并且您已经将其置于稳定状态,并希望项目中的每个人都可以从现在开始引用它。

    然后在其上运行这样的maven命令:mvn clean package install

    Maven将清理此模块,编译它,运行测试,创建jar,然后将其安装到您定义的存储库中。可以是贵公司的任何计算机。

    现在你可以告诉那些在其他项目上工作的人在他们的.pom文件上更新这个依赖版本,在他们运行的下一个版本中,在编译之前,maven会下载这个库然后使用它。真的很整洁。没有更多的类路径地狱。 (还有其他方法可以始终自动引用此post中所述的最新库,但有一些警告。无论如何,这只是一个例子。)

  • 使用JPA / EJB代替DAO Pattern。

    有些人说DAO意味着任何类型的数据访问,其他人确实意味着他们使用DAO模式来访问对象。如果是这种情况,则在使用JPA时不再需要使用它。 (至少对于大多数常见情况而言)。

    就我而言,我有一个通用的EntityService,它能够对任何实体进行CRUD操作,并具有集中的查询管理功能。然后,每个应该执行数据库相关操作的EJB都可以注入这个人并完成它的工作。

作为一个建议,对于Maven,你的项目可以这样组织:

  • 核心项目结构
    • core(the pom root)
    • core-ejb-module(包括所有通用EJB,例如EntityService。)
    • core-jpa-module(包括所有JPA通用定义,如Interfaces,MappedSuperclasses等。)
    • core-jsf-module(包括所有JSF泛型定义,如抽象控制器,FacesContext的通用转换器和包装器等。)

现在你有了一个核心通用模块设置,你可以创建:

  • 应用程序结构
    • app(pom root)
    • app-ear-module(包括此应用程序中的所有其他模块。共享jar位于ear / lib文件夹中,因此所有其他模块都可以引用它们。)
    • app-ejb-module-a(包括用于应用程序业务层的EJB。它使用core-ejb-module)
    • app-ejb-module-b(你可能有很多ejb模块。你甚至可能有一个只包含ejb模块的项目。其他应用程序会通过Maven声明它们对它们的依赖。)
    • app-jpa-module(包含代表数据库表的JPA实体的定义。取决于core-jpa-module)
    • app-web-module(保存此应用程序的页面,控制器和转换器。)

我认为你明白了。事情往往是松散耦合的,您可以根据自己的喜好组织项目。

这只是一个简单的例子来说明。我没有解释很多关于Maven的内容,但如果你感兴趣我会认为它确实对你很有帮助。

我希望它能为您提供一些想法,并可能以任何方式为您提供帮助。

[]的

答案 2 :(得分:1)

如果您可以使用相同的依赖项集运行所有子组件,您可能会发现迁移到Maven构建很有帮助。

使用Maven,您可以定义一个顶级项目,在一个位置管理所有第三方依赖项版本,因此所有模块都是针对相同的库版本构建,测试和部署的。您也可能会发现Maven非常适合您采用的多模块方法,因为它可以确保在其中一个依赖项发生更改时正确地重建项目。

您仍然可以像以前一样使用动态网络项目; Eclipse将自动部署DAO作为服务项目的一部分(IIRC,您需要将DAO定义为实用程序模块)。

如果您确实关闭了EJB根目录,那么每个EAR都将获得自己的类加载器是正确的,因此可以使用不同的依赖关系集。但是,在你的位置上,我倾向于首先考虑改进你的依赖管理 - 它可能会更便宜,更容易。