Ticket #36989

カスタムプラグインのアップデートサイト構築

Open Date: 2017-02-12 13:00 Last Update: 2017-02-14 23:03

Reporter: nakag Owner: (None)
Type: Feature Requests Status: Open
Component: (None) MileStone: (None)
Priority: 5 - Medium Severity: 5 - Medium
Resolution: None

Details

HandlerやGeneratorを使ったTMD-Makerのカスタムプラグインを取得するアップデートサイトを構築する。 TMD-Makerのリポジトリには含めないが、カステムでプラグインを作る場合のエコシステムを作りたい。 バージョンアップ時のパッチプラグイン等は、必要な人がこのアップデートサイトから取得できるようにしたい。

Attachment File List

No attachments

Ticket History (3/4 Histories)

2017-02-12 13:00 Updated by: nakag
  • New Ticket "カスタムプラグインのアップデートサイト構築" created
2017-02-13 21:44 Updated by: nakag
  • Details Updated
2017-02-14 20:42 Updated by: None
Comment

例の sphinx プラグインとかは、こういうところに入れると良さそうですね。

トピックブランチとしてpushしてみたは良いけれど、コンテキストメニューに常に表示されるほど使われるかというと疑問が残るので。

一方で、バージョンアップ時のパッチプラグインは、初めて使う人でも過去に作成されたtmdファイルを開く可能性は無いではないので本家のfeatureに入れといた方が良いような気がします。

2017-02-14 23:03 Updated by: nakag
Comment

確かにコンテキストメニューがどんどん多くなっていくのは分かりにくくなると思いますが、 まだ具体的な実現方法がイメージできていないので、当面sphinxプラグインやその他Generatorプラグインは本体に組み込む方向で良いと思います。 先々良い方法が実現できたら、その方法に最適なプラグインの置き場に再配置したいです。

今のふわっとした考えだと以下のような方法があるのかなと思ってます(下に行くほど簡単かも)。

  1. 最近流行りの〜Hub的なWebサイトを作る
  2. marketplaceに登録
  3. m2e connectorsのような独自のインストールの仕組みを作る
  4. RCPにupdate siteのダイアログを組み込む。更新サイト自体は公式でも野良でも良いかな

パッチプラグンは、本当はバージョン毎にプラグインを分ける想定だったのですが面倒なので一本化しちゃいましたが、 相当古いバージョンになったものは先々本体から外せたら良いなと考えています。

ちなみに私が登録したチケットで担当者が空欄のものは、具合案がないものがほとんどで、 気が向いたり良い案が浮かんだ時に自分をアサインしているだけなので、興味を持った人が先に取り組んでくれたら良いなとの思いもあったりします。

Edit

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Login