Что вы считаете хорошей поддержкой Eclipse?
В рамках моей работы я занимаюсь установкой и поддержкой инструментов разработки для разработчиков в компании.
Eclipse - это IDE, которую используют здесь многие разработчики, но я не поддерживаю ее активно. С огромным набором плагинов и быстрым выпуском новых версий - мне сложно держать в курсе, и я не смогу (очевидно) поддерживать все.
У меня есть некоторый опыт работы с Eclipse, но как разработчик - что вы считаете хорошей поддержкой на рабочем месте с точки зрения Eclipse?
Ответы 7
- Частный, внутренний плагин Central. Вы несете ответственность за обновление этого репозитория и тестирование обновлений плагинов в первую очередь для разрабатываемых в настоящее время проектов, поэтому разработчикам не нужно беспокоиться о совместимости; они просто обновятся из собственного репозитория плагинов.
- Общие настройки, например. определение и поддержание форматирования стиля кодирования.
Может быть, так ... просто внимательно выберите плагины, которые вы нужно будете использовать. Также лучше, чтобы он использовал ваше время, чем разработчика. Также вы можете отложить и запланировать обновления, когда сочтете нужным.
На моем рабочем месте Eclipse был стандартным инструментом разработки с проектами, выпущенными для компиляции с Eclipse (я был там, когда мы обнаружили, что файлы Makefile ничего не делали, если Eclipse еще не выполнил сборку). Простое решение - учесть потребности разработчиков и предоставить им необходимую им базовую среду. Пользовательские плагины могут быть установлены в домашнюю папку самими разработчиками с отказом от ответственности. Просто установите базовую среду, которая нужна большинству людей на вашем рабочем месте, и самые распространенные плагины. Сказать: - Базовая среда JDT - Графическая разработка / разработка сети / плагины для разработки на C++ или все, что вам нужно - Плагин UML, если он явно лучше - Какой-нибудь профилировщик, если вы можете заставить его работать (я выполнял профилирование с помощью Netbeans, gprof, даже Oprofile, но мне так и не удалось заставить его работать с Eclipse - это в любом случае более сложное профилирование, чем в Netbeans). И если люди воспользуются им. Если люди этого не делают, возможно, что-то нужно пересмотреть, если только оптимизация не выполняется вообще, потому что в этом нет необходимости :-). Это единственное, для чего людям нужна поддержка, ИМХО, остальное было прозрачно для меня. - Может быть, в Linux мне нужны RPM для версий Eclipse, скомпилированных с помощью gcj, например, Ubuntu и RedHat. За исключением того, что у меня нет доказательств того, что это быстрее, хотя у меня есть доказательства того, что ecj (автономный компилятор Eclipse Java) сам по себе намного медленнее с GCJ (и есть много причин, почему это нормально)!
Командная установка со стандартным набором плагинов.
Разрешите пользователям устанавливать новые и предлагайте новые для стандартной установки, но им следует знать, что они не поддерживаются.
Ваши ведущие разработчики также будут иметь некоторое представление о том, какая конфигурация этих плагинов будет полезна для работы в команде - например,
- Настройки SVN,
- Mylyn интеграция
- стили кода
- настройки checkstyle
- найти настройки ошибок
Как установка, так и плагины могут быть подготовлены и распространены в виде большого zip-файла, или более гибкий подход заключался бы в запуске собственного сайта обновлений внутри компании.
Что касается различных версий Eclipse, просто выберите стабильную и используйте ее. Примерно через год поддержите более новую версию, следуя совету Марцина.
Я делаю (помимо прочего) именно эту работу.
У меня получился большой zip-архив с:
- стабильная версия eclipse
- несколько плагинов, признанных разработчиками полезными (Subclipse, QuickRex, Findbugs, Checkstyle с общими настройками, ...)
- три JDK (!): 1.4, latest1.5, latest 6.0 (используется для запуска eclipse)
- оболочка с псевдонимами (включает "e" для запуска eclipse)
Скрипт, используемый для запуска eclipse:
- тщательно настроил настройки eclipse.ini
- проверьте, публикуются ли новые версии моих инструментов / скриптов / файлов / плагинов (в общем общем каталоге), и, если они это сделают, скопируйте их на рабочий стол пользователя.
Таким образом, вся моя «конфигурация разработки» развивается всякий раз, когда я проверяю новый стабильный набор инструментов.
По сути, нет необходимости устанавливать / обновлять все плагины: просто определите общий базовый набор инструментов, которые вы и ваши коллеги фактически используете ежедневно.
Это может сработать - за исключением того, что у меня много разных проектов на разных платформах и на разных языках, - но это не значит, что я не мог начать их с чего-то вроде этого.
Лично я хотел бы иметь внутренний сайт обновлений со «стандартными» плагинами в одной записи. Это связано с широким спектром возможных доступных версий Eclipse, в которых никто не может заранее удовлетворить потребности опытных разработчиков.
Обычный дистрибутив в виде zip-файла с внутренним сайтом обновлений и установленными "стандартными" плагинами плюс все определенные репозитории исходных текстов (и тщательно определенные шаги) подойдет для большинства разработчиков, не обременяя вас слишком сильно.
Для стандартного набора плагинов и для того, чтобы быть в курсе, я настроил профиль с Йоксос.
Спасибо, Питер, отличная ссылка.
Мне нравится идея плагинов, но я бы испугался, что это будет экспоненциально увеличиваться - необходимость тестировать каждый плагин с каждым другим плагином быстро съела бы мое время.