С выходом JBoss Tools 3.2 и JBoss Developer Studio 4.0 вы можете подумать: «Себя, сколько сайтов обновлений, ZIP-архивов и исполняемых файлов мне понадобится для загрузки ЭТОГО времени?»
Или, может быть, вы думаете: «Сам, почему это так сложно?»
Ну, ребята, мы слышали ваш квитч и что-то с этим сделали.
Композитный репо
Хотя для многих это не новая концепция, в прошлом году мы приняли комплексный сайт обновлений, и он значительно упростил жизнь для повторяющихся и гибких циклов разработки. В прошлом году JBoss Tools 3.1 был создан как одно задание Hudson, а второе — для JBoss Developer Studio. Это означало, что любое изменение в любом из компонентов приведет к запуску сборки, и через 4-6 часов у нас будут свежие биты. Да, далеко от идеала.
В этом году мы разделили монолит (и добавили несколько новых компонентов!), Так что теперь у нас есть 34 сайта обновлений, которые можно объединить в один, на котором затем могут быть собраны сборки. Этот составной сайт обновлений выглядит следующим образом:
compositeArtifacts.xml
<?xml version='1.0' encoding='UTF-8'?>
<?compositeArtifactRepository version='1.0.0'?>
<repository name='JBoss Tools Staging Repository'
type='org.eclipse.equinox.internal.p2.artifact.repository.CompositeArtifactRepository'
version='1.0.0'>
<properties size='2'>
<property name='p2.compressed' value='true'/>
<!-- get new time w/ `date +%s000` -->
<property name='p2.timestamp' value='1294205433000'/>
</properties>
<children size='34'>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.2_trunk.component--archives/all/repo/'/>
...
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.2_trunk.component--ws/all/repo/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-pi4soa-3.1_trunk/all/repo/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-teiid-designer-7.1_trunk/all/repo/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-drools-5.2_trunk/all/repo/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-savara-1.1_trunk/tools/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/xulrunner-1.9.1.2/all/repo/'/>
</children>
</repository>
compositeContent.xml
<?xml version='1.0' encoding='UTF-8'?>
<?compositeMetadataRepository version='1.0.0'?>
<repository name='JBoss Tools Staging Repository'
type='org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository'
version='1.0.0'>
<properties size='2'>
<property name='p2.compressed' value='true'/>
<!-- get new time w/ `date +%s000` -->
<property name='p2.timestamp' value='1294205433000'/>
</properties>
<children size='34'>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.2_trunk.component--archives/all/repo/'/>
...
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-3.2_trunk.component--ws/all/repo/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-pi4soa-3.1_trunk/all/repo/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-teiid-designer-7.1_trunk/all/repo/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-drools-5.2_trunk/all/repo/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/jbosstools-savara-1.1_trunk/tools/'/>
<child location='http://download.jboss.org/jbosstools/builds/staging/xulrunner-1.9.1.2/all/repo/'/>
</children>
</repository>
Итак, теперь, когда JBoss Tools состоит из 34 частей, биты, которые не изменились, не перестраиваются снова и снова, а сборка происходит быстрее. Если вам это кажется безумно очевидным, у нас было много внутрикомпонентных циклических зависимостей. Мы устранили их в начале цикла разработки для JBoss Tools 3.2, и с тех пор мы можем строить умнее и быстрее.
Дополнительные преимущества этого композитного сайта:
- Вновь созданные и опубликованные фрагменты сразу же доступны на комбинированном сайте — конечно, то же самое было верно в прошлогоднем режиме PDE «uberbuild», но это потому, что все создавалось заново каждый раз, что было медленным и почти невозможно заставить людей работать дома.
- Разработчики могут использовать этот сайт для установки последних обновлений компонентов, которые они заинтересованы в тестировании — опять же, это было верно раньше; но теперь, используя тот же сайт и ища обновления, разработчики и бета-тестеры могут получать инкрементные обновления фактически изменившихся компонентов, вместо того, чтобы ежедневно тратить по 160 МБ, чтобы получить несколько К изменений.
- Tycho может быть направлен на этот сайт (см. Ниже) для разрешения бинарных зависимостей p2, поэтому создание компонента глубоко в цепочке зависимостей может быть выполнено без необходимости сначала создавать его восходящие зависимости — это раньше не было проблемой, потому что все было построено из исходного кода каждый раз, так что по определению все было уже на диске. Но теперь, если разработчик заботится только об одном компоненте, таком как ModeShape или GWT, ему нужен только этот исходный код (и некоторый загрузочный код) на диске. Меньше, быстрее, проворнее. И гораздо более вероятно, что он будет создан локально перед проверкой кода, чем раньше, что делает мучительным «кто сломал что и когда?» процесс гораздо менее болезненный. Меньше движущихся частей и локальных сборок разработчиков дома означают — в теории — меньше неполных или разрушающих коммитов.
Когда мы впервые переехали в Tycho, нам нужно было создать ряд компонентов локально, чтобы просто перейти к глубокому компоненту. Например, компоненту Struts требуется VPE, для которого нужны JST и XulRunner . JST также нужен компонент Common, который, в свою очередь, нуждается в компоненте Tests.
Таким образом, чтобы построить Struts локально, сначала нужно будет создать 5 других компонентов локально. Это сработало, но было все еще довольно большим барьером для входа для большинства разработчиков (намного меньше участников!)
Но с этим новым составным сайтом, создание Struts может быть сделано без этой долгой начальной загрузки; вместо этого мы просто указываем Tycho на этот составной сайт, и он вытаскивает 5 jar компонентов выше по потоку из этого репозитория p2 — потому что вышестоящие deps уже встроены в Hudson.
Вот что мы добавили в наш родительский pom.xml, чтобы сборки находили двоичные файлы:
<repository>
<id>jbosstools-nightly-staging-composite-trunk</id>
<url>http://path.to.the.site/staging/_composite_/trunk/ </url>
<layout>p2</layout>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>
Во второй части я расскажу, почему мы перешли от использования набора SDK (Eclipse, EMF, DTP, GEF, M2E, RSE, TPTP, UMl2, WTP, XSD и т. Д.), На который можно строить — используя теперь- устаревший подход «просто распаковать в корневую папку затмений» или «dropins» — к использованию одного сайта обновления целевой платформы. Предупреждение о спойлере : проще в обновлении и обслуживании.
В третьей части я вернусь к тому успеху, который у нас был при использовании ассоциированных сайтов вместо того, чтобы просить людей вручную добавлять сторонние URL при установке JBoss Tools. СПОЙЛЕР ПРЕДУПРЕЖДЕНИЕ : один URL проще для людей, чем 6.
В четвертой части я немного расскажу о том, как предотвратить сборку вашего продукта из неофициальных источников, и предварительно загрузлю ваш продукт официальными сайтами, с которых можно получать обновления. Потому что важно сбалансировать простоту использования с предотвращением неподдерживаемых функций. SPOILER ALERT : может содержать p2.inf инструкции.
Кстати, доступны JBoss Tools 3.2.0.CR1 и JBoss Developer Studio 4.0.0.CR1 . Получить их, пока они горячие (а Sourceforge нет ).