Как выразить, предают зависимости проекта земле в Eclipse PDE

With a complex set of build dependencies, I've found Maven2 and Hudson (for CI) to be a pretty nice combination. It took a while to set up the infrastructure and get my head around configuration, but after that, it just worked.

Of course, you are dependent then on Maven2 (or Hudson) support for your build mechanism. I'm not sure how well Eclipse Headless builds are supported. But if the only reason you're using Eclipse headless is to allow the dependencies to be expressed in a single place, do yourself a favour and switch.

Проекты Eclipse зависят друг от друга благодаря флажку в свойствах проекта (зависимые проекты?). Именно так Eclipse решает, что строить. Вы можете установить это самостоятельно, но обычно это устанавливается при изменении пути сборки Java. Он хранит данные в файле .project IIRC, поэтому, пройдя через графический интерфейс и увидев, какие изменения, вы можете более гибко применять другие.

Однако похоже, что вы хотите смешивать и сопоставлять Банки и связки. Самый простой способ сделать это - рассматривать все проекты как проекты Java. В проекте PDE вы действительно можете зайти и настроить путь сборки Java; он будет жаловаться и говорить, что это неправильно, но это позволит вам иметь проект PDE в зависимости от проекта Java без всего этого пушистого JAR. Сказав это, меня не удивит, если при таком подходе возникнут проблемы во время выполнения - среда выполнения PDE, скорее всего, не увидит это таким образом.

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

Таким образом, PDE может генерировать пакеты OSGi, и что это просто еще одно название для JAR + Manifest. Вы можете использовать JAR точно так же в других средах (например, для вашего EAR или другого использования клиентом), и вы можете воспользоваться уровнем OSGi в своем приложении. На самом деле нет причин не делать этого, учитывая тип гибридного пакета, о котором вы говорите.

В нашем решении используется конструктор Ant для копирования каталогов "классов" простые проекты Java прямо в верхний каталог проекта плагина. Мы пропускаем этап создания JAR, чтобы сэкономить время, и он работает довольно хорошо. Если проект плагина зависит от уже созданных внешних JAR-файлов, мы также копируем их.

Вот как именно настроить его в Eclipse 3.5 (извините за странное форматирование, но это единственный способ сохранить отступ):

 Создать пустой каталог "классы" в проекте плагина
Выберите проект плагина, нажмите F5, чтобы обновить ресурсы
Создайте новый файл сборки Ant в проекте плагина для копирования зависимостей (наш показан ниже)

Щелкните проект плагина правой кнопкой мыши и выберите Свойства.
 Выбрать строителей
 Нажмите «Создать ...» (откроется диалоговое окно «Изменить конфигурацию»).
 Выберите Ant Builder и нажмите «ОК».
 Назовите свой конструктор (наш называется "PluginProject externals")
 Просмотрите рабочую область для файла сборки (наша - $ {workspace_loc: /PluginProject/copyDependencies.xml})
 щелкните вкладку Обновить
 установите флажок «Обновить ресурсы по завершении», нажмите «Определенные ресурсы»
 нажмите «Указать ресурсы ...», установите флажок для каталога классов, нажмите «Готово»
 Нажмите «ОК» (закрывает диалоговое окно «Редактировать конфигурацию»).
 Нажмите «Вверх», чтобы переместить «Внешние элементы PluginProject» в верхнюю часть списка конструкторов.
Нажмите «ОК» (закрывает диалоговое окно «Свойства»).

Откройте файл MANIFEST.MF вашего проекта плагина.
Перейдите на вкладку «Время выполнения».
Нажмите «Добавить ...» в «Путь к классам», выберите каталог «классы» и JAR-файлы и нажмите «ОК».

Ручное создание пустого каталога «классы» в проекте надстройки позволяет указать новому построителю обновить этот ресурс (который еще не существует до запуска нового построителя). Вот что находится в нашем файле copyDependencies.xml:

<project name="Copy dependencies" default="copyDependencies" basedir=".">
  <!--
    This copying is needed because it appears that Eclipse plugins can't
    depend directly on external Eclipse projects.
  -->
  <description>
    Copies external dependency class andd JAR files into this plugin's directory.
  </description>

  <target name="copyDependencies">
    <copy file="../External/JDOM/jdom-1.0/build/jdom.jar" todir="." preservelastmodified="true"/>
    <copy file="../External/Xalan/xalan-j_2_6_0/bin/xalan.jar" todir="." preservelastmodified="true"/>
    <copy file="../External/Xalan/xalan-j_2_6_0/bin/xercesImpl.jar" todir="." preservelastmodified="true"/>
    <copy file="../External/Xalan/xalan-j_2_6_0/bin/xml-apis.jar" todir="." preservelastmodified="true"/>
    <copy todir="./classes/com/arm" preservelastmodified="true">
      <fileset dir="../Utilities/src/com/arm" excludes="**/*.java"/>
    </copy>
  </target>
  <target name="clean" description="Deletes local copies of external classes and JARs.">
    <delete file="jdom.jar" quiet="true"/>
    <delete file="xalan.jar" quiet="true"/>
    <delete file="xercesImpl.jar" quiet="true"/>
    <delete file="xml-apis.jar" quiet="true"/>
    <delete dir="./classes/com/arm/utilities" quiet="true"/>
  </target>
</project>

Единственным недостатком этого метода, по-видимому, является то, что Eclipse не на 100% идеален для вызова внешнего построителя, когда его нужно вызвать, поэтому иногда вам нужно выполнять "Project > Очистить ... "в Eclipse, чтобы заставить его двигаться дальше.

Примите мои соболезнования. Я тоже боролся с этой проблемой и стеной молчания со стороны разработчиков Eclipse по такому простому и очевидному вопросу: как объявить зависимость от плагина для обычного Java-проекта (так, чтобы она работала во время выполнения)?

Я не думаю, что они поддерживают это. Единственный способ, которым я обошел эту проблему - это создание папок внутри моих проектов плагинов, которые на самом деле являются ссылками на папки bin/ проектов java, а затем включение этих папок в плагин. Это, по крайней мере, работает, но хрупко из-за требуемых абсолютных путей к файловой системе.

У меня точно такие же проблемы. У нас есть набор из нескольких обычных java-проектов, которые могут быть созданы Maven, и все они (в настоящее время) должны использовать один и тот же путь к классам для правильной работы. Эти проекты можно использовать для запуска сервера в среде, отличной от OSGi. Кроме того, у нас есть клиент Eclipse RCP, который использует эти проекты как один пакет. Я прекрасно могу собрать этот большой пакет с Maven, используя плагин Apache Felix Maven Bundle, и все работает нормально. Но всякий раз, когда я меняю один класс в обычном проекте, мне приходится перестраивать весь пакет. Добавочная сборка и связывание ресурсов не работают.

Я попробовал «решение», связав каталоги двоичных файлов / исходных кодов из этих проектов с путем к классам Manifest one-big-bundle, и, похоже, это сработало, но это был бы настоящий кошмар обслуживания, потому что мне даже пришлось связать некоторых отдельных файлы.

По иронии судьбы, ИЗ-ЗА использования OSGi в клиенте я на самом деле думаю о том, чтобы свернуть нашу красивую и модульную структуру с модулями Maven в подпакеты только одного проекта плагина. Это лучшая альтернатива, чем очень медленное развитие.

Другая, лучшая альтернатива (по словам разработчиков OSGi), которую я изучу в первую очередь, - это объединить все мои модули Maven в пакеты OSGi.Но это может быть настоящий PITA, потому что я зависим от сканирования путей к классам и объединения нескольких файлов конфигурации из нескольких пакетов (иногда с одним и тем же именем) для формирования одной конфигурации.

(В частности, мы используем фреймворк Spring и объединяем несколько файлов persistence.xml в один контекст сохранения. Мы также объединяем несколько файлов контекста Spring XML из разных модулей (все с разными ASPECT), которые вместе должны формировать один контекст Spring, который будет используется Spring-DM.)