Изменения между Eclipse версий 3.1 и 3.2 повлекли за собой некоторые несовместимости, касающиеся модулей. Ниже приведено описание измененных областей и инструкции по миграции модулей версии 3.1 в 3.2. Обратите внимание, что этот раздел будет полезен только в том случае, если модули 3.1 выполняются в версии 3.2 с ошибками.
Затронутые компоненты:Клиенты 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.File | IFileStore |
---|---|
delete | delete |
getName | getName |
getParent | getParent |
list | childNames |
mkdir | mkdir(EFS.SHALLOW, null) |
mkdirs | mkdir(EFS.NONE, null) |
renameTo | move |
new FileInputStream(file) | openInputStream |
new FileOutputStream(file) | openOutputStream |
В API IFileStore большая часть информации о файле хранится в структуре с именем IFileInfo, которая получается путем вызова IFileStore.fetchInfo(). Это позволяет достигнуть лучшей оптимизации по сравнению с кодом, использующим java.io.File, поскольку многие атрибуты файла можно получить с помощью одного вызова к файловой системе. Обратите внимание, что информация в IFileInfo становится устаревшей в случае изменения исходного файла, поэтому экземпляры следует хранить только пока они необходимы. Существует несколько методов java.io.File, эквивалентных методам IFileInfo:
java.io.File | IFileInfo |
---|---|
canWrite | isReadOnly |
exists | exists |
getName | getName |
isDirectory | isDirectory |
isFile | !isDirectory() |
isHidden | isHidden |
lastModified | getLastModified |
length | getLength |
setLastModified | setLastModified |
setReadOnly | setAttribute(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);
Как и для метода 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();
Затронутые компоненты: Клиенты, вызывающие MultiPageEditorSite.progressStart()
или MultiPageEditorSite.progressEnd()
.
Описание: При разработке Eclipse 3.0 эти методы были добавлены как часть поддержки выполнения. До выпуска 3.0 был изменен способ управления выполнением, и данный метод более не требуется. Вследствие ошибки программиста эти внешние методы были оставлены в выпуске 3.0. Эти методы не обслуживают какие-либо функции в выпуске Eclipse и поэтому были удалены.
Необходимо выполнить: Клиенты, вызывающие методы
MultiPageEditorSite.progressStart()
или
MultiPageEditorSite.progressEnd()
, должны вместо этого использовать
IWorkbenchSiteProgressService
.
Затронутые компоненты: Клиенты, у которых есть пользовательский файл 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.
Затронутые компоненты: Клиенты, открывающие приложения 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.
Затронутые компоненты: Клиенты, вызывающие 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()
для вызова классов из запускаемого комплекта.
В Eclipse 3.0 символ подчеркивания ('_') в номерах версий не поддерживался. При экспорте модуля в файловую систему и при
его установке с сайта обновлений символ подчеркивания (если он был указан) в номере версии модуля заменялся на дефис ('-').
В Eclipse 3.1 была добавлена поддержка символа подчеркивания, и при экспорте или установке модуля номер его версии оставался без изменения.
Это нововведение по случайности не было описано в руководствах по переходу от версии 3.0 к версии 3.1.
В следующих версиях (включая Eclipse 3.2) предусмотрена поддержка символа подчеркивания. Это следует иметь в виду при экспорте и
загрузке с сайта обновлений старых версий модулей, в номерах которых есть этот символ. Например, нужно обращать внимание,
совпадает ли имя модуля старой версии (где символ подчеркивания заменен на дефис) с именем в файловой системе.