2017-02-02 10 views
0

私は1つのグループid内に多くのパッケージを持っています。Bintray、共通グループidを持つパッケージをマージする

私のメインのグループIDは、次のとおりです。com.github.kondaurovdev

私はサブグループました: com.github.kondaurovdev.snippets com.github.kondaurovdev.akka_http ...

Iドンbintrayで多くのパッケージを作成したいのですが、jcenterにパッケージをリンクするのを待つ必要があるからです。

私は "解決策"を見つけました。 Bintray UIにはマージボタンがあり、同じグループidを持つすべてのパッケージを選択し、多数のサブパッケージを持つ1つのパッケージを持つことができます。このパッケージは一度だけリンクすることができ、JCenterリポジトリを使用してパッケージをダウンロードできます。カッコいい!

しかし、私は毎回マージしたくありません。サブパッケージを親パッケージに公開したいと思います。これは可能ですか?

私はsbt-bintrayを使用して成果物をアップロードしていますが、常に新しいパッケージを作成してコンテンツをアップロードします。

+0

あなたはBintrayの[REST API](https://bintray.com/docs/api/)を見ましたか? – jkinkead

+0

はい、私は見ました –

答えて

7

一部artifact_idsを単一のパッケージに統合されるべきかどうかを決定するための経験則は次のとおりです。

  1. プロジェクトは、単一のプロジェクトのサブモジュールであり、
  2. プロジェクトが一緒に
をリリースしています

私は何を意味するのかを示すいくつかの例を挙げてみましょう。私はかなり知られていて多様なSpring Frameworkプロジェクトを使用します。

  1. spring-contextspring-beansアーティファクトIDが同じBintrayパッケージにマージされます。それらは関連しており(Spring DIプロジェクトの中核部分)、一緒にリリースされています(4.3.6.RELEASEなど)。それらは同じBintrayプロジェクトの一部です - spring.framework
  2. spring-batch-coreは、Spring DIプロジェクトとはほとんど関係がないため、グループIDを共有していますが、org.springframeworkはBintrayの異なるパッケージにあります。
  3. 春データの異なるサブプロジェクトはもちろん関連していますが、リリースのバージョンが異なり、リリーススケジュールも異なります。たとえば、Spring Data Commonsはバージョン1.11.4ですが、Spring Data JPAはバージョン1.9.4です。したがって、それらのプロジェクトは関連しているかもしれませんが、同じパッケージを共有すると、Data JPAが1.11に達するまでに、Data Commons 1.11は、長い時間前にリリースされました。

私はそれが合理的であることを望む。

今、あなたの実用的な問題に。私は、あなたが含まれるリクエストに長い時間を待たなければならないことをお詫びします。あなたがそれが長すぎると感じたら私に個人的に連絡してください(@jbaruch)、私は何が起こっているのかをチェックすることができます。そうだとすれば、包括リクエストは1回限りの手続きパッケージです。どのくらいの頻度で新しいパッケージを導入しますか?

私が言及したように、あなたは同じパッケージにマージされるべきアーティファクトIDを持っている可能性が高いです(しかし、上記のルールで遊んでください)。その場合は、this exampleのように、 'build.sbt' publishTo設定でより広いパッケージを指定することができます。

+0

詳細な説明のためのJBaruchありがとう、私は共通のidsが異なるリリーススケジュールを持つパッケージについて考えたことはありません:) –

関連する問題