Вопросы и ответы по миграции модулей в Eclipse 3.1

Почему Eclipse API содержит несовместимые изменения между версиями 2.1 и 3.0?

Eclipse 3.0 является развитием Eclipse 2.1. В некоторых областях нам не удалось усовершенствовать Eclipse, сохранив безупречную совместимость с предыдущими версиями. Четырьмя основными причинами возникновения несовместимости являются:

Список отдельных несовместимостей.

Будет ли модуль 2.1 работать в Eclipse 3.0?

Да, за некоторыми исключениями. Если модуль использует только API Eclipse 2.1, он будет работать в версии 3.0. Есть единичные исключения в API, когда не удалось сохранить совместимость между версиями 2.1 и 3.0. Если модуль применяет эти функции, он не будет работать.

Мой модуль 2.1 использует классы во внутренних пакетах. Будет ли он работать в Eclipse 3.0?

Если модуль использует внутренние классы или поведение, не заданное в API Eclipse 2.1, невозможно с уверенностью утверждать о его совместимости или несовместимости с версией 3.0. Для этого потребуется попробовать запустить его.

Как запустить модуль в Eclipse 3.0, не внося в него изменений?

Установите ваш модуль 2.1 в каталог eclipse/plugins/ продукта Eclipse 3.0 и перезапустите Eclipse. Eclipse распознает модуль старой версии 2.1 (по заголовку файла plugin.xml) и автоматически внесет нужные изменения в зависимости модуля и переименованные точки расширения платформы.

Нужно ли вносить изменения в модуль 2.1 для правильной компиляции в Eclipse 3.0?

Да, во всех случаях. Есть определенные различия между Eclipse 2.1 и 3.0, требующие внесения изменений во все компилируемые модули. Если вы хотите перекомпилировать модуль, созданный для 2.1, необходимо перенести его в 3.0 перед дальнейшей разработкой под 3.0.

Как перенести модуль в Eclipse 3.0?

После загрузки (или импорта) модуля в рабочую среду Eclipse 3.0 воспользуйтесь контекстным меню проекта Инструменты PDE > Миграция в 3.0 для преобразования манифеста модуля в формат 3.0 и автоматического изменения списка требуемых модулей платформы и ссылок на точки расширения, которые были переименованы. В большинстве случаев после этого модуль должен компилироваться и выполняться безупречно. Затем желательно пересмотреть код модуля, чтобы убедиться, что он не зависит от функций API, ставших несовместимыми.

Будут ли отображены ошибки или предупреждения при компиляции модуля, использующего ставшие несовместимыми компоненты API?

Нет. Некоторые несовместимости не определяются компилятором Java.

Можно ли просто игнорировать предупреждения о коде, использующем старые элементы API?

Да, на протяжении некоторого времени. При возможности, старые API помечаются как устаревшие, а не удаляются и продолжают работать (что возможно лишь при определенных обстоятельствах). Несмотря на то, что срочной необходимости избавляться от старых API нет, они считаются старыми потому, что есть лучший способ выполнения задачи. Желательно удалить из модулей использование устарелых API как можно скорее.

После переноса моего модуля в Eclipse 3.0, могу ли я установить и выполнить конечный получающийся двоичный модуль в Eclipse 2.1?

Нет. Такая возможность не поддерживается и, возможно, не будет работать из-за переименованных точек расширения.

Каково назначение org.eclipse.core.runtime.compatibility?

Переход в версии 3.0 к работе на базе OSGi привел к устареванию некоторых имеющихся динамических ключевых API. Там, где это возможно, устаревшие API в пакетах org.eclipse.core.runtime.* и их реализации были перемещены из модуля org.eclipse.core.runtime в новый модуль org.eclipse.core.runtime.compatibility. По умолчанию новые модули зависят от org.eclipse.core.runtime. Предполагается, что они будут использовать только не устаревшие динамические API. С другой стороны, имеющиеся модули при переносе из версии 2.1 будут зависеть по умолчанию от org.eclipse.core.runtime.compatibility, а также смогут использовать и старые API (модуль org.eclipse.core.runtime.compatibility повторно экспортирует API из org.eclipse.core.runtime). Хотя модуль org.eclipse.core.runtime.compatibility вероятнее всего будет включен в конфигурации IDE Eclipse, вряд ли стоит ждать его включения в продукты на базе конфигураций RCP.

Каково назначение org.eclipse.ui.workbench.compatibility?

org.eclipse.ui.workbench.compatibility является фрагментом модуля, предоставляющим расширенную двоичную совместимость с модулями 2.1, выполняемыми в продуктах на базе Eclipse 3.0. В версии 3.0 шесть методов с явной зависимостью от IFile или IMarker были перемещены из интерфейса org.eclipse.ui.IWorkbenchPage для четкого разделения рабочей среды и рабочей области и ресурсов. Фрагмент org.eclipse.ui.workbench.compatibility позволяет поместить эти методы обратно, чтобы имеющиеся модули 2.1 можно было выполнять без изменений. Обратите внимание, что переносимые в версию 3.0 модули, ссылающиеся на перемещенные методы, вызовут ошибки компилирования, устранить которые можно, только вызвав замещающие методы, расположенные в org.eclipse.ui.ide.IDE.

Речь идет о методах IWorkbenchPage: openEditor(IFile), openEditor(IFile, String), openEditor(IFile, String, boolean), openEditor(IMarker), openEditor(IMarker, boolean), and openSystemEditor(IFile).