Интеграция Ant Builder в Eclipse: Относительные пути для рабочего набора обновления области действия.

Question

Этот вопрос похож на Интеграция Ant Builder в Eclipse: Ошибка «Переменные ссылки пустой выбор» , но запрашивает что-то другое.

В моем проекте Eclipse JDT у меня есть несколько задач ant, которые я хочу выполнить перед компиляцией, поэтому я добавил ant builder в свою конфигурацию Eclipse builder. Теперь я хочу настроить два параметра «обновить ресурсы по завершении» и «рабочий набор соответствующих ресурсов» для этого компоновщика, чтобы они содержали определенный каталог в моем проекте.

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

Проблема в том, что весь проект управляется в хранилище Subversion. Конфигурация Eclipse является частью репозитория, и другие пользователи проверяют это с помощью различных макетов файловой системы и, возможно, разных имен проектов Eclipse. Например, у меня обычно есть несколько рабочих копий одного и того же проекта в моей рабочей области Eclipse, каждая с разным именем проекта.

Вот почему я ищу способ , как указать рабочий набор в Eclipse относительно каталога проекта (не каталог рабочего пространства), или какой-то другой способ определить область обновления построитель такой, что он включает в себя один каталог в моем проекте .

Я использую Eclipse 3.7 (Индиго).

Если я настраиваю рабочий набор в диалоговом окне и затем просматриваю файл конфигурации, следующая строка является значением опции ATTR_REFRESH_SCOPE:

${working_set:
<?xml version="1.0" encoding="UTF-8"?>

<resources>

<item path="/MyProject" type="4"/>

</resources>}

Дезинфицированный это выглядит так:

${working_set:
  <?xml version="1.0" encoding="UTF-8"?>
  <resources><item path="/MyProject/lib" type="2"/></resources>
}

Так что я хочу получить часть "MyProject" из этого. Я попытался решить вопрос, упомянутый выше, и заменил путь на ${build_project:/lib}. Это не дает сообщения об ошибке, но, похоже, не имеет никакого эффекта (Eclipse не обновит упомянутый каталог).

Я также пытался заменить все определение рабочего набора на ${build_project:/lib}, но это выдает сообщение об ошибке Unable to restore resource memento.

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

Answer 1

К сожалению, Eclipse плохо работает с относительными каталогами.

Относительные пути в Eclipse

Однако вы можете сделать следующее:

• Создать новое рабочее пространство.
• Импорт файлов из известного местоположения, которое будет одинаковым на всех машинах.
• Настройте все внутри этого известного каталога.
• Предоставьте рабочую область и инструкции по настройке другим разработчикам, чтобы они использовали этот же «известный каталог».

Вы могли бы иметь что-то вроде

C:\YourKnownDir\
    \workspace\
    \src\
    \build\

и запустите затмение с помощью командного файла:

start %ECLIPSE_DIR%\eclipse.exe -data .\workspace

Если вы собираетесь включить файлы .project в SVN, на самом деле должен быть заранее заданный полный путь. EG:

C:\svn

Надеюсь, это поможет, но я не знаю другого способа решения этой проблемы.

Answer 2

В аналогичной ситуации я решил обновить «Проект, содержащий выбранный ресурс» (как вы уже сказали, он не зависит от названия проекта) и пометил «Производный ресурс» как можно большим количеством папок (Свойства папки -> Ресурс -> флажок «Производный»). Eclipse обновит производные ресурсы, но не попытается проверить / перестроить / и т. Д.

Answer 3

Совершенно другой подход:

Я думаю, что ограничения общих конфигурационных файлов Eclipse (то есть конфигурационных файлов, переданных в SVN) достаточно велики; некоторые люди предпочитают иметь свои зависимые библиотеки в качестве источника на диске, другие предпочитают ссылки JAR; Имена проектов каждого пользователя и относительные местоположения рабочей области различны, и так далее. И, как вы видели, многие параметры относятся либо к местоположению проекта (т.е. не может ссылаться на другие проекты), либо к местоположению рабочей области.

Поскольку у меня обычно есть файлы сборки Maven, я использую maven-eclipse-plugin для генерации из них файлов конфигурации Eclipse. Есть несколько вариантов на выбор во время выполнения, и почти все может быть настроено в файле сборки (и если нет, просто подключите плагин к этому плагину, который делает то, что вы хотите, и отправьте его вместе со своей сборкой. Maven автоматически соберет это плагин при необходимости для пользователей, которые его используют). А также некоторые более абстрактные настройки распределяются между плагинами, поэтому, если кто-то настаивает на использовании Netbeans вместо Eclipse, он, по крайней мере, получит элементарно сконфигурированный проект (зависимости, версии JRE, наборы символов и т. Д.), Когда я никогда не использовал или даже не использовал их. настроил NetBeans.

Положительный побочный эффект: при добавлении или обновлении зависимости библиотеки необходимо обновить только одно место (Maven POM), а остальное можно легко восстановить.

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

Answer 4

Как насчет добавления одного уровня папки в хранилище? Добавим проект в одну папку в репозитории. так что всякий раз, когда проект извлекается, он создает папку с именем проекта.
В настоящее время, если вы оформляете заказ в папке workspace1. Это должно выглядеть примерно так:

workspace_1\lib

Если вы добавите один уровень папок в репо, то есть название проекта (например, MyProject здесь), каждый, кто проверит проект, получит одно и то же имя проекта. и несколько копий проекта будут выглядеть как

workspace_1\MyProject\lib
workspace_2\MyProject\lib

Таким образом, вы можете всегда создавать несколько копий проекта с одним и тем же именем проекта, и ваш скрипт всегда может использовать эту уникальность имени проекта.