拆分Maven项目的推荐解决方案? [英] Recommended solution for splitting up Maven projects?

问题描述

在Maven中拆分大型企业项目的最佳方法是什么?

What is the best way to split up a large enterprise project in Maven?

很容易理解如何像这样垂直地划分事物...

It's easy enough to understand how to partition things vertically like this...

1. 您有一个DAO项目
2. DAO项目是以下项目的依赖项 服务项目
3. 服务项目是一个依赖项 该网络项目.

1. You have a DAO project
2. The DAO project is a dependency of the Service project
3. The Service project is a dependency of the web project.

有人在Maven.m中对大型项目进行分区/分割方面的最佳实践方面有意见吗

Does anybody have input on best practices in partitioning/splitting up really large projects in Maven.m

推荐答案

一些帮助了我的事情

• 将多模块项目用于相关的项目，并且仅用于相关的项目.仅在单个EAR中存在的EJB可以用于此. EJB和客户端应用程序不使用bo层.
• 每个pom一个工件，每个多模块项目一个可部署，不要浪费时间来解决这个问题.
• 创建包含常见依赖集的依赖项.这样一来，您可以将DAO，jdbc驱动程序和ORM工具包含在一个单一的依赖项中.它还使将数十个项目升级到ORM或DAO的最新版本变得容易得多.
• 创建构建器项目，仅用于运行程序集和创建部署集.这将使项目的多个部分保持同步.组装大型复杂的企业应用程序通常非常复杂，以至于您需要混合使用Maven，Shell脚本和/或ant:run任务以及数十个配置文件.将混乱放置在远离代码的项目中将在混乱蔓延之前将其包含.
• 创建测试器项目以进行持续集成.在这些poms中定义您的Web和应用程序服务器以及测试部署信息.使用父项目和公共属性文件将使测试部署更改更加容易.
• 仅在父pom中定义distributionManagement (如果可以将所有子项目作为子项目(或子项目)).
• 尽量不要依赖大文件(EAR，WAR)，这些文件会在每次构建时都塞入存储库中.消除了在每次快照时都将175mb WAR推到联系的需要，从而缩短了我们的构建时间.
• 尝试尽可能少地定义事物.干的构建是一个快乐的构建.具有30个Poms的源代码版本1.5或30个Pom的junit 3.8.2将会使升级到Java 6或junit 4.4变得更加困难.

• Use multi-module projects for projects that are related and only projects that are related. An EJB that exists only in a single EAR is a candidate for this. A bo layer that is used by an EJB and a client app is not.
• One Artifact per pom, one deployable per multi-module project Do Not Waste Time trying to get around this.
• Create dependency poms that include common sets of dependencies. That way you can include your DAO, your jdbc driver and your ORM tools with a single dependency. It also makes upgrading dozens of projects to the newest version of your ORM or DAO that much easier.
• Create builder projects that exist only to run assembly and create deployment sets. This will keep multiple parts of your project in sync. Assembling large complex enterprise apps is often complicated enough that you need a mix of maven, shell scripts and/or ant:run tasks plus dozens of profiles. Putting the mess in a project far away from your code will contain the mess before it spreads.
• Create tester projects for continuous integration use. Define your web and app servers in those poms as well as the test deployment info. Use of parent projects and common properties files will make testing deployment changes easier.
• Define distributionManagement in a parent pom only if it is possible to make all sub-projects a child (or grand-child) of it.
• Try not to depend on large files (EAR, WAR) being stuffed into your repository on every build. Removing the need for a 175mb WAR to be pushed to nexus on each snapshot improved our build times.
• Try to define things as few times as possible. A DRY build is a happy build. Having 30 poms with source-version 1.5 or 30 poms using junit 3.8.2 is going to make upgrading to java 6 or junit 4.4 that much harder.

希望这会有所帮助.

这篇关于拆分Maven项目的推荐解决方案?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！