Статьи

Упрощение процесса p2, часть 2: Репозитории на целевой платформе

Апрель 15, 2019

В первой части этой серии статей я рассмотрел использование составных репозиториев, чтобы обеспечить способ объединения сайтов обновлений в один URL-адрес для простоты использования и единой точки входа, с которой можно выполнять обновления.

Определение цели

Теперь я хотел бы поговорить о том, как избежать распространения молний, ​​необходимых для создания целевой платформы. Для тех, кто не знаком с термином «целевая платформа», это либо установленная база, для которой вы компилируете свой код, либо набор вещей, которые вы должны установить в первую очередь, прежде чем устанавливать что-либо поверх этого.

Для случая JBoss Tools у нас есть как минимум 8 предварительных требований для установки. Вот что вы должны были установить до JBoss Tools 3.1.1:

Разумеется, поскольку существует также сайт обновлений Ganymede , вам не обязательно загружать и распаковывать все эти zip-архивы для установки JBoss Tools — вместо этого вам нужно только включить сайт Ganymede . (Та же история для Helios и JBoss Tools 3.2 .)

Однако, чтобы сделать воспроизводимую сборку на основе PDE, вам все равно нужно создать эту базовую установку. Традиционно подход PDE состоял в том, чтобы загрузить и распаковать эти zip-файлы в корень установки Eclipse, на которой выполняется сборка. Athena попыталась улучшить эту ситуацию, позволив вам определить список сайтов обновлений и IU (функций и / или плагинов), которые были необходимы для определения платформы. Но это было далеко от портативного и вряд ли многоразового использования.

Бакминстер (позже b3) также подошел к этой проблеме, создав собственную разметку для определения того, какие сайты и какие IU следует устанавливать, опираясь на модель EMF. Но вместо того, чтобы иметь дело с пользовательским интерфейсом для создания модели и ее заполнения, я обнаружил, что более полезно просто сгенерировать экземпляр модели агрегатора, а затем использовать агрегатор для извлечения и установки IU. Но поскольку агрегатор является просто оболочкой для базовых задач p2.mirror и p2.director, вы можете использовать их также напрямую.

Но, как говорится … « Не надоедай, иди в хор! » Итак, вот пример кода для различных решений для обеспечения во время сборки.

  1. Использование агрегатора Бакминстера ( файл свойств ) — у нас перестали работать с Eclipse 3.6, поэтому мы перешли на b3

     

  2. Использование агрегатора b3 ( файл свойств ) — перестал работать последовательно из-за тайм-аутов сети, разрешающих задержки и выборку IU.

     

  3. Использование p2.mirror — основной задачи p2 ant для зеркалирования одного или нескольких репозиториев на локальный диск

     

  4. Использование p2.director — основной задачи p2 ant для установки IU (из локального или удаленного репо) в некоторый целевой Eclipse

Таким образом, с помощью этих инструментов вы можете создать репозиторий p2 из других репозиториев — зеркалировать и устанавливать IU по мере необходимости — и даже создавать сценарии установки. Но был ли лучший способ?

Файл определения целевой платформы

Введите файл определения целевой платформы (.target). Этот файл содержит список IU и репозитории p2, из которых они предоставляются. Таким образом, это похоже на агрегаторную модель b3 или файл build.properties Athena , но абстрагированный от концепции сборки, поскольку его можно использовать для сборки, но ТАКЖЕ для обеспечения установленной пользователем базы Eclipse.

К сожалению, редактор файла определения целевой платформы в Eclipse 3.6 менее оптимален для больших целей или когда ваше интернет-соединение неоптимально. Итак, после некоторой борьбы с ним, регистрации ошибок и, в конечном итоге, сдачи, я вернулся к своему удобному редактору XML (часто просто vim), чтобы поддерживать его проще. Поэтому вместо того, чтобы Eclipse автоматически устанавливал вещи на основе файла .target, я возвращаюсь к рабочему процессу, который действительно работает: установка вручную с сайта обновлений.

В то время как Buckminster поддерживает файлы .target (или я так прочитал ), я не хотел больше зависеть от этого, предпочитая более «чистое» решение.

Итак, основываясь на коде Питера Нехрера ( @pnehrer ), я затем написал XSL-преобразование для создания сценария p2.mirror из файла .target, обернутого другим сценарием Ant (и, необязательно, сценарием Maven pom.xml ).

И почему тебя это может волновать? Ну, этот файл .target может быть использован для:

  • Подготовьте Eclipse для разработчика, используя редактор определений целевой платформы и несколько щелчков мышью (когда время не истекает )
  • Предоставление Eclipse для разработчика с помощью сценария для автономного или нескольких пользователей (для ускорения работы команды)

И да, многое (или все) из вышеперечисленного может быть сделано с Бакминстером и / или b3, если вам нравится такой подход.

Но я предпочитаю создавать .target в качестве входных данных для процесса сборки, а не связывать его с ним явно. Итак, как я уже отмечал выше, если у вас есть файл .target, вы можете легко сгенерировать репозиторий p2 и использовать его для запуска последующих сборок. Теперь вместо полудюжины почтовых индексов для загрузки и распаковки при каждой сборке (с использованием устаревшего и неподдерживаемого метода « dropins ») вы можете использовать полностью подходящий для p2 сайт репо, который содержит все, что вам нужно для сборки — будь то Вы сервер Hudson или разработчик, работающий дома или в автономном режиме.

Выгоды

  • В отличие от «коллекции zips», этот сайт с одним источником может быть версионирован с каждым выпуском.
  • Он содержит только то, что вам действительно нужно, а не посторонние источники и документы и тангенциальные плагины / функции, которые вы не делаете. Это немного похоже на приготовление кексов, сначала размалывая собственную муку, но, по крайней мере, вы знаете, что в этой смеси нет ничего злого, и вы сможете последовательно воспроизводить рецепт каждый раз, независимо от того, где вы находитесь на интервеже.
  • Если вы увлеченный / бета-тестер, которому нравится собираться в соответствии с последним этапом (или даже еженедельной интеграционной сборкой) Eclipse 3.next или 4.future, вы можете использовать приведенный выше скрипт для самообновления. Таким образом, хотя сам TP представляет собой автономный снимок, в котором перечислены явные версии необходимых групп объектов, его также можно запускать в режиме « получения последней доступной версии », чтобы сохранить актуальность TP в некоторых разработках / выпусках HEAD или магистрали.
  • Разделив TP из сборки, вы можете построить ее вверх по течению . Итак, если раньше у нас был один «uberbuild» и подразумеваемый TP, то теперь у нас есть задание по сборке TP, которое затем разделяется 34 последующими заданиями, которые зависят от него в зависимости от их зависимостей.

Заткнись и покажи мне код!

# for the "foo.target" file, build a local target platform repo, fetching the latest versions and updating the .target file
$ ant -f build.xml -DtargetFile=foo.target -DuseLatest=true
 
# for the "bar.target" file, build a local target platform repo, but fetch only the stated versions of IUs
$ ant -f build.xml -DtargetFile=bar.target -DuseLatest=false

Вот и все. Я также обернуть сценарий build.xml муравья ж / с П , который позволяет ему быть вызван из предшествующего процесса Maven / Tycho, но в этом нет ничего больше , чем просто вызов сценария с использованием antrun плагина (и несколько муравьиных зависимостей), как это :

 

<build>
        <plugins>
                <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-antrun-plugin</artifactId>
                        <version>1.6</version>
                        <executions>
                                <execution>
                                        <phase>validate</phase>
                                        <configuration>
                                                <tasks>
                                                        <ant antfile="build.xml">
                                                                <property name="targetFile" value="multiple.target" />
                                                                <!-- <property name="repoDir" value="/path/to/where/to/provision/repo"/> -->
                                                        </ant>
                                                </tasks>
                                        </configuration>
                                        <goals>
                                                <goal>run</goal>
                                        </goals>
                                </execution>
                     </executions>
                        <dependencies>
                                <dependency>
                                        <groupId>commons-net</groupId>
                                        <artifactId>commons-net</artifactId>
                                        <version>1.4.1</version>
                                </dependency>
                                <dependency>
                                        <groupId>org.apache.ant</groupId>
                                        <artifactId>ant-commons-net</artifactId>
                                        <version>1.7.1</version>
                                </dependency>
                                <dependency>
                                        <groupId>org.apache.ant</groupId>
                                        <artifactId>ant-trax</artifactId>
                                        <version>1.7.1</version>
                                </dependency>
                        </dependencies>
                </plugin>
 </plugins>
</build>

Остальная часть кода здесь .

В третьей части я вернусь к тому успеху, который у нас был при использовании ассоциированных сайтов вместо того, чтобы просить людей вручную добавлять сторонние URL при установке JBoss Tools. СПОЙЛЕР ПРЕДУПРЕЖДЕНИЕ : один URL проще для людей, чем 6.

В четвертой части я немного расскажу о том, как предотвратить сборку вашего продукта из неофициальных источников, и предварительно загрузлю ваш продукт официальными сайтами, с которых можно получать обновления. Потому что важно сбалансировать простоту использования с предотвращением неподдерживаемых функций. SPOILER ALERT : может содержать p2.inf инструкции.

 

От http://divby0.blogspot.com/2011/01/simplifying-p2-process-part-2-target.html

43
Share: