Clever Geek Handbook

完璧なメイヴン。 パート1

完璧ではないことは承知していますが、少なくともこれに近づける方法をお話しします。







すべてが1つの音符になるわけではないので、最初に計画を立てます。







  1. 問題文-協力するプロジェクトの構成、目標、問題の説明
  2. タスクの一部として開発用のMavenをセットアップする方法
  3. CI / CDの構成方法（ビルド、リリース、展開）
  4. 未解決の問題


挑戦する



それでは、問題のステートメントから始めましょう。 Javaでプロジェクトを開発している人々（会社、会社、サークル）のグループがあるとします。 同時に、オープンソースプロジェクト（OSS）とクローズドソースプロジェクトの両方があります。 プロジェクトを内部と呼びましょう。プロジェクトは互いに独立して開発されていますが、プロジェクトには依存関係があります。 何が欲しいですか：









これらの問題を複雑に解決することを理解することが重要です。したがって、すべてのウィッシュリストを実装しないと、システムはまったく機能しません。







また、以下に書かれていることはすべて私の個人的な意見であり、mavenはさまざまな方法で構成できることを認識しています。また、この記事の議論で、既存のモデルをさらに改善するのに役立つ何か新しいものを見つけたいと思っています。 私の弁護では、これから説明するモデルはすでに機能しており、1年以上経過していると言えます。 オープンな部分は、特にここにある BitBucketにあります 。







Mavenを構成する



外部ライブラリの集中化された依存関係管理



サードパーティの依存関係を管理するために、mavenには特別なdependencyManagementセクションと継承メカニズムがあります。 これが答えです。「企業」POMを作成し、そこからすべてのプロジェクトのルートPOMを継承します。 はい、そうなりますが、ここに詳細があります.... したがって、ここに私たちの将来の「企業」POMがあります。 







<?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>org.team</groupId> <artifactId>org.team.pom</artifactId> <version>0-SNAPSHOT</version> <packaging>pom</packaging> <properties> <spring.version>4.3.12.RELEASE</spring.version> <junit.ver>4.12</junit.ver> </properties> <dependencyManagement> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-framework-bom</artifactId> <version>${spring.version}</version> <type>pom</type> <scope>import</scope> </dependency> <!-- Exclude commons-logging from whole Spring --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${spring.version}</version> <exclusions> <exclusion> <artifactId>commons-logging</artifactId> <groupId>commons-logging</groupId> </exclusion> </exclusions> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>${junit.ver}</version> <scope>test</scope> </dependency> </dependencies> </dependencyManagement> <build> <pluginManagement> <plugins> <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>3.7.0</version> <configuration> `<source>1.8</source> <target>1.8</target> </configuration> </plugin> <plugin> <artifactId>maven-deploy-plugin</artifactId> <version>2.8.2</version> </plugin> <plugin> <artifactId>maven-surefire-plugin</artifactId> <version>2.20.1</version> </plugin> <plugin> <artifactId>maven-war-plugin</artifactId> <version>3.2.0</version> </plugin> <plugin> <artifactId>maven-clean-plugin</artifactId> <version>3.0.0</version> </plugin> <plugin> <artifactId>maven-install-plugin</artifactId> <version>2.5.2</version> </plugin> <plugin> <artifactId>maven-site-plugin</artifactId> <version>3.5.1</version> </plugin> <plugin> <artifactId>maven-jar-plugin</artifactId> <version>3.0.2</version> </plugin> <plugin> <artifactId>maven-resources-plugin</artifactId> <version>3.0.2</version> </plugin> <plugin> <artifactId>maven-assembly-plugin</artifactId> <version>3.1.0</version> </plugin> </plugins> </pluginManagement> </build> </project>


すべてが標準ですが、いくつかのことに注意を払いたくありません。









「企業」POM'aを使用すると、通常どのような問題/誤解が発生しますか？









このすべてを、この記事の以下の部分で分析します。 ここで、最後の2つのポイントについて簡単に説明します。







「企業」POMと個々のプロジェクトのルートPOMの違い



「企業」POMは、Javaバージョン、依存関係とそのバージョン、Mavenが従うことができるプロジェクトの一般的な制限、開発者への連絡など、会社のすべてのプロジェクトの一般的なルールを記述します。 「企業」POMには、特定の内部プロジェクト（バージョン、特定のプロファイル、および類似のもの）に関する情報（「依存関係」）がないようにする必要があります。







外部ライブラリのバージョンを追跡する方法と更新する頻度



ライブラリ/プラグインのバージョンは、maven自体を使用して簡単に追跡できます（ versions-maven-plugin ）。 これを行うには、次のフラグメントをpluginManagementセクションの「corporate」POMに追加します 







 <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>versions-maven-plugin</artifactId> <version>2.5</version> <configuration> <rulesUri>file://${user.dir}/rules.xml</rulesUri> <generateBackupPoms>false</generateBackupPoms> </configuration> </plugin>


そして、pom.xmlの横に、次の内容のrules.xmlファイルを作成します 







 <ruleset comparisonMethod="maven" xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd"> <ignoreVersions> <ignoreVersion type="regex">.*-does-not-exist</ignoreVersion> <ignoreVersion type="regex">.*[Aa]lpha.*</ignoreVersion> <ignoreVersion type="regex">.*(?i)beta.*</ignoreVersion> <ignoreVersion type="regex">.*pre.*</ignoreVersion> <ignoreVersion type="regex">.*[Dd]raft.*</ignoreVersion> <ignoreVersion type="regex">.*-rc.*</ignoreVersion> <ignoreVersion type="regex">20041228\.180559</ignoreVersion> <ignoreVersion type="regex">.*jbossorg.*</ignoreVersion> <ignoreVersion type="regex">.*dev.*</ignoreVersion> <ignoreVersion type="regex">\d+\.\d+</ignoreVersion> <ignoreVersion type="regex">.*(19|20)\d\d(0[1-9]|1[012])(0[1-9]|[12][0-9]|3[01]).*</ignoreVersion> <ignoreVersion type="regex">.*jboss.*</ignoreVersion> <ignoreVersion type="regex">.*atlassian.*</ignoreVersion> <ignoreVersion type="regex">.*xwiki.*</ignoreVersion> <ignoreVersion type="regex">.*b\d\d</ignoreVersion> <ignoreVersion type="regex">.*_ALPHA</ignoreVersion> <ignoreVersion type="regex">.*M\d</ignoreVersion> <ignoreVersion type="regex">.*RC\d</ignoreVersion> <ignoreVersion type="regex">.*\.jre7</ignoreVersion> <ignoreVersion type="regex">.*\.jre6</ignoreVersion> <ignoreVersion type="regex">.*CR\d</ignoreVersion> <ignoreVersion type="regex">.*M\d*</ignoreVersion> <ignoreVersion type="regex">.*pr\d</ignoreVersion> <ignoreVersion type="regex">.*android</ignoreVersion> <ignoreVersion type="regex">.*m\d*</ignoreVersion> <ignoreVersion type="regex">.*p\d*</ignoreVersion> </ignoreVersions> </ruleset>


原則として、これは必要ではなく、行<rulesUri>file://${user.dir}/rules.xml</rulesUri>



は削除できます。 私にとって、このファイルは、私が無視したいさまざまな「ジャンク」バージョンをフィルタリングするのに役立ちます。

その後、次のversions:display-dependency-updates



実行しversions:display-dependency-updates



およびversions:display-plugin-updates



と結果を取得します： 







 [INFO] The following dependencies in Dependency Management have newer versions: [INFO] com.amazonaws:aws-java-sdk-core ................. 1.11.221 -> 1.11.237 [INFO] com.amazonaws:aws-java-sdk-dynamodb ............. 1.11.221 -> 1.11.237 [INFO] com.amazonaws:aws-lambda-java-core .................... 1.1.0 -> 1.2.0 [INFO] com.amazonaws:aws-lambda-java-events .................. 2.0.1 -> 2.0.2 [INFO] com.google.guava:guava .......................... 23.3-jre -> 23.5-jre [INFO] com.google.guava:guava-gwt ...................... 23.3-jre -> 23.5-jre [INFO] com.google.inject:guice ................................. 3.0 -> 4.1.0 [INFO] io.sentry:sentry-logback .............................. 1.6.1 -> 1.6.3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     


 [INFO] The following plugin updates are available: [INFO] org.codehaus.mojo:sonar-maven-plugin ......... 3.3.0.603 -> 3.4.0.905 [INFO] [INFO] All plugins have a version specified.


ちなみに、2番目のコマンドは、バージョンを指定せずに何らかのプラグインを使用すると警告を出します（ただし、プロジェクトPOMで実行する必要があります）







要するに、それはすべて「企業」POMについてです。 次の部分では、プロジェクトの典型的な構造について、そしておそらく、中央および企業リポジトリ内のアーティファクトのデポの組織について話す予定です。







More articles:


All Articles