Несовместимости между версиями Eclipse 3.1 и 3.2

Изменения между Eclipse версий 3.1 и 3.2 повлекли за собой некоторые несовместимости, касающиеся модулей. Ниже приведено описание измененных областей и инструкции по миграции модулей версии 3.1 в 3.2. Обратите внимание, что этот раздел будет полезен только в том случае, если модули 3.1 выполняются в версии 3.2 с ошибками.

  1. Ресурсы более не требуются в локальной файловой системе
  2. Изменения API для MultiPageEditorSite
  3. Изменение содержимого файла config.ini
  4. Изменение содержимого приложений jnlp
  5. Непосредственный вызов метода Bundle.start() активирует комплект при следующем запуске
  6. Символ подчеркивания в номерах версий модулей не заменяется на дефис

1. Ресурсы более не требуются в локальной файловой системе

Затронутые компоненты:Клиенты API IWorkspace, которые предполагают, что ресурсы хранятся в локальной файловой системе.

Описание: До Eclipse 3.2 для каждого существующего IResource имелся соответствующий файл или каталог в файловой системе, доступный для java.io.File. В Eclipse 3.2 была добавлена поддержка для создания ресурсов, содержимое которых хранится в произвольной резервной файловой системе. Ресурсы, для которых используется эта поддержка, не могут представляться непосредственно как java.io.File.

Необходимо выполнить: Старый метод IResource.getLocation() возвращает путь к ресурсу в локальной файловой системе. Этот метод возвращает null для ресурсов, которые не хранятся в локальной файловой системе. Большинство инициаторов метода getLocation() получали экземпляр java.io.File, который более не может применяться для ресурсов, не хранящихся в локальной файловой системе.

Новый модуль org.eclipse.core.filesystem предоставляет базовый API файловой системы, который можно использовать вместо java.io.File. В частности, экземпляр org.eclipse.core.filesystem.IFileStore предоставляет в основном те же методы, которые доступны в java.io.File. Следующий фрагмент кода получает экземпляр IFileStore для данного ресурса:

   IResource resource = ...;//некоторый ресурс
   IFileStore store = EFS.getStore(resource.getLocationURI());

В следующей таблице представлены эквивалентные методы IFileStore для действий, которые обычно выполнялись с помощью java.io.File:

java.io.FileIFileStore
deletedelete
getNamegetName
getParentgetParent
list childNames
mkdirmkdir(EFS.SHALLOW, null)
mkdirsmkdir(EFS.NONE, null)
renameTomove
new FileInputStream(file)openInputStream
new FileOutputStream(file)openOutputStream

В API IFileStore большая часть информации о файле хранится в структуре с именем IFileInfo, которая получается путем вызова IFileStore.fetchInfo(). Это позволяет достигнуть лучшей оптимизации по сравнению с кодом, использующим java.io.File, поскольку многие атрибуты файла можно получить с помощью одного вызова к файловой системе. Обратите внимание, что информация в IFileInfo становится устаревшей в случае изменения исходного файла, поэтому экземпляры следует хранить только пока они необходимы. Существует несколько методов java.io.File, эквивалентных методам IFileInfo:

java.io.FileIFileInfo
canWriteisReadOnly
existsexists
getNamegetName
isDirectoryisDirectory
isFile!isDirectory()
isHiddenisHidden
lastModifiedgetLastModified
lengthgetLength
setLastModifiedsetLastModified
setReadOnlysetAttribute(EFS.ATTRIBUTE_READ_ONLY, true)

Например, который ранее вызывал метод java.io.File.exists(), теперь может вызывать метод IFileStore.fetchInfo().exists(). При изменении IFileInfo результат следует сохранить с помощью метода IFileStore.putInfo. Например, данный фрагмент кода изменяет атрибут файла, предназначенный только для чтения

   IFileStore store = ...;//хранилище файлов
   IFileInfo info = store.fetchInfo();
   boolean readOnly = info.getAttribute(EFS.ATTRIBUTE_READ_ONLY);
   info.setAttribute(EFS.ATTRIBUTE_READ_ONLY, !readOnly);
   store.putInfo(info, EFS.SET_ATTRIBUTES, null);

IProjectDescription.getLocation()

Как и для метода getLocation(), расположение описания проекта может находиться не в локальной файловой системе. Для получения расположения ресурса в произвольной файловой системе можно использовать метод IProjectDescription.getLocationURI().

Локальное кэширование

Некоторые клиенты должны иметь локальное представление файла. Например, в них может запускаться встроенная утилита относительно этого файла, либо могут применяться не поддерживающие Eclipse библиотеки, которые могут работать только с ресурсами файловой системы (например, java.util.zip.ZipFile). В этих случаях можно указать IFileStore возвращать кэшированную локальную копию его содержимого:

   IFileStore store = ...;//хранилище файлов
   //проверяет, можно ли его напрямую представить как локальный файл
   java.io.File local = store.toLocalFile(EFS.NONE, null);
   //если нет, то запрашивается кэшированная локальная копия файла
   if (local == null)
      local = store.toLocalFile(EFS.CACHE, null);

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

Мягкий сбой

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

   IResource resource = ...;//некоторый ресурс
   URI uri = resource.getLocationURI();
   if (uri != null && EFS.SCHEME_LOCAL.equals(uri.getScheme())) {
      //файл находится в локальной файловой системе
   } else {
      //файл отсутствует в локальной файловой системе
   }

Если имеется экземпляр IFileStore, можно получить схему следующим образом:

   IFileStore store = ...;//хранилище файлов
   store.getFileSystem().getScheme();

2. Изменения API для MultiPageEditorSite

Затронутые компоненты: Клиенты, вызывающие MultiPageEditorSite.progressStart() или MultiPageEditorSite.progressEnd().

Описание: При разработке Eclipse 3.0 эти методы были добавлены как часть поддержки выполнения. До выпуска 3.0 был изменен способ управления выполнением, и данный метод более не требуется. Вследствие ошибки программиста эти внешние методы были оставлены в выпуске 3.0. Эти методы не обслуживают какие-либо функции в выпуске Eclipse и поэтому были удалены.

Необходимо выполнить: Клиенты, вызывающие методы MultiPageEditorSite.progressStart() или MultiPageEditorSite.progressEnd(), должны вместо этого использовать IWorkbenchSiteProgressService.

3. Изменение содержимого файла config.ini

Затронутые компоненты: Клиенты, у которых есть пользовательский файл config.ini, меняющие версию Eclipse на 3.2.

Описание: До Eclipse 3.2 для параметра osgi.bundles, заданного в файле config.ini, обычно указывалось значение org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start. Из-за рефакторинга выполнения это значение необходимо обновить для успешного запуска приложения.

Требуется: Изменить значение параметра osgi.bundles на org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start.

4. Изменение содержимого в приложениях jnlp

Затронутые компоненты: Клиенты, открывающие приложения RCP и указавшие значение для osgi.bundles.

Описание: До Eclipse 3.2 для параметра osgi.bundles, заданного в основном файле jnlp, обычно указывалось значение org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start. Из-за рефакторинга выполнения это значение необходимо обновить, иначе может возникнуть исключительная ситуация NullPointerException, препятствующая успешному запуску приложения.

Требуется: Изменить значение параметра osgi.bundles на org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start.

5. Непосредственный вызов метода Bundle.start() активирует комплект при следующем запуске

Затронутые компоненты: Клиенты, вызывающие Bundle.start().

Описание: В Eclipse для отложенного запуска комплекта применяется заголовок Eclipse-LazyStart (или устаревший заголовок Eclipse-AutoStart). В Eclipse 3.1 метод org.osgi.framework.Bundle.start() не помечал комплекты с отложенным запуском как постоянно запускаемые. Поскольку комплекты с отложенным запуском никогда не были помечены как постоянно запускаемые, они не активировались автоматически при перезапуске Eclipse. Утилита javadoc для метода Bundle.start() указывает, что после вызова этого метода произойдет следующее:

"Будет составляться журнал запуска комплекта. Комплект будет запускаться автоматически при перезапуске среды. "

В Eclipse 3.2 метод Bundle.start() помечает комплект как постоянно запускаемый, даже если для этого комплекта предусмотрен отложенный запуск. Теперь этот метод совместим со спецификацией среды OSGi. В результате при вызове Bundle.start() комплект будет активироваться при перезапуска Eclipse. Однако у этого изменения есть и негативная сторона: при каждом запуске Eclipse будут активироваться ненужные комплекты. Иногда могут возникнуть непредвиденные ситуации, например, неполадка 134412.

Требуется: Клиенты Bundle.start() должны определить, нужно ли активировать комплект при каждом запуске. Если нет - необходимо найти другой способ запуска комплекта. В большинстве случаев вместо метода Bundle.start() можно применять отложенный запуск с помощью вызова классов из целевого комплекта. В некоторых сценариях комплект с отложенным запуском необходимо намерено запустить, не помечая его как постоянно активируемый при запуске. В этих сценариях вместо Bundle.start() следует использовать метод Bundle.loadClass() для вызова классов из запускаемого комплекта.

5. Символ подчеркивания в номерах версий модулей не заменяется на дефис

В Eclipse 3.0 символ подчеркивания ('_') в номерах версий не поддерживался. При экспорте модуля в файловую систему и при его установке с сайта обновлений символ подчеркивания (если он был указан) в номере версии модуля заменялся на дефис ('-').
В Eclipse 3.1 была добавлена поддержка символа подчеркивания, и при экспорте или установке модуля номер его версии оставался без изменения. Это нововведение по случайности не было описано в руководствах по переходу от версии 3.0 к версии 3.1. В следующих версиях (включая Eclipse 3.2) предусмотрена поддержка символа подчеркивания. Это следует иметь в виду при экспорте и загрузке с сайта обновлений старых версий модулей, в номерах которых есть этот символ. Например, нужно обращать внимание, совпадает ли имя модуля старой версии (где символ подчеркивания заменен на дефис) с именем в файловой системе.