Решение для создания автономного составного сайта обновлений Eclipse с категориями

Это будет довольно длинный вопрос, так что потерпите меня. Я ищу решение для создания настраиваемых сайтов обновлений (или репозиториев p2) для использования в автономной среде разработки, имея в виду следующее:

  • Каждый сайт будет содержать как сторонние, так и пользовательские плагины Eclipse.

  • Я хотел бы создать один сайт для каждой конфигурации IDE. например Разработчикам, использующим Helios, достаточно добавить 1 сайт обновлений, содержащий m2e, Subversive и CustomPluginA. Разработчики, использующие Flash Builder, могут добавить другой сайт, содержащий m2e и CustomPluginB.

  • Поскольку разработка находится в автономном режиме, в настоящее время мы зеркалируем сторонние сайты обновлений с помощью скрипт. Пользовательским сайтам необходимо извлечь плагины из этих копий.

  • Наши настраиваемые плагины Eclipse в настоящее время создаются с помощью Maven + Tycho на Jenkins. Если возможно, я бы хотел настроить сайты обновлений для автоматической сборки с Jenkins. Затем, если настраиваемый плагин обновлен, он может запускать необходимые сборки сайта обновления.

  • Было бы неплохо использовать настраиваемые категории на сайтах обновлений.

Я пытаюсь найти лучший и самый чистый способ подойти к этому. Как я могу настроить что-то подобное с помощью Tycho для создания сайтов? Tycho - это даже лучший вариант? Я хочу, чтобы сторонние плагины копировались на каждый сайт, или я хочу создать составные репозитории p2, которые указывают на каждый из зеркальных сторонних сайтов. Можно ли создавать собственные категории с помощью составного репозитория p2?

И, наконец, каков самый простой способ определить, какие плагины и функции включены в сайт? В Eclipse я могу создать проект обновления сайта, который упрощает редактирование, но я могу включать только плагины, которые существуют в этой установке Eclipse. Создание вручную сценария site.xml или p2 ant решает эту проблему, но определение идентификаторов и версий устанавливаемых модулей вручную затруднительно и чревато ошибками.

Спасибо, что нашли время прочитать все это. Если бы кто-нибудь действительно мог решить все мои проблемы, это было бы замечательно, и мне, вероятно, пришлось бы добавить награду за этот вопрос.


eclipse tycho p2 update-site
person takteek    schedule 20.01.2012    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Я предложу два способа: один с Tycho и один с агрегатором B3.

1) Тихо:

Шаг 1.. Определите целевую платформу с помощью встроенных средств PDE, которые используют ваши существующие локальные сайты обновлений, и сохраните ее как файл .target. Затем вы можете ссылаться на этот файл в своей сборке следующим образом:

<plugin>
  <groupId>org.eclipse.tycho</groupId>
  <artifactId>target-platform-configuration</artifactId>
  <version>${tycho.version}</version> <configuration>
  <resolver>p2</resolver>
   <target>
     <artifact>
      <groupId>org.eclipse.viatra2</groupId>
      <artifactId>«project name where the target file resides»</artifactId>
      <version>«artifact version»</version>
      <classifier>«target filename without extension»</classifier>
     </artifact>
   </target>
   <ignoreTychoRepositories>true</ignoreTychoRepositories>
  </configuration>
 </plugin>

Шаг 2.. Определите новый проект как сайт обновлений. Проект должен содержать файл category.xml со ссылкой на использованные версии используемых функций целевой платформы из предыдущего шага. Вы можете создать этот файл category.xml с помощью мастера / редактора определения категории PDE.

Шаг 3.: просто опубликуйте свою сборку, используя архетип сайта обновления:

<packaging>eclipse-repository</packaging>
<build>
  <plugins>
    <plugin>
      <groupId>org.eclipse.tycho</groupId>
      <artifactId>tycho-p2-publisher-plugin</artifactId>
      <version>${tycho.version}</version>
      <configuration>
        <publishArtifacts>true</publishArtifacts>
      </configuration>
    </plugin>
  </plugins>
</build>

2) Агрегатор B3:

Проект Eclipse B3 содержит функцию агрегатора. Используя агрегатор, вы определяете модель, которая использует существующие сайты обновлений, затем просто выполняете эту модель с помощью агрегатора, и в результате вы получаете сайт обновлений. В последнем случае вы можете создать составной сайт обновлений, который ссылается на другие сайты обновлений, или вы можете создать автономную копию из исходных данных. В руководстве есть простой пример, им легко пользоваться.

3) Сравнение

В B3 определение логики зеркального отображения более простое, поскольку модель содержит только описание зеркального отображения, а также позволяет создавать составные сайты обновлений, которые ссылаются только на существующие сайты. Однако, если вы хотите заниматься чем-то еще, кроме создания сайта обновлений, это сделать труднее. Кроме того, его можно запускать в безголовых сборках (например, из Jenkins), но для этого требуется установка безголового экземпляра Eclipse. Документация содержит подробности, но инструмент не является автономным, как в случае Maven / Tycho.

В случае Tycho сложнее увидеть структуру результирующего сайта обновления, однако получившаяся сборка более расширяема (например, вы можете просто добавить свои собственные функции, используя тот же тип сборки), а для создания сборки вам нужно только Установлен Maven.

Итак, в целом оба инструмента могут соответствовать вашим потребностям - вам нужно оценить их сильные и слабые стороны в вашем случае.

person Zoltán Ujhelyi    schedule 20.01.2012