日本語 : Hosting plugins

Created by Unknown User (bols_blue), last modified on Jan 06, 2013

このページは記述し終わっていません、記述してない部分は英文を代わりに載せておきます。

私たちは、ジェンキンズ・コミュニティー・リポジトリ( Github あるいは svn.jenkins-ci.org )で plugin をホスティングするように開発者におすすめします。
これは、コミュニティーが plugin からの利益を得ると同時にコミュニティーがあなたを助けることをより簡単にします。
あなたが他のものに移る場合さえ、コミュニティーの他の誰かがあなたの代わりに仕事を見つけることができます。
より詳細な内容は私たちはどのように働くか (英文 how we work )で見ることができます。

Contents

ホスティングのリクエスト(Request hosting)

ディベロッパーリストに参加して、GitHub を使用する場合は自分の GitHub ID を、Subversion を使用する場合はjenkins-ci.orgアカウントIDを伝えるメッセージを送ることで、あなたをレポジトリへのアクセス権を得ることができます。
ほとんどのpluginsがgithub(jenkinsci-devによる)に移ったので、可能な限り Subversion の利用はさけてください。
GitHub の上に既にリポジトリを持っていれば、あなたは私たちはそこから fork するように言うことができます。
私たちが1つ作成することができるように、私たちにpluginの名前を教えてください。
https://github.com/jenkinsci(GitHub)の下のリポジトリへの admin アクセスを得るでしょう。
リポジトリをよく作っている場合は、自分でforkなどのアクセスをすることができます。
より詳細については、IRCボット( 英文 IRC Bot )を参照してください。

あなたが Subversion で pluginをホストしたければ、共同作業を促進するために git を推奨していますが、私たちは https://svn.jenkins-ci.org/trunk/hudson/plugins/ で例外としてそれをすることができます。ほとんどのpluginsがgithub(jenkinsci-devによる)に移ったので、可能な限り Subversion の利用はさけてください。

ソースコードのインポート(Importing source code)

コミット権とレポジトリを得ることができれば、あなたはソースコードをインポートすることができます:

$ cd path/to/yourplugin
$ git init
$ git add pom.xml src
$ git commit -m "initial import of my plugin"
$ git remote add origin git@github.com:jenkinsci/MYPLUGINNAME.git
$ git push origin master

さらに私たちは、余分のものを整えるために他のpluginのPOMファイル(このような)をあなたが見るように勧めます。
例えば、通常<groupId>はデフォルトであるorg.jenkins-ci.pluginsを使用するために削除されます(<parent>セクション中のものではなく plugin のための groupId です)。
<repositories>および<pluginRepositories>は同様に撤去することができます。
もし、分からないことがあったり、助けを必要とする場合は、devリストと連絡をとってください。

POM にレポジトリの場所を定義する (Declare your repository in your POM)

pluginsのためにPOMの中であなたのリポジトリの位置を宣言する必要があります。Githubを利用する場合、次のようになります:

  <scm>
    <connection>scm:git:ssh://github.com/jenkinsci/MYPLLUGINNAME.git</connection>
    <developerConnection>scm:git:ssh://git@github.com/jenkinsci/MYPLUGINNAME.git</developerConnection>
    <url>https://github.com/jenkinsci/MYPLUGINNAME</url>
  </scm>

Subversion でのディレクトリ名がplugin artifactIdと一致し、バージョンが 1.398以上であれば、svn.jenkins-ci.orgの中のPluginsはこれを省略することができます。そうでない場合は以下のようにPOMに追記します:

  <scm>
    <connection>scm:svn:https://svn.jenkins-ci.org/trunk/hudson/plugins/MYPLUGINNAME</connection>
    <developerConnection>scm:svn:https://svn.jenkins-ci.org/trunk/hudson/plugins/MYPLUGINNAME</developerConnection>
    <url>https://svn.jenkins-ci.org/trunk/hudson/plugins/MYPLUGINNAME</url>
  </scm>

Wiki ページの追加 (Adding a Wiki page)

pluginはこのウィキの上にそれ自身のウィキ・ページを持っているとよいです。また、ウィキ・ページがある場合URLをこのようなあなたのPOMに記述しておいてください:

<project>
  ...
  <url>http://wiki.jenkins-ci.org/display/JENKINS/My+Plugin</url>
</project>

これは、アップデートセンターがあなたのpluginを正確にリストするだろうということを保証します。
あなたのウィキに「plugin-scm」あるいは「plugin-misc」のような"plugin-" がprefixとして付与されたラベルを(ウィキの底のラベルをクリックする、ページを編集できます)にページをつけます。こうすることで、ページがPluginsの中でリンクとして現われることを保証するでしょう。

必ずさらに{jenkins-plugin-info:pluginId=your-artifact}を含めること、これはあなたのウィキ・エントリーの一番上の標準のplugin infoboxをあなたのウィキ・ページ上で現われさせるためです。
さらに、あなたは、{excerpt}タグでpluginの記述をおこなうとそれがアップデートセンターに現われます。

よく分からなかった

あなたのpluginのJIRAの中のコンポーネントがそのartifact IDと異なる場合は、{jenkins-plugin-info:pluginId=your-artifact|jiraComponent=your-plugin-component}を使用してください。あなたのpluginのSubversionでのGitHubリポジトリあるいはディレクトリがartifact IDと一致しない場合は、同様に{{|sourceDir=your-plugin-dir}} を加えてください。

メンテナー情報の追加 (Adding Maintainer Information)

あなたのPOMでは、以下のように開発者情報を含めることを確実に行ってください:

<project>
  ...
  <developers>
    <developer>
      <id>devguy</id>
      <name>Developer Guy</name>
      <email>devguy@developerguy.blah</email>
    </developer>
  </developers>
</project>

<id>はあなたのjenkins-ci.orgアカウントです。<name>は人間の判読可能なディスプレイ名です。
これは、アップデートセンターおよび関連するツールがあなたのpluginの保持者を適切に表示することができることを保証します。
電子メール・アドレスはオプションです(もしPOMの中で提供されれば、それはウィキ上でplugin infoboxの中で使用されるでしょう)。

BuildHive@CloudBees上での継続的インテグレーション (Continuous integration builds on BuildHive@CloudBees)

BuildHive@CloudBeesであなたのpluginをビルドするためには、devリストに電子メールを送って、あなたのpluginのためにCIビルドをセット・アップさせてくれるように頼んでください。
デフォルト(つまり「クリーン・インストール」)とは異なっているゴールを持ちたい場合は、それに言及してください。
plugin CIビルドはすべて、ビルドが失敗するか、持っているすべての人に行く電子メールと共に不安定な場合にビルド結果の電子メールを送る準備ができるでしょう。

リリースのためのPOMの準備(Prepare POM for release)

すべてのpluginは ”master plugin POM" (org.jenkins-ci.plugins:plugin もしくはレガシーな org.jvnet.hudson.plugins:plugin) を継承します。
古い”master plugin POM"が最近の変化を反映しないので、次の調節を行う必要があります。

maven release plugin の設定のオーバーライド(1.387以前)

これは、それはPOM 1.387以前向けのpluginのみです。
これは、リリース・プロセスがhpi:アップロードおよびhpi:announce goalsを実行するのを防ぎます。

  <build>
    <plugins>
      <plugin>
        <artifactId>maven-release-plugin</artifactId>
        <configuration>
          <goals>deploy</goals>
        </configuration>
      </plugin>
    </plugins>
  </build>

Maven レポジトリーの場所のオーバーライド (1.395以前)

あなたのplugin POMの中に次の宣言を加えることで、私たちの Maven リポジトリにビルド成果物を配置します:

  <distributionManagement>
    <repository>
      <id>maven.jenkins-ci.org</id>
      <url>http://maven.jenkins-ci.org:8081/content/repositories/releases/</url>
    </repository>
  </distributionManagement>

jenkins-ci.orgにリリースする(Releasing to jenkins-ci.org)

1.393から1.398を使用して、どんなpluginsもリリースしないでください。リリース時ににカレントバージョンを記録しないバグが過去のバージョンに存在しました。したがって、jenkinsは、それが古いコア・バージョンを使用する場合にそのようなpluginを利用する人々を警告することができません。

pluginを公開する最も簡単な方法は jenkins-ci.orgアカウント をつかって Maven release pluginを実行することです。

$ mvn release:prepare release:perform -Dusername=... -Dpassword=...

GitHubを使用している場合、あなたの実際のリモート plugin リポジトリを"origin"に指定されているはずです。

これで通常のリリースのための処理をすべて行ない、さらに、ダウンロード・セクションにpluginを追加するでしょう。
あなたが-Bオプションで走れば、Mavenは自動的に、デフォルト値をすべて使用するでしょう。
Subversion と同様にGithub.comにホスティングされたpluginsのリリースを行うことができることに注意してください。(詳細)
しかしながら、この場合、あなたのpluginはGitHubでホストされています。そのため、異なるユーザー名および(または)ユーザー名/パスワードのためのコマンドライン引数のGitHubおよびjenkins-ci.org使用のためのパスワードを持っているとエラーになるでしょう。

しーっ代理人を始めて、リリースpluginがGitHubリポジトリにアクセスすることができ、下記に述べられるようなあなたの~/.m2 /settings.xmlの中のjenkins-ci.orgのためのパスワードを形成することができるように、秘密鍵を import しなければならないでしょ う。

However if you plugin is hosted on GitHub and you have different username and/or password for GitHub and jenkins-ci.org use of the command-line arguments for username/password will result in errors.
You will have to start an ssh-agent and import your private key so the release plugin can access the GitHub repository and configure the password for jenkins-ci.org in your ~/.m2/settings.xml as described below.

Instead of listing username/password on the command line, you may also specify these in ~/.m2/settings.xml as follows:

settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">

  <servers>
    <server>
      <id>maven.jenkins-ci.org</id> <!-- For parent 1.397 or newer; before this use id java.net-m2-repository -->
      <username>...</username>
      <password>...</password>
    </server>
  </servers>

</settings>

You may also follow these instructions to encrypt the password stored in settings.xml. Once you are done with this run mvn deploy to verify that your credential is correctly recognized by Maven.

Also consider these tips before making a plugin release.

The released plugin will show up in the update center in half a day or so.

Working around common issues

If a release fails with the following error, that means the version number for your plugin in pom.xml does not end with -SNAPSHOT. Add this suffix and commit the change, then try again.

    [INFO] ------------------------------------------------------------------------
    [ERROR] BUILD FAILURE
    [INFO] ------------------------------------------------------------------------
    [INFO] You don't have a SNAPSHOT project in the reactor projects list.

If a release:prepare fails with an error like the following, then it's probably because you are hitting a bug between Maven and Subversion 1.5 (see more details.) In such a case, run "svn up" on your workspace then retry:

[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '/svn/hudson/tags/foo/bar/zot/...' already exists

If changes to your pom.xml seem to be having no effect, try one of these to clear out any intermediate files and start over:

mvn -Dresume=false release:prepare release:perform
mvn release:rollback
mvn release:clean

My release failed and I want to redo it from scratch

When a release fails in the middle, you unfortunately have to manually cancel out some of the side-effects Maven has caused. See this e-mail for details. The easiest way out is to forget about the botched release and simply move on to the next release number.

Subversion 1.6 authentication problem

Subversion 1.6 has a known problem with the --non-interactive switch that Maven uses, in that the presence of this switch prevents Subversion from accessing your authentication credentials. See this thread for more background discussion.
You can verify whether this is the cause of your problem by comparing the behavior between svn ls --non-interactive https://svn.jenkins-ci.org/ and svn ls https://svn.jenkins-ci.org/. Once verified that this is the root cause, tell Subversion to store the password in plain text

Additionally you need to check that you are not accessing the subversion repository with the "guest" user. So try svn ls --username YOURNAME https://svn.jenkins-ci.org/ . If it asks for your credentials then simply give it and retry.

OutOfMemoryError: Java heap space

If the release fails because Maven runs out of heap space, you may need to increase its limit by defining the MAVEN_OPTS environment variable. For example, in a bash shell, you could add the following to ~/.profile:

~/.profile
export MAVEN_OPTS=-Xmx300m

If you are running Maven inside IntelliJ 9.0.1, its setting for Maven > Runner > VM Parameters applies to only the parent Maven process, but it may be a child Maven process that is running out of memory. Furthermore, if you are running IntelliJ on MacOSX 10.6, normal environment variables, i.e., exported from ~/.profile, are not seen by apps launched from Finder. So, to increase the heap limit of child Maven processes in IntelliJ, you can configure MAVEN_OPTS in /etc/launchd.conf instead. Create or edit the file, e.g. sudo vi /etc/launchd.conf and add:

/etc/launchd.conf on MacOSX
setenv MAVEN_OPTS -Xmx300m

Error deploying artifact: Connection failed: Unable to connect to https://svn.dev.java.net/svn/maven2-repository/trunk/repository/

If the deployment fails it might be trying to write to a legacy repository. The instructions above and in the migration page should help with setting the correct target repository.

HTTP 401 when transferring a file to the Jenkins Maven repository

If, when running mvn release:perform, you get an error message similar to the following one, there are a few possibilities:

  • Your password is incorrect
  • You haven't added your jenkins-ci.org credentials to your ~/.m2/settings.xml file as described above.
  • The ID of the repository as specified in POM (which is normally inherited) doesn't match the ID in ~/.m2/settings.xml. To verify this, run mvn help:effective-pom and look for the <distributionManagement> element. For example, see this. This is because earlier versions of the plugin parent POM had this kind of problems. The easiest solution is bump up the parent POM to 1.409 or later. If you need to keep the parent version as is, then add additional <server> entry in your settings.xml with all the variations of the IDs.
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project sbt:
Failed to deploy artifacts: Could not transfer artifact org.jvnet.hudson.plugins:sbt:hpi:1.0 from/to
maven.jenkins-ci.org (http://maven.jenkins-ci.org:8081/content/repositories/releases/):
Failed to transfer file:
http://maven.jenkins-ci.org:8081/content/repositories/releases/org/jvnet/hudson/plugins/sbt/1.0/sbt-1.0.hpi.
Return code is: 401 -> [Help 1]

If release:prepare fails with the following error, you are most likely using "Cygwin" on Windows. There is a failure of path translation somewhere between Maven and the Cygwin Subversion client. The easiest way around this is to install a native Windows Subversion client (eg. Win32Svn) and re-run from a DOS/CMD window.

[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "svn --non-interactive commit
       --file C:\DOCUME~1\username\LOCALS~1\Temp\maven-scm-1876439793.commit
       --targets C:\DOCUME~1\username\LOCALS~1\Temp\maven-scm-7190199490958000758-targets"
[INFO] Working directory: D:\home\ed\projects\hudson\plugins\lavalamp
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to commit files
Provider message:
The svn command failed.
svn: '/cygdrive/d/home/username/projects/hudson/plugins/lavalamp/D:/home/username' does not exist

If a release fails with either of the following errors, that means you don't have hudson/plugins/pom.xml installed in your local repository. Run mvn -N install in the plugins directory and retry a release.

[INFO] Executing: mvn deploy
--no-plugin-updates -DperformRelease=true
    [INFO] Scanning for projects...
    Downloading:
http://repo1.maven.org/maven2/org/jvnet/hudson/plugins/plugin/1.NNN/plugin-1.NNN.pom
    [INFO] ------------------------------------------------------------------------
    [ERROR] FATAL ERROR
    [INFO] ------------------------------------------------------------------------
    [INFO] Error building POM (may not be this project's POM).


    Project ID: null:xxxxxx:hpi:N.N

[INFO] Scanning for projects...
       Downloading: http://repo1.maven.org/maven2/org/jvnet/hudson/plugins/plugin/1.212/plugin-1.212.pom
       [INFO] ------------------------------------------------------------------------
       [ERROR] FATAL ERROR
       [INFO] ------------------------------------------------------------------------
       [INFO] Failed to resolve artifact.

    GroupId: org.jvnet.hudson.plugins
       ArtifactId: plugin
       Version: 1.212

    Reason: Unable to download the artifact from any repository

      org.jvnet.hudson.plugins:plugin:pom:1.212

    from the specified remote repositories:
          central (http://repo1.maven.org/maven2)

Subversion 409 Conflict

If a release:perform fails with an error like the following, retry mvn release:perform later. We don't know the root cause of this problem, but the problem does seem to disappear after a while.

[INFO] [INFO] Error deploying artifact: Connection failed: Unable to connect to
  https://svn.dev.java.net/svn/maven2-repository/trunk/repository/
[INFO]
[INFO] svn: The specified baseline is not the latest baseline, so it may not be checked out.
[INFO] svn: CHECKOUT of '/svn/maven2-repository/!svn/bln/1348162': 409 Conflict (https://svn.dev.java.net)
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] For more information, run Maven with the -e switch
[INFO] [INFO] ------------------------------------------------------------------------

git push hangs

Stackoverflow offers suggestions on how to correct this at http://stackoverflow.com/questions/3243755/maven-error-releasing-code-to-github-hangs-after-push.

Frequently asked questions

What should be the Java package name?

If you'd like to use your own package name, feel free to do so. If you don't want to do so, or prefer to use the Jenkins name in the package name, we recommend jenkins.plugins.XYZ.

Help! My plugin is not showing up in the update center.

  1. First, check http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/ or http://repo.jenkins-ci.org/releases/org/jvnet/hudson/plugins/ and see if your plugin is listed there. If not, your release process failed, and it never left your PC. If you can't resolve this issue, capture the output from mvn release:prepare release:perform and send it to the dev list.
  2. Check if your new version is in http://updates.jenkins-ci.org/update-center.json. This file is updated every 6 hours, so there's some delay before your new version appears here.
  3. If your plugin appears there but not in your Jenkins update center, visit Manage Plugins / Advanced and click the button to make Jenkins retrieve the latest update-center.json data.
  4. If none above applies, it's time for Kohsuke to start investigating.