如何指定maven的分配管理组织范围？ [英] How to specify maven's distributionManagement organisation wide?

问题描述

我正在试图找出如何组织许多（大约50多个）maven2项目，以便它们可以部署到中央的nexus存储库。当使用 mvn deploy 目标时，需要在distributionManagement标签中指定目标，如下所示：

 < distributionManagement> 
< repository> 
< id> nexus-site< / id> 
< url> http：// central_nexus / server< / url> 
< / repository> 
< / distributionManagement> 
  

现在，我不希望每个pom.xml（其中50+以上）包含这个一遍又一遍地阻止。我的第一个虽然将是 settings.xml 文件，但似乎不可能（按设计）在那里定义它。
那么第一个问题是，为什么会这样呢？如果有可能，我可以在maven2发行版的settings.xml中指定，可以将其分发给所有开发人员。

我发现的唯一可能的解决方案是创建一个组织范围的master-pom项目，其中包含这些设置，并且通过< parent> 标签使所有其他pom.xml依赖于此master-pom 。但是在多模块构建中看起来很奇怪：

   - 主配置POM（pm）
  - 项目1父pom（p1与模块1和模块2作为模块）
  - 项目1模块pom（以pm为父）
  - 项目2模块pom（以pm为父）
  

通常我读到所有的文档，模块poms应该使用父pom，而不是一些不同的。但是在阅读了关于继承v。汇总的maven网站之后，它写的确是有可能的。

我发现的一个问题是使用maven网站生成，这个设置有问题（如果没有直接的参考，模块不会被正确连接）

那么这是一个有效的方法吗？任何其他更明显的更简单的解决方案？

解决方案

最好的解决方案是创建一个简单的父pom文件项目（包装pom）一般用于您组织的所有项目。

  <？xml version =1.0 = UTF-8 >？; 
< project xmlns =http://maven.apache.org/POM/4.0.0xmlns：xsi =http://www.w3.org/2001/XMLSchema-instance
 xsi：schemaLocation =http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd\"> 
< modelVersion> 4.0.0< / modelVersion> 
 
< groupId> your.company< / groupId> 
< artifactId> company-parent< / artifactId> 
< version> 1.0.0-SNAPSHOT< / version> 
< packing> pom< / packaging> 
 
< distributionManagement> 
< repository> 
< id> nexus-site< / id> 
< url> http：// central_nexus / server< / url> 
< / repository> 
< / distributionManagement> 
 
< / project> 
  

这可以构建，发布和部署到您的本地连接，所以每个人都可以访问它的工件。

现在，对于您希望使用的所有项目，只需包含以下部分：

 code><亲本GT; 
< groupId> your.company< / groupId> 
< artifactId> company-parent< / artifactId> 
< version> 1.0.0< / version> 
< / parent> 
  

此解决方案将允许您轻松地将其他常见问题添加到所有公司的项目中。例如，如果您希望将JUnit的使用规范化到特定的版本，这将是完美的地方。

如果您有使用多模块结构的项目有自己的父母，Maven也支持链接继承，所以完全可以让你的项目的父pom文件参考你公司的父母，并让项目的子模块甚至不知道你公司的父母。

从您的示例项目结构中可以看出，您尝试将您的父项目与您的聚合器pom处于同一级别。如果您的项目需要自己的父项，我发现的最佳方法是将父级包含在与其余模块相同的级别，并将您的聚合器pom.xml文件放在所有模块目录所在的根目录下。 / p>

   -  pom.xml（聚合器）
  - 项目 - 父
  -  project-module1 
 -  project-module2 
  

您使用此结构的方式是将父模块包含在聚合器中并构建所有内容来自根目录的mvn install。

我们在我的组织中使用这个确切的解决方案，它经受了时间的考验，对我们来说很好。 / p>

I'm trying to figure out how to organize many (around 50+) maven2 projects, so that they can deploy into a central nexus repository. When using the mvn deploy goal, one does need to specify the target in the distributionManagement tag like this:

<distributionManagement>
   <repository>
      <id>nexus-site</id>
        <url>http://central_nexus/server</url>
   </repository>
</distributionManagement>

Now, i don't want every single pom.xml (of those 50+) to contain this block over and over again. My first though would be the settings.xml file, but it seems it is not possible (by design) to define it there. So, the first question would be, why is that the case ? If it would be possible i could specify it in the settings.xml in the maven2 distribution, which could be distributed to all developers.

The only possible solution i've found was to create an organisation-wide master-pom project, that does contain these settings, and make all other pom.xml depend on this master-pom via <parent> tag. But this looks kind of strange in multi-module builds:

- master configuration POM (pm)
- Project 1 parent pom (p1 with module 1 and module 2 as modules)
    - Project 1 module pom (with pm as parent)
    - Project 2 module pom (with pm as parent)

Usually i read in all documentation that the module poms should use the parent pom, not some different one. But after reading the maven website about Inheritance v. Aggregation it is written that it is indeed possible.

One problem i found was with the maven site generation, which does seem to have problems with this setup (modules does not get linked correctly if they have no direct back-reference)

So, is this a valid approach ? Any other, more obvious, simpler solution to the problem ?

解决方案

The best solution for this is to create a simple parent pom file project (with packaging 'pom') generically for all projects from your organization.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>your.company</groupId>
    <artifactId>company-parent</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <distributionManagement>
        <repository>
            <id>nexus-site</id>
            <url>http://central_nexus/server</url>
        </repository>
    </distributionManagement>

</project>

This can be built, released, and deployed to your local nexus so everyone has access to it's artifact.

Now for all projects which you wish to use it, simply include this section:

<parent>
  <groupId>your.company</groupId>
  <artifactId>company-parent</artifactId>
  <version>1.0.0</version>
</parent>

This solution will allow you to easily add other common things to all your company's projects. For instance if you wanted to standardize your JUnit usage to a specific version, this would be the perfect place for that.

If you have projects that use multi-module structures that have their own parent, Maven also supports chaining inheritance so it is perfectly acceptable to make your project's parent pom file refer to your company's parent pom and have the project's child modules not even aware of your company's parent.

I see from your example project structure that you are attempting to put your parent project at he same level as your aggregator pom. If your project needs its own parent, the best approach I have found is to include the parent at the same level as the rest of the modules and have your aggregator pom.xml file at the root of where all your modules' directories exist.

- pom.xml (aggregator)
    - project-parent
    - project-module1
    - project-module2

What you do with this structure is include your parent module in the aggregator and build everything with a 'mvn install' from the root directory.

We use this exact solution at my organization and it has stood the test of time and worked quite well for us.

这篇关于如何指定maven的分配管理组织范围？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！