В контексте создания пользовательского дистрибутива Eclipse для команды разработчиков.
Как мне приступить к созданию пользовательского дистрибутива Eclipse, содержащего определенный набор плагинов? Было бы также трудно добавить какой-то сайт обновлений для размещения определенных версий плагинов, из которых будет изменено настроенное затмение?
Eclipse не является одним из тех приложений, которые должны быть "установлены", поскольку его можно просто скопировать в структуру каталогов и установить ярлыки для его запуска (a la the BIRT all-in-one distribution).
Я бы предложил установить его на одной машине, установить все подключаемые модули, а затем просто закрепить каталог и использовать его для распространения на другие компьютеры.
И запустить собственный сайт обновлений не так уж сложно, вам просто нужен сервер, на котором вы устанавливаете только версии подключаемых модулей, которые вам нужны, и убедитесь, что ваши точки распространения на этом сервере перед созданием zip файла. Там ничто не мешает вашим разработчикам подключаться к другому сайту.
Я понимаю, что это старый пост, но он продолжает подходить к поисковым запросам, которые я делаю, и я хотел бы добавить некоторые подробности, учитывая все изменения и зрелость, которые произошли, когда дело доходит до доставки плагинов Eclipse... Итак, для тех, кто попадает на эту страницу, надеюсь, следующее поможет вам!
Подводя итог моим личным выводам:
И пока я работаю в компании, предлагающей коммерческое решение (http://genuitec.com/sdc), Ive попытался ответить ниже с практикой Eclipse с помощью бесплатных решений.
Итак, без дальнейших аде...
Абсолютно минимальное решение - загрузить пакет Eclipse с Eclipse.org, добавить нужные вам плагины, установить параметр -clean в eclipse.ini, закрепить каталог и передать его вокруг вашей команды. Пока вы добавили функции со своего внутреннего сайта обновления (и URL-адрес остается постоянным), Eclipse сможет обновить его.
Это будет работать в первый раз, и, поскольку это легко, это то, что большинство людей начинают делать. Но он игнорирует жизненный цикл стека инструментов. Вот некоторые моменты боли, с которыми я столкнулся, помогая клиентам с помощью инструмента Eclipse:
Eclipse Packages: вы должны быть гуру Eclipse/p2 для настройки и поддержки пакетов Eclipse. Инструменты EPP позволяют создавать собственные пакеты, но вам нужно много знаний о доменах вокруг пакетов Eclipse, p2 и инструментария EPP. Место для начала - http://wiki.eclipse.org/EPP/How_to_build_a_package_locally
Плагины: поиск плагинов включает в себя много охоты на сайты обновлений, и вы никогда не можете быть уверены, что получили точные правильные двоичные файлы. Иногда сайты обновления снижаются или вы теряете поддержку своей версии Eclipse, когда разработчики плагинов выпускают новый сайт обновлений. Одно из предложений заключается в том, чтобы локальные копии сайтов обновлений уменьшали воздействие таких проблем.
Обновления Eclipse: если вы хотите, чтобы ваша команда переключала версии Eclipse, вы в итоге просто переделаете свой стек инструментов в следующей версии и переустановите всех. Там нет способа обойти это, когда просто отправляете почтовый индекс.
Обновления плагинов: Eclipse предназначен для установки новой версии плагинов, но в крупных производственных группах, которые могут быть контрпродуктивными. Локальные зеркала сайтов обновлений могут помочь в этом, пока ваша команда не выйдет и не добавит свои собственные сайты обновлений.
Безопасность: вам нужно запретить вашей команде устанавливать какое-либо программное обеспечение? Как насчет требуемых инструментов? Вам нужно будет написать плагины, чтобы ограничить возможности вашего пакета, и вам, возможно, придется подписать плагины самостоятельно. У сборки PDE есть некоторая поддержка для подписания.
Долгосрочное обслуживание: восстановление набора инструментов за несколько лет (или иногда несколько месяцев) может быть практически невозможным, так как поддержка различных версий Eclipse и разных версий плагинов приходит и динамически развивается в экосистеме Eclipse. Сохраните копии ваших пакетов Eclipse. Покупайте большие жесткие диски. Зеркалируйте сайты обновлений, которые вы используете.
Настройка рабочей области: вы можете развернуть Eclipse для своей команды, но это только первый шаг в этом процессе. Автоматизация для настройки рабочего пространства, например. предпочтениями, проектами, конфигурацией Checkstyle или PMD, позволяет значительно сократить время, затрачиваемое вашей командой на подготовку к работе. Кроме того, эти настройки часто меняются при добавлении проектов, создающих непрерывные проблемы с управлением. Когда вы проходите вокруг zip, я видел, что команды также проходят вокруг соответствующей страницы WIKI или чего-то подобного. Обычно каждый разработчик должен следить за тем, чтобы они выполняли следующие шаги.
Управление несколькими пакетами. Возможно, у вас есть один пакет для вашей команды разработчиков и еще один для вашей команды QA. И тогда ваша команда разработчиков растет и делится на две группы с немного разными потребностями в инструментах, и теперь ваша команда QA нуждается в нескольких пакетах. И затем вы начнете отправлять свой собственный плагин поверх Eclipse, чтобы другой пакет, которым вы управляете. Через несколько лет вы потратите все время на создание пакетов Eclipse, и вы стали гуру Eclipse/P2/Update Site, даже не пытаясь. Ясно, что решение здесь - нанять кого-то, кто сделает это за вас.:)
Распространение SMS: это хорошо работает с zip файлом, но отключение обновлений становится беспорядочным. Обычно люди используют SMS для выпадания первой установки, а затем задание разработчика, чтобы поддерживать ее в актуальном состоянии.
Отвечая на исходный вопрос Lokki, руководитель группы может создать собственный "дистрибутив" команды, как .p2f файл, который содержит идентификаторы плагинов, сайт обновления и точную версию для использования.
Используйте (File → Export → Install → Software Items to file), чтобы подготовить файл списка плагинов (*.p2f),
Пример файла
<?xml version='1.0' encoding='UTF-8'?>
<?p2f version='1.0.0'?>
<p2f version='1.0.0'>
<ius size='5'>
<iu id='org.chromium.sdk.feature.group' name='ChromeDevTools SDK' version='0.3.9.201302091448'>
<repositories size='1'>
<repository location='http://www.tomotaro1065.com/nodeclipse/updates/'/>
</repositories>
</iu>
<iu id='org.chromium.debug.feature.group' name='Chromium JavaScript Remote Debugger' version='0.3.9.201302091448'>
<repositories size='1'>
<repository location='http://www.tomotaro1065.com/nodeclipse/updates/'/>
</repositories>
</iu>
<iu id='com.eclipsesource.jshint.feature.feature.group' name='JSHint Eclipse Integration' version='0.9.6.20130319-2128'>
<repositories size='1'>
<repository location='http://github.eclipsesource.com/jshint-eclipse/updates/'/>
</repositories>
</iu>
<iu id='markdown.editor.feature.feature.group' name='Markdown Editor' version='0.2.3'>
<repositories size='1'>
<repository location='http://winterwell.com/software/updatesite/'/>
</repositories>
</iu>
<iu id='org.nodeclipse.feature.group' name='Nodeclipse' version='0.2.0.201302091448'>
<repositories size='1'>
<repository location='http://www.tomotaro1065.com/nodeclipse/updates/'/>
</repositories>
</iu>
</ius>
</p2f>
затем (Файл → Импорт → Установить элемент программного обеспечения из файла)
Eclipse Node.js IDE собрана таким образом.
Этот вопрос связан с Eclipse IDE: установить набор плагинов
Мне может быть интересно, если кто-то попытается собрать свой собственный дистрибутив Eclipse, чтобы познакомиться с проектом Eclipse Packaging Project http://www.eclipse.org/epp/. Для настройки частного сайта обновления Sonatype Nexus Professional служит именно для этой цели (коммерческая лицензия).
Просто запустите каталог C:\eclipse\plugins и распространите его.
Просто убедитесь, что разработчики запустили Eclipse с опцией "-clean", чтобы обеспечить включение любых изменений.