Inkompatibilitet mellan Eclipse 2.1 och 3.0

Eclipse har ändrats på ett inkompatibelt sätt mellan version 2.1 och 3.0 på ett sätt som påverkar insticksprogram. Under följande rubriker beskrivs de olika områdena som har ändrats. Här finns även instruktioner för hur du migrerar 2.1-insticksprogram till version 3.0. Du behöver endast läsa detta om det har uppstått problem när du ska köra 2.1-insticksprogrammet i version 3.0.

  1. Manifestversion för insticksprogram
  2. Omstrukturera insticksprogram för plattformsanvändargränssnittet
  3. Omstrukturera insticksprogram för plattformskärnans runtime
  4. Borttagning av insticksprogrammet Xerces
  5. Eclipse 3.0 arbetar mer samtidigt
  6. Öppna redigerare på IFiles
  7. Redigerare gå till markör
  8. Startprogram för redigerare
  9. Redigerare för registret
  10. Hjälpregister för arbetsmiljömarkör
  11. Dokumentprovider för textredigerare
  12. Textredigerare
  13. Konsollöst stöd för anteckningar
  14. Konsolvyn
  15. Lyssnare för Java-brytpunkt
  16. Urklippsaccess i användargränssnittstråd
  17. Tangentnedtryckningshändelser
  18. Tabbförflyttning mellan anpassade kontroller
  19. Ordningsföljd för markeringshändelser i SWT-tabeller och trädgränssnittskontroller
  20. Ny allvarlighetsgrad i statusobjekt
  21. Byggrelaterade meddelanden om resursändringar
  22. Mellanliggande meddelanden vid åtgärder på arbetsytan
  23. Hanterarutökningar för URL-strömmar
  24. Inläsningsordning för klasser
  25. Skyddsdomän för klassinläsare inte angiven
  26. PluginModel-objektsomvandling
  27. Implementering av ILibrary ofullständig
  28. Ogiltiga antaganden beträffande URL-formatet
  29. BootLoader-metoder flyttade/borttagna
  30. Export av insticksprogram inkluderar inte insticksprogrammets JAR-filer automatiskt
  31. Exportera om runtime-API
  32. Insticksprogrammets tolkningsmetoder på plattformen
  33. Insticksprogrammets bibliotek anges av fragment
  34. Ändringar av byggskript
  35. Ändringar av Ant-åtgärder för PDE-byggen
  36. Ändringar av Ant-åtgärder för eclipse.build
  37. Ändringar av Ant-åtgärder för eclipse.fetch
  38. Ersättning av install.ini

1. Manifestversion för insticksprogram

Huvudet i manifestfilerna för insticksprogram (och insticksprogramfragment) här ändrats så att de nu inkluderar en ny rad som identifierar rätt manifestversion för insticksprogrammet. Före version 3.0 innehöll inte insticksprogram en av dessa <?eclipse ...?>-rader. Efter version 3.0 måste de däremot göra det. Ändringen finns för att Eclipse runtime på ett säkert sätt ska känna igen alla insticksprogramversioner tidigare än 3.0 som har portats till version 3.0. På så sätt kan Eclipse runtime automatiskt erbjuda en större binär kompatibilitet för sådana insticksprogram. Detta är det allmänna formatet på filen plugin.xml (filen fragment.xml är liknande):

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
    ...
</plugin>

Manifestfiler för insticksprogram som har skapats av PDE 3.0 har automatiskt detta format. Vi rekommenderar att du använder migreringsverktyget för PDE-insticksprogram. Verktyget infogar automatiskt den angivna raden i manifestfilen för 2.1-insticksprogram och insticksprogramfragment adresserar många av de andra ändringarna som beskrivs här.

Om du lägger till direktivet i filen plugin.xml (manuellt eller med hjälp av PDE) måste filen även uppdateras så att den explicit listar de insticksprogram som den är beroende av. Före Eclipse 3.0 var till exempel beroenden på org.eclipse.core.runtime och org.eclipse.core.boot implicita. I och med version 3.0 behövs inte org.eclipse.core.boot längre och utvecklare måste välja org.eclipse.core.runtime eller org.eclipse.core.runtime.compatibility (eller ingendera) som passar bäst.

Obs! Detta är en av de inkompatibiliteter som inte påverkar hur binära 2.1-insticksprogram körs av Eclipse 3.0.

2. Omstrukturera insticksprogram för plattformsanvändargränssnittet

Insticksprogrammet org.eclipse.ui, som var plattformens huvudanvändargränssnitt, har nu endast det API och de utökningspunkter som krävs för den allmänna (dvs. icke-IDE-specifika) arbetsmiljön. Valfria och IDE-specifika API:er och utökningspunkter har flyttats till andra insticksprogram.

Effekten av denna förändring är tvådelad: (1) den flyttade utökningspunkten, org.eclipse.ui, har nya utökningspunkts-ID; och (2) listan med obligatoriska insticksprogram har ändrats.

Utökningspunkterna, org.eclipse.ui, i följande tabell har flyttats till andra insticksprogram, vilket har medfört att deras utökningspunkt-ID har ändrats. Om ett befintligt insticksprogram lägger till en utökning i de flyttade utökningspunkterna kommer referensen i "point"-attributet som hör till <extension>-elementet i manifestfilen för insticksprogrammet att ändras och hänvisa till motsvarande nya utökningspunkt-ID. Migrationsverktyget för PDE-insticksprogram utför dessa ändringar.

Obs! Detta är en av de inkompatibiliteter som inte påverkar hur binära 2.1-insticksprogram körs av Eclipse 3.0. Eclipse 3.0 runtime upptäcker automatiskt insticksprogram som är äldre än version 3.0 (genom frånvaron av den ovan nämnda <?eclipse version="3.0"?>-raden i manifestfilen till insticksprogrammet) och kompenserar automatiskt för dessa ändringar av utökningspunkter och insticksprogramberoenden.

Gammalt utökningspunkts-ID

Nytt utökningspunkts-ID

org.eclipse.ui.markerHelp org.eclipse.ui.ide.markerHelp
org.eclipse.ui.markerImageProviders org.eclipse.ui.ide.markerImageProviders
org.eclipse.ui.markerResolution org.eclipse.ui.ide.markerResolution
org.eclipse.ui.projectNatureImages org.eclipse.ui.ide.projectNatureImages
org.eclipse.ui.resourceFilters org.eclipse.ui.ide.resourceFilters
org.eclipse.ui.markerUpdaters org.eclipse.ui.redigerare.markerUpdaters
org.eclipse.ui.documentProviders org.eclipse.ui.redigerare.documentProviders
org.eclipse.ui.workbench.texteditor.
markerAnnotationSpecification
org.eclipse.ui.redigerare.markerAnnotationSpecification

I följande tabell visas de API-paket som tidigare tillhandahölls av insticksprogrammet org.eclipse.ui, som har flyttats till andra insticksprogram. (Namnen på API-paketen, klasserna, fälten och metoderna ändrades inte.) I vissa fall är API-paketen nu delade över fler än ett insticksprogram. Eftersom API-klasserna som är synliga för ett insticksprogram bestäms av det insticksprogrammets lista över obligatoriska insticksprogram, kanske "<requires>"-elementen måste justeras i en befintlig manifestfil för ett insticksprogram så att accessen till API-klassen återställs.

Ändringen påverkar endast insticksprogram som är beroende av insticksprogrammet org.eclipse.ui (dvs. som inkluderar <import plugin="org.eclipse.ui"/> i avsnittet <requires> i manifestfilen för insticksprogrammet). Inga andra insticksprogram påverkas. Om insticksprogrammet påverkas kanske du måste ändra <import>-elementet eller lägga till flera <import>-element så att alla API-klasser som insticksprogrammets behöver finns i omfånget. Vi rekommenderar att insticksprogram endast tar med beroenden till de insticksprogram som verkligen används. Om du tar med onödiga beroenden försämras runtime-prestandan eftersom Java-klassinläsaren måste söka efter klasser i alla beroende parter. (Migrationsverktyget för PDE-insticksprogram rättar till beroendena och hjälper till att bestämma den minsta uppsättningen.)

API-paket

2.1-insticksprogram

Motsvarande 3.0-insticksprogram

org.eclipse.jface.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.text.* org.eclipse.ui org.eclipse.jface.text
org.eclipse.ui org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.actions org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.dialogs org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.editors.* org.eclipse.ui org.eclipse.ui.editor
org.eclipse.ui.model org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.part org.eclipse.ui org.eclipse.ui, org.eclipse.ui.ide
org.eclipse.ui.texteditor org.eclipse.ui org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors
org.eclipse.ui.texteditor.* org.eclipse.ui org.eclipse.ui.workbench.texteditor
org.eclipse.ui.views.bookmarkexplorer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.contentoutline org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.markers org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.navigator org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.views.properties org.eclipse.ui org.eclipse.ui.views
org.eclipse.ui.views.tasklist org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.datatransfer org.eclipse.ui org.eclipse.ui.ide
org.eclipse.ui.wizards.newresource org.eclipse.ui org.eclipse.ui.ide

3. Omstrukturera insticksprogram för plattformskärnans runtime

Eclipse 3.0 har en plattforms-runtime som är baserad på OSGi, vilket kräver ändringar i strukturen av de två plattforms-runtime-insticksprogrammen org.eclipse.core.runtime och org.eclipse.core.boot.

Ett nytt insticksprogram, org.eclipse.core.runtime.compatibility, tillhandahåller en implementeringsbrygga mellan de gamla och de nya API:erna och är den nya platsen för många av de inaktuella API:erna som tidigare fanns i org.eclipse.core.runtime och org.eclipse.core.boot. Utökningspunkter för plattforms-runtimepåverkas inte av omstruktureringen.

När du migrerar ett befintligt insticksprogram till version 3.0 måste manifestfilen till insticksprogrammet uppdateras för att de nya strukturerna i insticksprogrammen för Eclipse-plattformens runtime ska visas. Migrationsverktyget för PDE-insticksprogram lägger till ett beroende i org.eclipse.core.runtime.compatibility, om det behövs.

Observera att om du markerar insticksprogrammet som version 3.0 (med <?eclipse version="3.0"?>) och insticksprogrammet definierar en insticksprogramklass, måste du antingen explicit ange <import plugin="org.eclipse.core.runtime.compatibility"/> i manifestfilen för insticksprogrammet eller se till att insticksprogramklassen definierar standardkonstruktionsfunktionen.

Obs! Detta är en av de inkompatibiliteter som inte påverkar hur binära 2.1-insticksprogram körs av Eclipse 3.0. Eclipse 3.0 runtime upptäcker automatiskt insticksprogram som är äldre än version 3.0 (genom frånvaron av <?eclipse version="3.0"?>-raden i manifestfilen till insticksprogrammet) och kompenserar automatiskt för dessa ändringar av plattformens runtime.

4. Borttagning av insticksprogrammet Xerces

Insticksprogrammet org.eclipse.xerces behövs inte längre och har tagits bort. XML-tolkstöd är inbyggt i J2SE 1.4 och närvaron av insticksprogrammet Xerces skapar klassinläsningskonflikter. API-paketen javax.xml.parsers, org.w3c.dom.* och org.xml.sax.*, som tidigare tillhandahölls av insticksprogrammet org.eclipse.xerces, finns numera i J2SE-biblioteken.

Om insticksprogrammet kräver insticksprogrammet org.eclipse.xerces måste du ändra i manifestfilen för insticksprogrammet och ta bort detta beroende. När det är klart bör insticksprogrammets kod kompilera och köra utan fler ändringar.

Binära 2.1-insticksprogram med ett angivet beroende till insticksprogrammet org.eclipse.xerces kommer att sakna förutsättningar när det körs i en Eclipse 3.0-standardkonfiguration. Insticksprogrammet kommer som en konsekvens inte att aktiveras.

5. Eclipse 3.0 arbetar mer samtidigt

Före Eclipse 3.0 arbetade Eclipse mestadels i en tråd. De flesta API-metoder och utökningspunkter fungerade antingen i användargränssnittstråden eller i en tråd som kom från en förloppsindikator som blockerar användargränssnittstråden. De flesta konstruktörer av insticksprogram behövde inte tänka på trådsäkerhet förutom att se till att all användargränssnittsaktivitet förekom i användargränssnittstråden. I Eclipse 3.0 är det normalt sett mycket mer samtidighet. Flera åtgärder inträffar nu i en bakgrundstråd, där de kan köras samtidigt med andra trådar, inklusive användargränssnittstråden. Alla insticksprogram vars kod körs i en bakgrundstråd måste hålla reda på trådsäkerheten i koden.

Förutom insticksprogram som explicit utför åtgärder i bakgrunden med API:et org.eclipse.core.runtime.jobs, finns det flera plattforms-API-möjligheter och utökningspunkter som utnyttjar bakgrundstrådar. Insticksprogram som hakar på dessa möjligheter måste se till att koden är trådsäker. I följande tabell sammanfattas API och utökningspunkter som kör en del av eller all sin kod i en bakgrundstråd i Eclipse 3.0:

Utökningspunkt eller API-klass

Anmärkningar

org.eclipse.core.runtime.IRegistryChangeListener Ny i Eclipse 3.0, körs i bakgrunden
org.eclipse.core.resources.IResourceChangeListener AUTO_BUILD-händelser körs nu i bakgrunden
org.eclipse.core.resources.builders (utökningspunkt) Automatiska byggen körs nu i bakgrunden
org.eclipse.core.resources.ISaveParticipant SNAPSHOT körs nu i bakgrunden
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (utökningspunkt) Ny i Eclipse 3.0, körs i bakgrunden
org.eclipse.ui.decorators (utökningspunkt) Körs redan i Eclipse 2.1 i bakgrunden
org.eclipse.ui.startup (utökningspunkt) Körs redan i Eclipse 2.1 i bakgrunden
uorg.eclipse.team.core.org.eclipse.team.core.repository (utökningspunkt) Flera åtgärder körs nu i bakgrunden
org.eclipse.team.ui.synchronizeParticipants (utökningspunkt) Ny i Eclipse 3.0, körs i bakgrunden
org.eclipse.debug.core.launchConfigurationTypes (utökningspunkt) Körs nu i bakgrunden
org.eclipse.jdt.core.IElementChangedListener ElementChangedEvent.PRE_AUTO_BUILD körs nu i bakgrunden, POST_RECONCILE kördes redan i bakgrunden

Det finns flera strategier för att göra koden trådsäker. En enkel lösning är att se till att allt arbete sker i användargränssnittstråden, vilket ger en seriell körning. Detta är ett vanligt sätt för användargränssnittsbaserade insticksprogram som inte har CPU-intensiv bearbetning. Om du använder detta bör du vara medveten om risken för dödläge som finns i Display.syncExec. Display.asyncExec är normalt sett säkrare eftersom det inte medför risken för dödläge, dock på bekostnad av att den exakta kontrollen när koden körs går förlorad.

Övrig teknik för trådsäker kod är bland annat:

6. Öppna redigerare på IFiles

Följande metoder är borttagna ur gränssnittet org.eclipse.ui.IWorkbenchPage. IWorkbenchPage deklareras i den allmänna arbetsmiljön men metoderna är i sig resursspecifika.

Klienter till dessa IWorkbenchPage.openEditor-metoder ska i stället anropa motsvarande publika statiska metoder som deklareras i klassen org.eclipse.ui.ide.IDE (i insticksprogrammet org.eclipse.ui.ide).

Klienter till dessa IWorkbenchPage.openSystemEditor(IFile)-metoder ska konvertera IFile till en IEditorInput med den nya FileEditorInput(IFile) och sedan anropa openEditor(IEditorInput, sträng)-metoden. Du ska med andra ord skriva om page.openSystemEditor(fil) som page.openEditor(new FileEditorInput(fil), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Obs! Klienter som använder redigerar-ID IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID måste överföra en redigerarinmatning som implementerar org.eclipse.ui.IPathEditorInput (vilket FileEditorInput gör).

Obs! Detta är en av de inkompatibiliteter som inte påverkar hur binära 2.1-insticksprogram körs av Eclipse 3.0. I Eclipse 3.0 finns en kompatiblitetsmekanism för binär runtime som garanterar att befintliga binära 2.1-insticksprogram som använder någon av de borttagna openEditor- och openSystemEditor-metoderna fortsätter att fungera på samma sätt som i 2.1, trots ändringen i API:et. (De borttagna metoderna är i själva verket "tillbakalagda" i fragmentet org.eclipse.ui.workbench.compatibility.)

7. Redigerare gå till markör

Följande metod togs bort från gränssnittet org.eclipse.ui.IEditorPart. IEditorPart deklareras i den allmänna arbetsmiljön men metoden är i sig resursspecifik.

Motsvarande metoder togs också bort från de klasser i paketet org.eclipse.ui.part som implementerar IEditorPart, dvs. EditorPart, MultiEditor, MultiPageEditorPart och MultiPageEditor. 

Klienter som anropar denna metod bör i stället testa om redigerardelen implementeras eller anpassas till org.eclipse.ui.ide.IGotoMarker (i insticksprogrammet org.eclipse.ui.ide) och, om så är fallet, anropa gotoMarker(IMarker). IDE-klassen har en bekvämlighetsmetod för detta: IDE.gotoMarker(redigerare, markör).

Klienter som implementerar en redigerare som kan placera sig själv baserat på IMarker-information, bör implementeras eller anpassas till org.eclipse.ui.ide.IGotoMarker.

Eftersom IGotoMarkers enda metod är gotoMarker(IMarker) och den har samma signatur och specifikation som den gamla IEditorPart.gotoMarker(IMarker), kan befintliga redigerarimplementeringar anpassas till ändringen helt enkelt genom att IGotoMarker inkluderas i implementeringsklausulen i klassdefinitionen.

Ett binärt 2.1-insticksprogram med kod som anropar denna metod får ett klasslänkundantagsfel när det körs i en Eclipse 3.0-standardkonfiguration.

8. Startprogram för redigerare

Startprogramgränssnittet för redigerare, interface org.eclipse.ui.IEditorLauncher, implementeras av insticksprogram som bidrar med externa redigerare. Följande metod har tagits bort från detta gränssnitt. IEditorLauncher deklareras i den allmänna arbetsmiljön men metoden är i sig resursspecifik.

Har ersatts av

Klienter som anropar IEditorLauncher.open(fil) ska i stället anropa IEditorLauncher.open(file.getLocation()). Klienter som implementerar detta gränssnitt ska ersätta (eller utvidga) implementationen av open(IFile) med open(IPath).

Ett binärt 2.1-insticksprogram med kod som anropar denna metod får ett klasslänkundantagsfel när det körs i en Eclipse 3.0-standardkonfiguration.

9. Redigerare för registret

Följande metoder har tagits bort från gränssnittet org.eclipse.ui.IEditorRegistry. IEditorRegistry deklareras i den allmänna arbetsmiljön men metoderna är i sig resursspecifika.

Klienter som anropar getEditors(fil) eller getImageDescriptor(fil) bör anropa de "sträng"-ekvivalenta metoderna: Klienter som anropar setDefaultEditor(IFile-fil, strängredigerar-ID) och getDefaultEditor(IFile-fil) ska i stället anropa de motsvarande publika statiska metoder som deklareras i klassen org.eclipse.ui.ide.IDE (i insticksprogrammet org.eclipse.ui.ide): Även API-kontraktet för metoden IEditorRegistrygetDefaultEditor() har ändrats. Metoden, som nu också är utkommenterad, returnerar alltid redigerarbeskrivningen för systemets externa redigerare. Ändringen påverkar klienter som antar att den standardredigerare som returnerades är en textredigerare.

Det finns nya konstanter som motsvarar identifierarna för systemets externa redigerare och systemets på plats-redigerare (SYSTEM_EXTERNAL_EDITOR_ID och SYSTEM_INPLACE_EDITOR_ID). Dessa två redigerare kräver en redigerarinmatning som implementeras eller anpassas till org.eclipse.ui.IPathEditorInput. Observera att beskrivaren för på plats-redigeraren inte existerar i Eclipse-konfigurationer som inte stöder på plats-redigering.

10. Hjälpregister för arbetsmiljömarkör

Följande metod togs bort från gränssnittet org.eclipse.ui.IWorkbench. IWorkbench deklareras i den allmänna arbetsmiljön men metoden är i sig resursspecifik.

Klienter till IWorkbench.getMarkerHelpRegistry() bör i stället anropa den publika statiska metoden org.eclipse.ui.ide.IDE.getMarkerHelpRegistry() (i insticksprogrammet org.eclipse.ui.ide).

Ett binärt 2.1-insticksprogram med kod som anropar denna metod får ett undantagsfel när det körs i en Eclipse 3.0-standardkonfiguration.

11. Dokumentprovider för textredigerare

För att org.eclipse.ui.texteditor.AbstractTextEditor ska bli oberoende av IFile, introducerar org.eclipse.ui.texteditor.AbstractDocumentProvider konceptet med en dokumentprovideråtgärd (DocumentProviderOperation) och en dokumentprovideråtgärdskörare (IRunnableContext). Vid begäran om återställning, spara eller synkronisera, skapar AbstractDocumentProvider dokumentprovideråtgärder och använder åtgärdsköraren för att köra dem. Det körbara sammanhanget kan tillhandahållas av underklasser via getOperationRunner-metoden. Nedan visas en översikt över de ändringar som klienter måste anpassas till:

Underklassen org.eclipse.ui.editors.text.StorageDocumentProvider till AbstractDocumentProvider implementerar getOperationRunner-metoden som alltid returnerar null. Detta betyder att underklasser till StorageDocumentProvider inte påverkas av denna ändring.

Underklassen org.eclipse.ui.editors.text.FileDocumentProvider till StorageDocumentProvider implementerar getOperationRunner-metoden som returnerar en IRunnableContext för körning av den angivna DocumentProviderOperations i en WorkspaceModifyOperation. Övriga ändringar i FileDocumentProvider är:

12. Textredigerare

Ändringar i org.eclipse.ui.texteditor.AbstractTextEditor:

Underklassen org.eclipse.ui.texteditor.StatusTextEditor till AbstractTextEditor tillhandahåller predikatmetoden isErrorStatus(IStatus). Underklasser kan åsidosätta för att avgöra om en given status ska anses som ett fel eller inte.

Ändringar i org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:

13. Konsollöst stöd för anteckningar

Som en del av introduktionen av konsollöst stöd för anteckningar har följande ändringar i Annotation gjorts:

        org.eclipse.jface.text.source.Annotation 
        org.eclipse.jface.text.source.AnnotationModel 
        org.eclipse.jface.text.source.AnnotationModelEvent 
        org.eclipse.jface.text.source.IAnnotationModel 
        org.eclipse.jface.text.source.IAnnotationModelListener 
        org.eclipse.jface.text.source.IAnnotationModelListenerExtension

14. Konsolvyn

Eclipse 3.0 har ett nytt allmänt konsolstöd. Den allmänna konsolen är tillgänglig via Fönster > Visa vy > Grundläggande > Konsol och används vid felsökning i Eclipse och av Ant-integrationen.

Vy-ID för konsolen har ändrats från org.eclipse.debug.ui.ConsoleView till org.eclipse.ui.console.ConsoleView. 2.1-insticksprogram som öppnar konsolen i programkoden kommer inte att lyckas, eftersom den gamla vyn inte längre existerar.

15. Lyssnare för Java-brytpunkt

I version 3.0 är returtyperna för metoderna org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) och installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) ändrade från boolesk till heltal för att lyssnare ska kunna rösta "DONT_CARE". I tidigare versioner än 3.0 kunde lyssnare endast rösta "SUSPEND" eller "DONT_SUSPEND" när en brytpunkt anträffades och "INSTALL" eller "DONT_INSTALL" när en brytpunkt skulle installeras. I version 3.0 kan lyssnare även rösta "DONT_CARE" för alla dessa meddelanden. Detta gör det möjligt för lyssnare att rösta i situationer som de tycker är viktiga. För "breakpointHit"-meddelanden kommer brytpunkten att stoppas om någon lyssnare röstar "SUSPEND" eller om alla lyssnare röstar "DONT_CARE". Brytpunkten stoppas inte om minst en lyssnare röstar "DONT_SUSPEND" och ingen lyssnare röstar "SUSPEND". Ungefär detsamma gäller för "installingBreakpoint"-meddelanden. Brytpunkten installeras om någon lyssnare röstar för en installation eller om alla lyssnare röstar "DONT_CARE". Brytpunkten installeras inte om minst en lyssnare röstar "DONT_INSTALL" och inga lyssnare röstar "INSTALL". I normala fall bör implementeringsfunktioner returnera DONT_CARE om de inte har en stark om något. Om någon till exempel röstar "SUSPEND" kommer alla andra lyssnares "DONT_SUSPEND"-röster att åsidosättas.

IJavaBreakpointListener-gränssnittet är implementerat av klienter som skapar eller reagerar på brytpunkter i Java-kod. Det finns troligtvis inte många klienter utanför JDT. Spara den som rapporterade problemet (fel 37760) som denna ändring åtgärdar. Detta är en brytande ändring för befintlig kod som implementerar IJavaBreakpointListener-gränssnittet. Koden måste ändras så att den returnerar ett riktigt heltalsvärde innan den kan kompileras och köras i version 3.0.

16. Urklippsaccess i användargränssnittstråd

Före version 3.0 var metoderna i SWT-klassen org.eclipse.swt.dnd.Clipboard tillåtna att köra i andra trådar än användargränssnittstråden. Detta misstag resulterade i fel på GTK där operativsystemet kräver att alla urklippsåtgärder utfördes i användargränssnittstråden. Misstaget uppdagades inte tidigare eftersom många tillämpningar är enkeltrådiga och framförallt testas i Windows. För att urklipps-API:et ska fungera på många plattformar har alla specifikationer och implementeringar i version 3.0 för urklipps-API-metoderna ändrats så att de orsakar ett SWT-undantag (ERROR_THREAD_INVALID_ACCESS) om de anropas från en icke-användargränssnittstråd. Urklippstjänster tillhandahålls automatiskt av Eclipse-komponenter, bland annat i textredigeraren, vilket isolerar många klienter från den här ändringen. Befintlig kod som inte direkt använder Urklipp bör garantera att API-metoderna anropas på rätt tråd genom att Display.asyncExec eller syncExec används där det passar, så att åtkomsten flyttas till användargränssnittstråden.

17. Tangentnedtryckningshändelser

I version 3.0 rapporterar SWT tangentnedtryckningshändelser innan arbetet är klart i operativsystemet. Detta är mycket tidigare än det var i äldre versioner än 3.0. Ändringen gjordes för att ge stöd åt tangentbindningar i Eclipse. Det kräver att tangenthändelsen snappas upp innan engränssnittskontroll hinner bearbeta tecknet. Följderna av denna ändring är synliga i kod som hanterar org.eclipse.swt.SWT.KeyDown-lågnivåhändelser direkt. Detta betyder till exempel att när en lyssnare i en textgränssnittskontroll tar emot en tangentnedtryckningshändelse kommer inte gränssnittskontrollsinnehållet (getText()) att innehålla den tangent som just trycktes ned (i äldre versioner än 3.0 gjorde den det). Det rekommenderade sättet att få all text från gränssnittskontrollen, inklusive den aktuella tangenten, är att hantera SWT.Modify- eller SWT.Verify-händelserna som ligger på en högre nivå i stället för SWT.KeyDown-lågnivåhändelsen. Kod som redan gör på detta vis påverkas inte av ändringen.

18. Tabbförflyttning mellan anpassade kontroller

I äldre versioner än 3.0, när fokus var i SWT-klassen org.eclipse.swt.widgets.Canvas eller i någon av dess underklasser (inklusive anpassade gränssnittskontroller), utlöste Ctrl+Tab, Skift+Tab, Ctrl+PgUp eller Ctrl+PgDn automatisk förflyttning till nästa/föregående gränssnittskontroll utan att någon händelse rapporterades. Beteendet var inte specificerat och följde inte regeln om att arbetsytor ser alla tangenter som trycks ned när de har fokus. Det korrekta sättet att hantera förflyttning är att registrera en förflyttningslyssnare. I version 3.0 ändrades standardbeteendet så att arbetsytan nu ser tangenthändelserna Ctrl+Tab, Skift+Tab, Ctrl+PgUp och Ctrl+PgDn, i stället för förflyttningen. Om du använder en arbetsyta som den är eller definierar underklass till en arbetsyta måste du se till att registrera en förflyttningslyssnare.

19. Ordning för markeringshändelser i SWT-tabeller och trädgränssnittskontroller

Musmarkeringar av objekt i SWT-klasserna org.eclipse.swt.widgets.Table och Tree genererar händelsesekvensen MouseDown-Selection-MouseUp på samma sätt i alla operativsystem. På liknande sätt genererar tangentbordsmarkeringar händelsesekvensen KeyDown-Selection-KeyUp på samma sätt i alla operativsystem. I äldre versioner än 3.0 var händelseordningen inte densamma. Motif och Photon skiljde sig åt från resten genom att alltid rapportera Selection-händelsen först, dvs. Selection-MouseDown-MouseUp eller Selection-KeyDown-KeyUp. I version 3.0 har händelseordningen för Motif och Photon ändrats så att den nu är densamma som för de övriga operativsystemen. Befintlig kod som fungerade utan problem i {Windows, GTK} och i {Motif, Photon} påverkas troligtvis inte. Det kan dock vara en bra ide att kontrollera koden så att den inte förlitar sig på en felaktig händelseordning.

20. Ny allvarlighetsgrad i statusobjekt

org.eclipse.core.runtime.IStatus har en ny konstant för allvarlighetgrad, IStatus.CANCEL, som kan användas när annullering ska indikeras. Procedurer som anropar IStatus.getSeverity() och förlitar sig på att uppsättningen av möjliga allvarlighetsgrader är begränsade till IStatus.OK, INFO, WARNING och ERROR påverkas av detta tillägg. Procedurer som anropar getSeverity bör få koden uppdaterad så att den nya allvarlighetsgraden inkluderas.

21. Byggrelaterade meddelanden om resursändringar

I Eclipse 3.0 finns nu automatiska byggen av arbetsytan i en bakgrundestråd. Detta kräver en ändring av API-kontraktet till org.eclipse.core.resources.IResourceChangeEvent. Kontraktet till IResourceChangeEvent garanterade tidigare följande händelseordning för alla ändringar av arbetsytan:

  1. Händelsemeddelande PRE_DELETE eller PRE_CLOSE om tillämpligt
  2. Utför åtgärden
  3. Händelsemeddelande PRE_AUTO_BUILD
  4. Om automatiskt bygge är aktiverat, utför inkrementellt arbetsytebygge
  5. Händelsemeddelande POST_AUTO_BUILD
  6. Händelsemeddelande POST_CHANGE

Nu när automatiskt bygge körs i bakgrunden finns det inte längre någon garanti för tidvisa relationer mellan AUTO_BUILD-händelser och POST_CHANGE-händelsen. I Eclipse 3.0 har steg 3-5 tagits bort från åtgärden i strukturen ovan. Resultatet blir följande:

  1. Händelsemeddelande PRE_DELETE eller PRE_CLOSE om tillämpligt
  2. Utför åtgärden
  3. Händelsemeddelande POST_CHANGE

Med jämna mellanrum kommer plattformen att utföra en byggåtgärd av arbetsytan i bakgrunden. Detta inträffar oavsett om automatiskt bygge är aktiverat eller inte. Exakt när detta bygge inträffar anges inte. Byggåtgärdens struktur kommer att se ut så här:

  1. Händelsemeddelande PRE_BUILD (PRE_BUILD är det nya namnet på PRE_AUTO_BUILD)
  2. Om automatiskt bygge är aktiverat, utför inkrementellt arbetsytebygge
  3. Händelsemeddelande POST_BUILD (POST_BUILD är det nya namnet på POST_AUTO_BUILD)
  4. Händelsemeddelande POST_CHANGE

Referenspunkten för de deltan som tas emot av automatiska bygglyssnare skiljer sig från den som efterändringslyssnare tar emot. Bygglyssnare tar emot meddelanden om alla ändringar sedan den senaste byggåtgärden. Efterändringslyssnare tar emot ett delta som beskriver alla ändringar sedan det senaste efterändringsmeddelandet. Den nya strukturen behåller tre egenskaper hos resursändringslyssnare som har varit sanna sedan Eclipse 1.0:

Det finns dock vissa viktiga skillnader med denna metod. I äldre versioner än Eclipse 3.0 anropades alltid automatiska bygglyssnare före POST_CHANGE-lyssnare. Därför var alltid deltan som togs emot av automatiska bygglyssnare en delmängd av deltan som togs emot av POST_CHANGE-lyssnare. Denna relation har nu i allt väsentligt omvänt. Automatiska bygglyssnare tar emot deltan som är en uppsättning med alla deltan som har skickats till POST_CHANGE-lyssnare sedan slutet av det senaste bakgrundsbygget. På samma sätt som tidigare kan automatiska bygglyssnare ändra arbetsytan, medan efterändringslyssnare inte kan göra det.

Det är inte längre sant att AUTO_BUILD-händelselyssnare meddelas vid slutförandet av en ändringsåtgärd av arbetsytan. Klientkod som registrerar resursändringslyssnare med IWorkspace.addResourceChangeListener(IResourceChangeListener) påverkas troligtvis inte av den är ändringen eftersom AUTO_BUILD-händelser aldrig har rapporterats till dessa lyssnare. Klienter som använder IWorkspace.addResourceChangeListener(IResourceChangeListener,int) och anger en händelsemask som inkluderar AUTO_BUILD-händelser, kan dock gå sönder av den här ändringen om de förutsätter när automatiska bygglyssnare kör eller i vilken tråd de körs. Om en automatisk bygglyssnare till exempel uppdaterar en domänmodell för att återspegla ändringar av arbetsytan kanske inte denna uppdatering har inträffat när ändringsåtgärden av arbetsytan returneras. Det kan vara värt att nämna att endast kod på användargränssnittsnivå kan påverkas på detta sätt. Kod på kärnnivå som anropas via API kan anropas inom omfånget av en IWorkspaceRunnable. Därför kan koden aldrig veta när resursändringslyssnare anropas. Problemet kan lösas genom att POST_CHANGE används i stället för bygglyssnare om meddelandet måste visas innan åtgärden slutförs.

22. Mellanliggande meddelanden vid åtgärder på arbetsytan

Det är inte längre säkert att alla resursändringar som inträffar under det dynamiska omfånget som hör till en IWorkspaceRunnable samlas upp i ett enda meddelande. Mekanismen kan fortfarande användas vid uppsamling av ändringar för att onödiga byggen och meddelanden ska undvikas, men plattformen kan nu skicka meddelanden under åtgärden. Denna API-kontraktsändring med troligtvis inget problem för befintliga klienter. Det är detsamma som att plattformen anropar IWorkspace.checkpoint periodvis under en lång åtgärdskörning. Anledningen till ändringen är att det nu är möjligt att flera trådar samtidigt ändrar arbetsytan. När en tråd är klar med ändringar av arbetsytan krävs ett meddelande för att svarsproblem inte ska uppstå, även om den andra åtgärden ännu inte har slutförts. Denna ändring gör det också möjligt för användare att börja arbeta på en resursuppsättning innan åtgärden slutförs. En användare kan till exempel börja bläddra bland filer i ett projekt som fortfarande håller på att checkas ut. Den nya metoden IWorkspace.run(IWorkspaceRunnable, ISchedulingRule, heltal, IProgressMonitor) har en valfri flagga, AVOID_UPDATE, som åtgärder kan använda som ett tips till plattformen om periodiska uppdateringar är önskvärda.

23. Hanterarutökningar för URL-strömmar

Vad som påverkas: Insticksprogram som bidrar med utökningar till utökningspunkten org.eclipse.core.runtime.urlHandlers.

Beskrivning: Kontraktet för utökningspunkten org.eclipse.core.runtime.urlHandlers har ändrats så att den använder URL-strömhanteringstjänsten som tillhandahålls av OSGi. OSGi-stödet är överlägset det som finns i Eclipse 2.1 och hanterar dynamiska hanterare på rätt sätt. På grund av olika designfrågor med Javas URL-grundhanteringsmekanism, måste URLStreamHandlers som är registrerade med OSGi-hanterartjänsten implementera org.osgi.service.url.URLStreamHandlerService.

Åtgärd som krävs: Förut behövde hanteringsklassen implementera java.net.URLStreamHandler och utöka utökningspunkten urlHandlers. Utökningspunkten stöds inte längre och hanteraren måste uppdateras så att den implementerar gränssnittet org.osgi.service.url.URLStreamHandlerService. SGi-ramverket tillhandahåller en abstrakt grundklass (org.osgi.service.url.AbstractURLStreamHandlerService) som på ett enkelt sätt kan delas in i underklasser för att uppfylla detta.

I stället för att registrera hanteraren med en utökningspunkt måste nu insticksprogrammen göra detta genom att registrera sin hanterare som en tjänst. Exempel:

    Hashtable properties = new Hashtable(1);
    properties.put(URLConstants.URL_HANDLER_PROTOCOL, new String[] {MyHandler.PROTOCOL});
    String serviceClass = URLStreamHandlerService.class.getName();
    context.registerService(serviceClass, new MyHandler(), properties);

24. Inläsningsordning för klasser

Vad som påverkas: Insticksprogram som tillhandahåller paket som även tillhandahålls av andra insticksprogram. Ett begränsat antal insticksprogram påverkas av denna ändring. En del av de insticksprogram som drabbas kommer att vinna på detta (se nedan).

Beskrivning: I Eclipse 2.x söker klassinläsningsfunktioner efter klasser i följande ordning: konsultera (1) den överordnade klassinläsningsfunktionen (i praktiken är detta Javas startklassinläsningsfunktion), därefter (2) innehållet i sin egen klassökväg och slutligen (3) alla nödvändiga filer i den ordning de har deklarerats. I OSGi finns en optimering för denna modell. I denna metod konsulterar en klassinläsningsfunktion (1) den överordnade klassinläsningsfunktionen (i praktiken Javas startklassinläsningsfunktion), därefter antingen (2a) en enstaka nödvändig fil som är känd att innehålla klasser i paketet som efterfrågas eller (2b) poster i sin egen klassökväg för den sökta klassen.

Klassinläsningsfunktionen avgör om den ska konsultera sig själv eller nödvändiga filer baserat på importerade och obligatoriska paket. Information räknas fram med hjälp av innehållet i insticksprogrammet om det gäller traditionella insticksprogram eller så tas den fram direkt om det gäller insticksprogram med explicita OSGi-paketmanifest. Oavsett hur informationen tas fram är det känt tidigare vilka klassinläsningsfunktioner som tillhandahåller klasserna för vilka paket. Detta medför prestandavinster samt en lösning på problemet med flera nödvändiga filer som bidrar till samma klasser.

Ta till exempel omständigheten med Xerces och Xalan, som åda innehåller olika klasser från org.xml-paket. Med det första tillvägagångssättet kommer insticksprogrammet Xerces att se sin egen kopia av dessa klasser, medan insticksprogrammet Xalan inte kommer att göra det. Eftersom dessa insticksprogram måste kommunicera uppstår ClassCastExceptions-fel. Med det andra tillvägagångssättet kommer endast en av de två insticksprogrammen att bidra med de duplicerade klasserna. Båda insticksprogrammen kommer att se samma kopior.

Åtgärd som krävs: Vilken åtgärd som krävs beror på detaljerna i det specifika användningsfallet. Utvecklare som påverkas får granska sina klassökvägar och lösa eventuella konflikter som kan uppstå.

25. Skyddsdomän för klassinläsare inte angiven

Vad som påverkas: Insticksprogram som förväntar sig att en skyddsdomän till sin klassinläsningsfunktion alltid anges.

Beskrivning: I klassinläsningsfunktioner till Eclipse 2.1-insticksprogram där java.security.SecureClassloaders alltid hade en angiven skyddsdomän. I Eclipse 3.0 utökar inte klassinläsarfunktioner SecureClassloader. De anger endast skyddsdomänen om Java-säkerhet är aktiverad (detta är inte normalfallet).

Åtgärd som krävs: Vilken åtgärd som krävs beror på i vilket scenario som insticksprogrammet använder skyddsdomänen.

26. PluginModel-objektsomvandling

Vad som påverkas: Insticksprogram som typomvandlar objekt av typen org.eclipse.core.runtime.IPlugin* till org.eclipse.core.runtime.model.Plugin*Model. Även om relationen mellan dessa gränssnitt och modellklasserna inte är specificerade i Eclipse 2.1 API, meddelar vi uttryckligen denna ändring på grund av att vi har hittat förekomster av insticksprogram som är beroende av denna relation i 2.1-implementeringen.

Beskrivning: I Eclipse API:et finns flera gränssnitt (till exempel IPluginDescriptor) och så kallade "modellklasser" (till exempel PluginDescriptorModel) som är relaterade till insticksprogram och insticksprogramregistreringen. I. Eclipse 2.1-implementeringen händer det att modellklasserna implementerar relevanta gränssnitt. I den nya OSGi-baserade runtimemodulen har insticksprogramregistret omarbetats för att en uppdelning mellan insticksprogrammens klassinläsning och nödvändiga filer och mellan utökningar och utökningspunkter ska tillåtas. Runtimemodulen för Eclipse 3.0 kan inte upprätthålla implementeringsrelationen som finns i version 2.1.

Åtgärd som krävs: Koden i insticksprogram som är beroende av denna icke-API-relation måste skrivas om beroende på användning. Mer information om det här finns i avsnittet med rekommenderade ändringar i det här dokumentet och i Javadoc för relaterade klasser och metoder.

27. Implementering av ILibrary ofullständig

Vad som påverkas: Insticksprogram som använder org.eclipse.core.runtime.ILibrary.

Beskrivning: Den nya runtimemodulen underhåller posterna i klassökvägen på ett annat och inkompatibelt sätt, till skillnad från Eclipse. Som ett resultat kan inte kompatibilitetslagret modellera den underliggande OSGi-strukturen som ILibrary-objekt på rätt sätt. Runtimemodulens kompatibilitetsstöd skapar ILibrary-objekt men måste anta standardvärden för allt utom bibliotekets sökväg.

Åtgärd som krävs: Användare av ILibrary bör överväga att accessa önskade huvudvärden (till exempel Bundle-Classpath) ur lämpligt paket (se Bundle.getHeaders()) och använda hjälpklassen ManifestElement för att tolka posterna. Mer detaljer finns i klass-Javadoc.

28. Ogiltiga antaganden beträffande URL-formatet

Vad som påverkas: Insticksprogram som gör antaganden om sin installationsstruktur, plats och layouten på det lokala filsystemet.

Beskrivning: Metoder som till exempel IPluginDescriptor.getInstallURL() returnerar URL-adresser i ett visst format. Trots att formatet är ospecificerat gör olika insticksprogram antaganden baserat på den aktuella implementationen. Insticksprogrammen kan till exempel förvänta sig att få en file: URL och använda URL.getFile() och använda java.io.File-manipulation på resultatet. Fram till nu har detta varit ett fungerande, men ömtåligt tillvägagångssätt. Om till exempel ett insticksprogram installeras på en webbserver returneras troligtvis en http: URL. Den nya Eclipse 3.0-runtimemodulen är ännu mer flexibel och öppnar upp för fler möjligheter för körningskonfigurationer (till exempel att underhålla insticksprogram i JAR-filer i stället för i en katalogstruktur). Den nya OSGi-baserade runtimemodulen delar i själva verket inte upp 2.1-API:et, utan visar fler fall där antaganden som görs i aktuella insticksprogram är felaktiga.

Åtgärd som krävs: Utvecklare av insticksprogram bör kontrollera att den information som de behöver åtkomst till är tillgänglig via getResource() (och finns i klassökvägen) eller använda relevant API vid access av innehållet i ett insticksprogram (till exempel Bundle.getEntry(String)).

29. BootLoader-metoder flyttade/borttagna

Vad som påverkas: Icke-insticksprogramkod som anropar vissa metoder från klassen org.eclipse.core.boot.BootLoader.

Beskrivning: De statiska metoderna BootLoader.startup(), shutdown() och run() har flyttats till org.eclipse.core.runtime.adaptor.EclipseStarter som tillhör OSGi-ramverket. Detta API är gränssnittet mellan main() i startup.jar och OSGi-ramverket/Eclipse runtimemodulen. Omstruktureringen av runtimemodulen tillät inte att dessa metoder var kvar i BootLoader. Den gamla BootLoader-klassen finns nu i runtimemodulens kompatibilitetslager och är utkommenterad. De flyttade metoderna utför ingenting.

Det finns ingen ersättare till den gamla BootLoader.getRunnable() eftersom runtimemodulen inte längre stöder förvärv av enstaka tillämpningar. I stället får användaren ange tillämpningen när de startar plattformen.

Åtgärd som krävs: I normala fall används det här API:et av väldigt få (det går inte att använda inifrån ett Eclipse-insticksprogram). Om API:et används måste koden anpassas så att motsvarande metoder används i EclipseStarter.

30. Export av insticksprogram inkluderar inte insticksprogrammets JAR-filer automatiskt

Vad som påverkas: Alla insticksprogram.

Beskrivnings: I Eclipse 2.1 behövde inte raden bin.includes i ett insticksprograms build.properties innehålla listan med JAR-filer från insticksprogrammets biblioteksdeklaration i filen plugin.xml. JAR-filerna lades till ändå. I Eclipse 3.0 är listan med filer i avsnittet bin.includes i build.properties en fullständig lista som måste innehålla alla filer som utvecklaren av insticksprogrammet tänker använda vid byggen eller export.

Åtgärd som krävs: Kontrollera att raden bin.includes i filen build.properties innehåller alla JAR-filer som är med i filen plugin.xml.

31. Exportera om runtime-API

Vad som påverkas: Insticksprogram som visar det API som innehåller element från det ändrade runtime-API:et.

Beskrivning: Olika insticksprogram visar API:et som innehåller element från runtime-API:et. Med de ändringar som tas upp här av Eclipse 3.0-runtime-modulen måste klientinsticksprogram omvärdera sin användning av runtime-API:et i sitt eget API.

Åtgärd som krävs: Detta scenario är ovanligt eftersom mycket lite av Eclipses runtime-API ändras. Beroende på scenario måste kanske klienter ändra sina API:er eller fortsätta förlita sig på kompatibilitetslagret.

32. Insticksprogrammets tolkningsmetoder på plattformen

Vad som påverkas: Insticksprogram som använder org.eclipse.core.runtime.Platform.parsePlugins(..., Factory).

Beskrivning: Metoden org.eclipse.core.runtime.Platform.parsePlugins(..., Factory) har flyttats. API:et som är associerat till argumentet Factory har flyttats från insticksprogrammet org.eclipse.core.runtime upp till insticksprogrammet org.eclipse.core.runtime.compatibility (som är beroende av runtime-insticksprogrammet). Som ett resultat av detta har tolkningsmetoden också flyttats.

Åtgärd som krävs: Användare av denna metod bör använda samma metod på klassen org.eclipse.core.runtime.model.PluginRegistryModel.

33. Insticksprogrammets bibliotek anges av fragment

Vad som påverkas: Insticksprogram som anger kod i sin klassökväg men inte tillhandahåller koden (JAR-filen tillhandahålls av ett fragment, till exempel i insticksprogrammet org.eclipse.swt).

Beskrivning: Den nya runtimemodulen konverterar plug.xml-filer till manifest.mf-filer. Detta görs i en helt mekanisk omvandling. En analys av de JAR-filer som listas och tillhandahålls av insticksprogrammet görs också. I de fall där ett insticksprogram anger en JAR-fil i klassökvägen men inte tillhandahåller filen, finns det ingen kod att analysera och konverteraren av insticksprogram kan inte skapa en riktig manifest.mf-fil.

Åtgärd som krävs: De som tillhandahåller sådana insticksprogram måste antingen ändra så att rätt JAR-fil inkluderas i insticksprogrammet eller skicka med en META-INF/MANIFEST.MF-fil med insticksprogrammet. Detta kan göras med hjälp av PDE som skapar en grundläggande manifest-fil och sedan lägger till ett passande Provide-Package-huvud.

34. Ändringar av byggskript

Vad som påverkas: Skript (till exempel Ant build.xml-filer) som definierar klassökvägar som innehåller runtime-relaterade JAR-filer och klasskataloger.

Beskrivning: Den nya runtimemodulen innehåller ett antal nya insticksprogram och JAR-filer. Introduktionen av dessa gjordes på grund av omfaktoriseringen av runtimemodulen till konfigurerbara delar. I de flesta runtimesituationer märks inte dessa ändringar. Men om du har ett anpassat build.xml-skript(eller liknande) som nu kompilerar koden mot org.eclipse.core.runtime, måste du uppdatera dem för att de ska fungera felfritt. Ett normalt skript innehåller en klassökvägspost i en <javac>-åtgärd som refererar till insticksprogrammet org.eclipse.core.runtime på följande sätt:

    ../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar

Runtime-insticksprogrammet kommer fortsättningsvis att innehålla mycket av den ursprungliga runtimekoden. Olika delar av runtimemodulen som endast är där för kompatibilitetsskäl finns dock i ett kompatibilitetsinsticksprogram (org.eclipse.core.runtime.compatibility). Det mesta av runtimekoden finns i en insticksprogramsamling (org.eclipse.osgi.*).

Åtgärd som krävs: Utvecklare bör lägga till nedanstående poster för att undvika kompileringsfel. Även om en komplett uppsättning med JAR-filer visas nedan kräver en normalanvändning endast en del av klassökvägen vid kompilering. Som vanligt är inkluderingen av /bin-katalogerna godtycklig. Posterna visas i logiska grupper efter tillhandahållande insticksprogram:

Dessutom kan följande JAR-filer behövas i vissa fall:

När du uppdaterar sådana skript bör du ta tillfället i akt och rensa (dvs. ta bort) referenser till org.eclipse.core.boot. Insticksprogrammet är inaktuellt och innehåller inte längre någon kod. Posterna kan vara kvar i klassökvägen men har inget syfte och bör tas bort. Leta efter och ta bort:

    ../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar

35. Ändringar av Ant-åtgärder för PDE-byggen

Vad som påverkas: Skript (till exempel Ant build.xml-filer) som använder eclipse.buildScript-åtgärden.

Beskrivning: PDE Build introducerar en ny egenskap för åtgärden eclipse.buildScript som styr hur insticksprogrammens byggskript genereras. Detta krävdes när den nya OSGi-baserade runtimemodulen introducerades.

Åtgärd som krävs: Om du vill använda Eclipse 3.0 för att bygga en 2.1-baserad produkt ska du sätta egenskapen "buildingOSGi" i eclipse.buildScript till false (falskt). Exempel:

<eclipse.buildScript ... buildingOSGi="false"/>

36. Ändringar av Ant-åtgärder för eclipse.build

Vad som påverkas: Skript (till exempel Ant build.xml-filer) som använder eclipse.buildScript-åtgärden.

Beskrivning: PDE Build introducerar en ny egenskap för åtgärden eclipse.buildScript som styr hur insticksprogrammens byggskript genereras. Detta krävdes när den nya OSGi-baserade runtimemodulen introducerades.

Åtgärd som krävs: Om du vill använda Eclipse 3.0 för att bygga en 2.1-baserad produkt ska du ange egenskapen "buildingOSGi" i eclipse.buildScript till false (falskt). Exempel:

<eclipse.buildScript ... buildingOSGi="false"/>

37. Ändringar av Ant-åtgärder för eclipse.fetch

Vad som påverkas: Skript (till exempel Ant build.xml-filer) som använder eclipse.buildScript-åtgärden.

Beskrivning: PDE Build ändrade beteendet för eclipse.fetch-åtgärden för att förenkla bygget av Eclipse i ett automatiserat byggformat. Elementformatet stöder nu endast en post åt gången och scriptName ignoreras alltid.

Åtgärd som krävs: Om du hade en lista med poster i märkordet "elements" i ett eclipse.fetch-anrop, sprider du ut dem på flera anrop till eclipse.fetch. Om du brukar ange scriptName bör du observera att det genererade hämtskriptet alltid anropas "fetch_{elementId}". Exempel:

<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>

blir

<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../>
<eclipse.fetch elements="feature@org.eclipse.platform" .../>

38. Ersättning av install.ini

Filen install.ini inkluderas inte längre. I stället används den nya filen config.ini i underkatalogen för konfiguration. Produkter som använder filen install.ini för att ange en primär funktion (till exempel för att tillhandahålla anpassningsinformation) måste i stället ändra i filen config.ini. Förutom det nya filnamnet har nyckelnamnen ändrats.

Värdet på nyckeln feature.default.id i version 2.1 ska sättas till värdet för den nya nyckeln eclipse.product. Värdet för eclipse.application bör sättas till "org.eclipse.ui.ide.workbench".

Slutligen, välkomstbilden i version 2.1 har alltid varit splash.bmp i den anpassade insticksprogrammets katalog. I version 3.0 anges placeringen av välkomstbilden explicit av nyckeln osgi.splashPath i config.ini-filen.