Как совместно использовать конфигурацию Eclipse в разных рабочих областях

Я использую Eclipse (PDT) В качестве основной IDE на разных машинах. (как дома, ноутбук, в офисе и т. д.). Как я могу поделиться конфигурацией Eclipse и project прагматически между несколькими компьютерами? Должен ли я контролировать их версию, или есть более простой способ сделать это?

Как вы гарантируете, чтобы использовать тот же самый хороший и старый, даже так до даты конфигурации всех ваших компьютеров?

10 ответов


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


совместное использование конкретных настроек eclipse в рабочих областях:

  1. на ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings
  2. скопировать все в каталог с ${new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings

это будет убедиться, что ${new_workspace} имеет ту же конфигурацию, что и ${old_workspace}

надеюсь, что это помогает. Обновление в случае каких-либо проблем.


другой вариант-экспорт/импорт:

  1. из существующего рабочего пространства,File->Export...->General->Preferences, проверьте экспорт всех и выберите файл для их сохранения (преф.epf, например)
  2. запуск Eclipse в новом рабочем пространстве,File->Import...->General->Preferences выберите файл (префов.epf), проверьте импорт всех

это отлично сработало для первоначального автора этого совета: у него было его форматирование кода, стиль кода, SVN repos, jres preferences импортированы.

Edit: On Eclipse Juno это работает плохо. Некоторые предпочтения молча не переносятся, например, действия сохранения.


Я должен был работать на нескольких рабочих пространствах одновременно, и было много предпочтений, которые должны быть установлены каждый раз, когда я создаю новое рабочее пространство. Я создал рабочую область шаблона и создал все необходимые параметры в этой рабочей области шаблона.Всякий раз, когда я создаю новое рабочее пространство, я создаю simlink {new_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings указать {template_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings. Таким образом, при редактировании любого предпочтения в любом из рабочих пространств оно будет реплицироваться во всех других рабочих пространствах.

Я создал этот псевдоним функции в моем .чтобы создать новое рабочее пространство, я запускаю эту функцию в командной строке с именем нового рабочего пространства в качестве аргумента, чтобы создать ссылку.

function eclset(){
    present_dir=`pwd`;
    cd  {parent_to_workspace}//.metadata/.plugins/org.eclipse.core.runtime ; 
    rm -rf .settings ; 
    ln -s {parent_to_workspace}/template/.metadata/.plugins/org.eclipse.core.runtime/.settings .settings;
    cd $present_dir;
}

Это относительно новый проект, но похоже, что Eclipse Oomph был создан именно по этой причине. С помощью этого инструмента вы можете создать уникальную конфигурацию которая может использоваться совместно с другими. Я не использовал его (пока), но планирую:

https://projects.eclipse.org/projects/tools.oomph


здесь есть два вопроса. Во-первых, существуют проектные определения .файлы проекта и параметры проекта. Лично мне нравятся те, что в моем исходном контроле, так как это упрощает проверку проекта и настройку IDE.

во-вторых, у вас есть параметры рабочей области. Вы увидите много вопросов в этой области. Я предлагаю взглянуть на пульс: это расширенное распределение Eclipse, которое может, среди прочего, сохранить настройки рабочей области и синхронизировать их с несколькими машинами или членами команды.


начиная с Eclipse Neon (и, возможно, Mars, а также), вы можете скопировать следующие два каталога, чтобы поделиться своим верстаком и настройками/предпочтениями среди разных рабочих областей:

    [workspace]/.metadata/.plugins/org.eclipse.core.runtime/.settings
    [workspace]/.metadata/.plugins/org.eclipse.e4.workbench

вы также можете скопировать .префов файлы ${old_workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings в папку под названием .настройки в корневой папке вашего проекта, а затем добавьте его в SVN (или CVS или...)

таким образом, настройки будут распространяться среди всех разработчиков вместе с исходным кодом во время обновления.


У меня была та же проблема.

мой подход: хранение данных проекта в папке управляемых сервисов

Проект X создается на рабочей станции A, с пользовательским путем, указывающим на новый подкаталог моей иерархии ownCloud. Рабочее пространство по умолчанию еще residenting в файловой системе А.

когда я сижу на рабочей станции B, Я открываю локальную рабочую область по умолчанию (локальную на B) и создаю новый проект, используя существующие источники в " synchronized" каталог сервисов.

просто нажмите Обновить в любое время, когда вы запускаете eclipse, и у вас есть текущие данные проекта. Синхронизация выполняется в фоновом режиме автоматически, поэтому позаботьтесь о том, чтобы закрыть eclipse и дать ownCloud возможность загружать новые файлы на сервер ownCloud.

Tomcat или другие серверы работают локально, конфигурация копируется вручную между машинами через scp. Это происходит только в случае изменений в настройке сервера, что бывает не очень часто.

У меня не было проблем с совместимостью с NEON 2 (arch linux) & NEON 3 (загрузите запуск на Debian stretch) с разными JDK.

с наилучшими пожеланиями Армин!--1-->


просто скопируйте каталоги

${old_workspace}/.metadata/.plugins

из существующего проекта в новый.

это хорошо работало в (довольно простых) PHP-проектах.