在多模块项目中使用配置文件 [英] Using profiles in multimodule project

查看:117
本文介绍了在多模块项目中使用配置文件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个多模块Maven项目.项目布局如下:

I have a multimodule maven project. Project layout is described below:

PARENT
  |-CHILD1
  |-CHILD2

父项目具有pom打包类型,并且将CHILD1CHILD2项目声明为模块.同样,PARENT项目声明了配置文件dev,该配置文件声明了一些属性. CHILD1项目具有jar包装类型,并通过添加一些依赖项(例如,对commons-collections的依赖项)来覆盖" PARENT dev概要文件. CHILD2项目具有战争包装类型,并且依赖CHILD1项目. CHILD2还通过添加另一个依赖项(例如,依赖于commons-io的依赖关系,与我的项目CHILD1中的那个不相关)来替代"父dev配置文件. 然后,当我运行mvn clean install -Pdev时,maven不会将commons-collections.jar(在CHILD1项目中声明的依赖项)放到CHILD2项目的WEB-INF/lib中,但是commons-io.jar在那里.

Parent project has pom packaging type and declares CHILD1 and CHILD2 projects as modules. Also PARENT project declares profile dev which declares some property. CHILD1 project has jar packaging type and "overrides" PARENT dev profile by adding some dependency(dependency on commons-collections for example). CHILD2 project has war packaging type and has dependency on CHILD1 project. Also CHILD2 "overrides" parent dev profile by adding another dependency(dependency on commons-io for example, I mean dependency that is not related with that one in project CHILD1). Then when I run mvn clean install -Pdev maven doesn't put commons-collections.jar(dependency that is declared in CHILD1 project) to WEB-INF/lib of CHILD2 project, but commons-io.jar is there.

所以,问题是:如果目标项目在该概要文件中声明了另一组依赖关系,为什么不从目标项目的依赖项目中声明的概要文件中放行依赖关系呢?

So, the question is: Why does not maven put dependencies from profiles that are declared in dependent projects of target project if target project declares another set of dependencies in that profile?

实际上,我有更多的项目和更多的依赖关系,这些依赖关系在不同的配置文件中有所不同.而且我想在该项目的pom.xml中声明特定于项目的依赖项(假设在项目中声明配置文件将覆盖"父配置文件声明)

Actually I have much more projects and much more dependencies that varies in different profiles. And I want to declare project specific dependencies in that project pom.xml(supposing that declaring profile in project will "override" parent profile declaration)

推荐答案

我假设您希望在开发时能够在本地进行测试,针对暂存环境测试更改并最终部署到生产环境.

I am assuming that you want to be able to test locally when developing, test your changes against a staging environment and finally deploy to production.

您需要牢记的关键是,当将工件部署到本地/远程存储库时,活动概要文件不属于所部署内容的一部分,因此当您通过概要文件添加依赖项时,情况变得非常危险.您无法知道该Web应用程序是在DEV配置文件处于活动状态还是PROD配置文件处于活动状态的情况下构建的,然后当该构建的构件被部署到生产环境中时,您可能会被束之高阁.

The critical thing that you need to keep in mind is that when an artifact gets deployed to the local/remote repository, the active profiles is not part of what gets deployed, so when you add dependencies via profiles things become very dangerous as you have no way of knowing if the webapp was built with the DEV profile active or the PROD profile active, and then when that built artifact gets deployed into production you could be royally screwed over.

因此,这是确保您的工件独立于部署环境的缺点.

So the short of this is that you ensure that your artifacts are independent of deployment environment.

这意味着,例如,您将从以下位置选择配置:

This means that, for example, you will pick up configuration from:

  • classpath上的文件
  • 系统属性
  • jndi条目

因此,例如,如果部署到Tomcat,则可以将configuration.properties放入$CATALINA_HOME/lib

So for example, if deploying to Tomcat, you might put a configuration.properties into $CATALINA_HOME/lib

您的Web应用程序在启动时将使用getClass().getResource('/configuration.properties')解析属性文件,如果缺少该文件,则启动失败(快速失败)

Your webapp on startup will use getClass().getResource('/configuration.properties') to resolve the properties file and fail to start-up if the file is missing (fail-fast)

您可以通过将测试版本的configuration.properties放在src/test/resources中,让您的单元/集成测试使用不同的配置.

you can let your unit/integration tests use a different config by putting a test version of configuration.properties in src/test/resources.

您对应用程序的<scope>provided</scope>样式依赖项使用相同的原理.换句话说,容器应提供与容器签订合同的依存关系.因此,您也可以使用Maven为自己构建tomcat/jetty的生产版本,并将所需的依赖项添加到该程序集中.就像生产版本使用MySQL数据库一样,因此您需要将mysql-jdbc驱动程序添加到$CATALINA_HOME/lib中.使用Assembly插件执行此操作相对容易,因为您实际上只是在重新打包包含某些位而排除了某些位的zip.

You use the same principle for the <scope>provided</scope> style dependencies of your application. In otherwords a dependency that the container is contracted with providing should be provided by the container. So you might build the production version of tomcat/jetty for yourself using Maven also and add in the required dependencies into that assembly. This would be things like the production version uses a MySQL database, so you need to add the mysql-jdbc driver into to $CATALINA_HOME/lib. It is relatively easy to do this with the assembly plugin as you are really just repacking a zip with some bits included and others excluded.

在本地进行测试时,您将需要利用助手插件的run目标,例如jetty:runtomcat:run.此处的解决方案是通过配置文件为这些插件提供依赖没有错,因为您不会影响工件的依赖,而仅影响插件的类路径.

When testing locally you will want to make use of the helper plugins' run goals such as jetty:run and tomcat:run. The solution here is that there is nothing wrong with giving these plugins dependencies via profiles because you are not affecting the dependencies of the artifact you are only affecting the plugin's classpath.

例如

<project>
  <!-- ... some stuff .. -->
  <profiles>
     <profile>
       <id>DEV</id>
       <build>
         <plugins>
           <plugin>
             <groupId>org.mortbay.jetty</groupId>
             <artifactId>jetty-maven-plugin</artifactId>
             <dependencies>
               <dependency>
                 <groupId>commons-dbcp</groupId>
                 <artifactId>commons-dbcp</artifactId>
                 <version>1.4</version>
               </dependency>
               <dependency>
                 <groupId>mysql</groupId>
                 <artifactId>mysql-connector-java</artifactId>
                 <version>5.1.18</version>
               </dependency>
             </dependencies>
           </plugin>
         </plugins>
       </build>
     </profile>
   </profiles>
 </project>

您还可以配置系统属性或添加的类路径以拉入所需的配置文件.

You can also configure system properties or classpath additions to pull in the required configuration file.

所有这些的最终结果是工件保持了环境独立性,您可以轻松地在各种环境下进行测试

The net result of all this is that the artifact remains environment independent and you can test easily against the various environments

希望这可以回答您的问题(即使是侧身)

Hope this answers your question (even if sideways)

这篇关于在多模块项目中使用配置文件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆