web-dev-qa-db-ja.com

「必要なファイル名ベースの自動モジュールが検出されました」とは何ですか。警告はどういう意味ですか？

私のマルチモジュールプロジェクトでは、module-info.Javaいくつかのモジュールのみ。そして、コンパイル中にmaven-compiler-plugin:3.7.0次の警告が表示されます：

[警告] *必要なファイル名ベースの自動モジュールが検出されました。このプロジェクトをパブリックアーティファクトリポジトリに公開しないでください。 *

どういう意味ですか？これは、module-info.Javaプロジェクト全体ではなく？

javamavenmaven-3java-9maven-compiler-plugin
16
Dmitriy Dumanskiy

自動モジュールの要約

明示的なモジュール（つまり、module-info.Javaを備えたモジュール）は、必要なモジュールのコードにのみアクセスできます（一時的に 暗黙の読みやすさ は無視されます）。すべての依存関係がモジュール化されている場合、それは素晴らしいことですが、そうでない場合はどうなりますか？モジュール化されていないJARを参照する方法は？

自動モジュール が答えです。モジュールパスで終わるJARはすべてモジュールに変換されます。 JARにモジュール宣言が含まれていない場合、モジュールシステムは次のプロパティを持つ自動モジュールを作成します。

  • 推定された名前（これはここで重要なビットです）
  • 他のすべてのモジュールを読み取ります
  • すべてのパッケージをエクスポートします

Mavenはそのメカニズムに依存しており、module-info.jarを作成すると、すべての依存関係がモジュールパスに配置されます。

自動名

自動モジュールの名前を推測するには2つの方法があります。

  • マニフェストのエントリ
  • jARファイル名から推測

最初のケースでは、名前はメンテナーによって故意に選ばれたので、安定していると想定できます（たとえば、プロジェクトがモジュール化されても変更されません）。 2つ目はエコシステム全体で明らかに不安定です。すべてのプロジェクトセットアップが依存関係のまったく同じファイル名につながるわけではありません。

どういう意味ですか？

警告の理由は、依存関係の一部が自動モジュールであり、がマニフェストで将来のモジュール名を定義しないためです。代わりに、それらの名前はファイル名に由来するため、不安定になります。

安定した名前

では、なぜ不安定な名前がこのような問題になるのでしょうか？ライブラリがrequires guavaで公開され、私のフレームワークがrequires com.google.guavaで公開されると仮定します。今誰かが私のフレームワークであなたのライブラリを使用し、突然guavaとcom.google.guavaモジュールパス上。その問題に対する簡単な解決策はないので、回避する必要があります！

どうやって？たとえば、開発者がファイル名ベースの自動モジュールに依存するアーティファクトを公開しないようにします。 ????

18
Nicolai

[警告] *必要なファイル名ベースの自動モジュールが検出されました。このプロジェクトをパブリックアーティファクトリポジトリに公開しないでください。 *

これは、プロジェクト全体ではなく、module-info.Javaのモジュールが少ししかないためですか？

いいえ、module-info.Javaにリストされているいくつかのモジュールが原因ではありませんが、すべての自動モジュールに対してmaven-compiler-pluginによって生成されますモジュールのグラフにあります。

それはどういう意味ですか？

自動モジュールは所有者によって名前付きまたは明示的なモジュールに変換され、リポジトリに公開されるため、モジュール名も変更される可能性があるため、現在のプロジェクトを公開しないと主張されています。さらに、ここで注意すべき注意点は、Mavenの進捗ドキュメント〜> Java + 9 +-+ Jigsaw によると、JDK9互換のプラグインバージョンではまだ完全に準備ができていないということです。

このようなユースケースの例を示すだけです。これらの線を考え直してください-

  • アーティファクトcom-foo-bar:1.0.0-SNAPSHOT:jarを公開しました。
  • 私の別のプロジェクトcom-xyz:1.0.0はそれに依存しています。
  • 最終的に、あなたのプロジェクトはcom-foo-barを介してcom-xyzに推移的に依存します

  • コードをモジュール化して、次のようなものを利用することを計画している

    module your.module {
    requires com.foo.bar;
    requires com.xyz;
}

    （モジュールの宣言で 推移的な依存関係を指定する を個別に指定する必要があります）

  • すべてうまくいきましたが、それまではライブラリをモジュール化することにしました。
  • さて、私が最初にしたことは、モジュールに名前を付けることです！

  • そして、私はこのような私の努力を明確に呼び出すために素晴らしいことをしました：-

    module modular.com.foo.bar {}

  • モジュール化された方法で依存ライブラリ、そして最終的には依存ライブラリのコードを破壊することになります。

注：本番環境でSNAPSHOTを使用しないことについて同意しますが、最終的にはあなたはまだ開発段階にあるアーティファクトに依存しています。

Edit：@khmarbaiseのコメントから

人々はアーティファクトに公開することを望んでいることを理解していましたが、彼らが結果に気付いていない場合、あなたは将来これによって打たれるでしょう。

Mavenは、この場合の警告が非常に深刻であることを明確にしたいと思います。これは、代わりに障害である可能性がありますが、対処するのは悪いユーザーエクスペリエンスでした。

これに対処する理想的な方法は、ライブラリの所有者がアーティファクトをJDK9に移行することを計画し、ツリーがボトムアップでトラバースされることです。この場合、名前付き/明示的モジュールが、自動モジュール名とそのような警告。

4
Naman

とともに maven-compiler-plugin v3.7.0情報メッセージです。なぜそれを警告として見るのかわからない...

これは、Java 10ベースのプロジェクトをmodule-info.Java：

[INFO] Required filename-based automodules detected. Please don't publish this project to a public artifact repository!
0
testphreak

Module-info.Javaファイルでモジュール自体からクラスを追加したときに警告が表示されました。netbeansでテストファイルをデバッグするためにこれを実行する必要がありましたが、モジュールではないため、間違いです。

module net.my.package.xy
{
 requires Java.logging;
 requires Java.naming;
 requires javax.jms.api;
 //THAT GENERATES THE WARNING: 
 exports net.my.package.xy.MyClass;
}
0
Dimitri Virgin