Eclipse ble endret slik at det oppstod inkompatibiliteter mellom 2.1 og 3.0 på måter som påvirker plugin-moduler. De følgende punktene beskriver områdene som ble endret, og de inneholder instruksjoner for migrering av plugin-moduler fra 2.1 til 3.0. Du trenger bare å se her hvis du har problemer med å kjøre plugin-moduler fra 2.1 på 3.0.
Toppteksten for manifestfilene for plugin-moduler (og plugin-fragmenter) er endret slik at den inkluderer en ny linje som identifiserer den riktige versjonen av plugin-manifestet. Før 3.0 hadde ikke plugin-moduler noen av disse <?eclipse ...?>-linjene. Etter 3.0, må de alltid ha en slik linje. Denne endringen er gjort slik at Eclipse-kjøretiden kan pålitelig gjenkjenne plugin-moduler fra før 3.0 som ikke er portert til 3.0, slik at den automatisk kan gi bedre binær kompatibilitet for slike plugin-moduler. Dette er den generelle formen av plugin.xml-filen (fragment.xml likner):
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin ...>
...
</plugin>
Plugin-manifester som er opprettet av PDE 3.0, får automatisk denne formen. Det anbefales at du bruker PDE-verktøyet for plugin-migrering. Det setter automatisk inn den oppgitte linjen i manifestet for plugin-moduler og plugin-fragmenter fra 2.1, og adresserer mange av de andre endringene som beskrives her.
Hvis du tilføyer dette direktivet i en plugin.xml (manuelt eller ved hjelp av PDE), må filen også oppdateres slik at den eksplisitt inneholder plugin-modulene den avhenger av. Før Eclipse 3.0 var for eksempel avhengigheter med org.eclipse.core.runtime og org.eclipse.core.boot implisitt. Med 3.0 er org.eclipse.core.boot ikke lenger nødvendig, og utviklere må velge org.eclipse.core.runtime eller org.eclipse.core.runtime.compatibility (eller ingen av dem) slik det passer.
Merk: Dette er en av inkompatibilitetene som ikke påvirker hvordan binære filer fra 2.1 kjøres av Eclipse 3.0.
Plugin-modulen org.eclipse.ui, som var hoved-plugin for plattformgrensesnittet, har nå bare APIet og utvidelsespunktene for den generiske (det vil si ikke-spesifikke) arbeidsbenken. Valgfri og IDE-spesifikk API og utvidelsespunkter er flyttet til andre plugin-moduler.
Denne endringen virker på to områder: (1) de flyttede org.eclipse.ui-utvidelsespunktene har nye utvidelsespunkt-IDer, og (2) listen over nødvendige plugin-moduler er endret.
Org.eclipse.ui-utvidelsespunktene i den følgende tabellen er flyttet til andre plugin-moduler, som gjør at utvidelsespunkt-IDene blir endret. Hvis en eksisterende plugin-modul oppgir en utvidelse for de flyttede utvidelsespunktene, må referansen i "point"-attributtet for <extension>-elementet i plugin-manifestfilen endres slik at det refererer til de tilsvarende nyes utvidelsespunkt-IDer. PDE-verktøyet for plugin-migrering utfører disse oppryddingene.
Merk: Dette er en av inkompatibilitetene som ikke påvirker hvordan binære plugin-moduler for 2.1 kjøres av Eclipse 3.0. Eclipse 3.0-kjøretiden oppdager automatisk plugin-moduler som er eldre enn 3.0 (på grunn av fraværet av den nevnte <?eclipse version="3.0"?>-linjen i plugin-manifestet), og kompenserer automatisk for disse endringene i utvidelsespunkter og plugin-avhengigheter.
Gammel utvidelsespunkt-ID |
Ny utvidelsespunkt-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.editors.markerUpdaters |
org.eclipse.ui.documentProviders | org.eclipse.ui.editors.documentProviders |
org.eclipse.ui.workbench.texteditor. markerAnnotationSpecification |
org.eclipse.ui.editors.markerAnnotationSpecification |
Den følgende tabellen viser API-pakkene som tidligere ble oppgitt av plugin-modulen org.eclipse.ui, som nå er flyttet til andre plugin-moduler. (Navnene på API-pakkene, klassene, feltene og metodene er ikke endret.) I noen tilfeller er API-pakkene nå delt på mer enn en plugin-modul. Siden de synlige API-klassene for en hvilken som helst gitt plugin-modul bestemmes av denne plugin-modulens liste over nødvendige plugin-moduler, kan disse endringene kreve justering av "<requires>"-elementer i et eksisterende plugin-manifest for å få tilbake tilgangen til API-klassen.
Denne endringen påvirker bare plugin-moduler som avhenger av plugin-modulen org.eclipse.ui (det vil si inkluderer <import plugin="org.eclipse.ui"/> i <requires>-delen av plugin-manifestet). Ingen andre plugin-moduler blir påvirket. Hvis det blir påvirket, kan det være nødvendig å endre <import>-elementet, eller legge til ekstra <import>-elementer, slik at alle API-klassene plugin-modulen trenger, er i omfanget. Det anbefales at plugin-modulene bare oppgir avhengigheter med de plugin-modulene de faktisk bruker. Hvis unødvendige avhengigheter tas med, reduseres kjøretidsytelsen, fordi Java-klasselasteren må søke etter klasser i alle avhengigheter. (PDE-verktøyet for plugin-migrering retter avhengighetene, og hjelper til med å fastsette et minimumssett.)
API-pakke |
Plugin-modul for 2.1 |
Tilsvarende plugin-modul(er) for 3.0 |
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 |
Plattformkjøretiden for Eclipse 3.0 er basert på OSGi, noe som gjør det nødvendig å endre strukturen for de to plugin-modulene for plattformkjøretiden, org.eclipse.core.runtime og org.eclipse.core.boot.
En ny org.eclipse.core.runtime.compatibility-plugin utgjør en bro mellom de gamle og det nye APIene, og den er den nye plasseringen av mange av de foreldede APIene som tidligere fantes i org.eclipse.core.runtime og org.eclipse.core.boot. Plattformkjøretidens utvidelsespunkter blir ikke påvirket av omstrukturering.
Når den eksisterende plugin-modulen migreres til 3.0, må plugin-modulens manifest oppdateres slik at det gjenspeiler den nye strukturen i plugin-modulene for Eclipses plattformkjøretid. PDE-verktøyet for migrering av plugin-manifest legger til en avhengighet i org.eclipse.core.runtime.compatibility hvis det er nødvendig.
Vær også oppmerksom på at hvis du merker plugin-modulen som 3.0 (ved hjelp av <?eclipse version="3.0"?>), og plugin-modulen definerer en plugin-klasse, må du enten eksplisitt oppgi <import plugin="org.eclipse.core.runtime.compatibility"/> i plugin-manifestet, eller sikre at plugin-klassen definerer en standardkonstruktør.
Merk: Dette er en av inkompatibilitetene som ikke påvirker hvordan binære plugin-moduler for 2.1 kjøres av Eclipse 3.0. Eclipse 3.0-kjøretiden oppdager automatisk plugin-moduler som er eldre enn 3.0 (på grunn av fraværet av den nevnte <?eclipse version="3.0"?>-linjen i plugin-manifestet), og kompenserer automatisk for disse endringene i plattformkjøretiden.
Plugin-modulen org.eclipse.xerces er ikke lenger nødvendig, og den er slettet. Støtte for XML-analyse er innebygd i J2SE 1.4, og plugin-modulen for Xerces oppretter klasselastingskonflikter. API-pakkene javax.xml.parsers, org.w3c.dom.* og org.xml.sax.* som tidligere ble oppgitt av plugin-modulen org.eclipse.xerces, er nå tilgjengelige fra J2SE-bibliotekene.
Hvis din plugin-modul krever plugin-modulen org.eclipse.xerces, må du endre plugin-manifestet slik at denne oppgitte avhengigheten fjernes. Når det er gjort, skal plugin-modulens kode kunne kompileres og kjøres uten videre endring.
En binær plugin-modul for 2.1 med en oppgitt avhengighet med plugin-modulen org.eclipse.xerces vil mangle en forutsetning når den kjøres i en standard Eclipse 3.0-konfigurasjon. Som en konsekvens blir plugin-modulen ikke aktivert.
Før Eclipse 3.0 fungerte Eclipse for det meste i en enkelt tråd. De fleste API-metoder og utvidelsespunkter fungerte enten i brukergrensesnittråden eller i en tråd som kommer fra en fremdriftsdialogboks som blokkerte brukergrensesnittråden. De fleste plugin-utviklere trengte ikke å bekymre seg så mye om trådsikkerhet, bortsett fra å sikre at all brukergrensesnittaktivitet oppstod i brukergrensesnittråden. I Eclipse 3.0 er det generelt mye mer samtidighet. Mange operasjoner oppstår nå i en bakgrunnstråd, der de kan kjøre samtidig med andre tråder, inkludert brukergrensesnittråden. Alle plugin-moduler med kode som kjører i en bakgrunnstråd, må nå ta hensyn til kodens trådsikkerhet.
I tillegg til plugin-moduler som
eksplisitt kjører operasjoner i bakgrunnen ved hjelp av APIet org.eclipse.core.runtime.jobs
,
finnes det flere funksjoner for plattform-API og utvidelsespunkter som bruker
bakgrunnstråder. Plugin-moduler som bruker disse funksjonene,
må sørge for at koden er trådsikker. Den følgende tabellen inneholder et
sammendrag av APIet og utvidelsespunktene som kjører noe av eller all koden i
en bakgrunnstråd i Eclipse 3.0:
Utvidelsespunkt eller API-klasse |
Merknader |
org.eclipse.core.runtime.IRegistryChangeListener | Ny i Eclipse 3.0, kjører i bakgrunnen |
org.eclipse.core.resources.IResourceChangeListener | AUTO_BUILD -hendelser nå i bakgrunnen |
org.eclipse.core.resources.builders (utvidelsespunkt) | Automatisk bygging nå i bakgrunnen |
org.eclipse.core.resources.ISaveParticipant | SNAPSHOT nå i bakgrunnen |
org.eclipse.ui.workbench.texteditor.quickdiffReferenceProvider (utvidelsespunkt) | Ny i Eclipse 3.0, kjører i bakgrunnen |
org.eclipse.ui.decorators (utvidelsespunkt) | Allerede i bakgrunnen i Eclipse 2.1 |
org.eclipse.ui.startup (utvidelsespunkt) | Allerede i bakgrunnen i Eclipse 2.1 |
org.eclipse.team.core.org.eclipse.team.core.repository (utvidelsespunkt) | Mange operasjoner nå i bakgrunnen |
org.eclipse.team.ui.synchronizeParticipants (utvidelsespunkt) | Ny i Eclipse 3.0, kjører i bakgrunnen |
org.eclipse.debug.core.launchConfigurationTypes (utvidelsespunkt) | Kjører nå i bakgrunnen |
org.eclipse.jdt.core.IElementChangedListener | ElementChangedEvent.PRE_AUTO_BUILD kjører
nå i bakgrunnen, POST_RECONCILE kjørte allerede i bakgrunnen |
Det finnes ulike tilgjengelige
strategier for å gjøre koden trådsikker. En intern løsning er å
sikre at alt arbeid forekommer i brukergrensesnittråden, og derved sikre
serialisert utføring. Dette er en vanlig tilnærming for
plugin-moduler for brukergrensesnitt som ikke utfører
CPU-intensiv behandling. Når dette gjøres, må du være oppmerksom på
vranglåsrisikoen i Display.syncExec
. Display.asyncExec
er
generelt sikrere fordi det ikke har en vranglåsrisiko, men det kan føre til tap av kontrollen
over når koden utføres.
Andre teknikker for å gjøre kode trådsikker:
org.eclipse.core.runtime.jobs.ILock
.
Fordelen med
ILock
fremfor generiske låser, er at de overføres automatisk til
brukergrensesnittråden når det utføres en syncExec
, og støtte for oppdaging av
vranglås er innebygd i implementeringen som loggfører og deretter åpner vranglås.Display.asyncExec
), som behandles bare i brukergrensesnittråden.java.lang.String
og
org.eclipse.core.runtime.IPath
trådsikre. Fordelen med uforanderlige objekter
er svært rask lesetilgang, men det gir ekstra arbeid ved endring.De følgende metodene er slettet fra org.eclipse.ui.IWorkbenchPage-grensesnittet. IWorkbenchPage er deklarert i den generiske arbeidsbenken, men metodene er iboende ressursspesifikke.
Klienter av disse IWorkbenchPage.openEditor-metodene må i stedet sende kall til de tilsvarende felles statiske metodene som er deklarert i klassen org.eclipse.ui.ide.IDE (i plugin-modulen org.eclipse.ui.ide).
Klienter av denne IWorkbenchPage.openSystemEditor(IFile)-metoden må konvertere IFile til IEditorInput ved hjelp av den nye FileEditorInput(IFile), og deretter sende kall til metoden openEditor(IEditorInput,String). Med andre ord skrive om page.openSystemEditor(file) til page.openEditor(new FileEditorInput(file), IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID). Merk: Klienter som bruker redigeringsprogram-IDen IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID, må sende redigeringsprograminndata som implementerer org.eclipse.ui.IPathEditorInput (som FileEditorInput gjør).
Merk: Dette er en av inkompatibilitetene som ikke påvirker hvordan binære plugin-moduler for 2.1 kjøres av Eclipse 3.0. Eclipse 3.0 inkluderer en binær mekanisme for kjøretidskompatibilitet som sikrer at eksisterende binære filer for 2.1-plugin-moduler bruker en hvilken som helst av de slettede openEditor- og openSystemEditor-metodene, fortsetter å fungere som i 2.1, til tross for denne API-endringen. (De slettede metodene blir effektivt "lagt tilbake" av fragmentet org.eclipse.ui.workbench.compatibility.)Den følgende metoden er slettet fra org.eclipse.ui.IEditorPart-grensesnittet. IEditorPart er deklarert i den generiske arbeidsbenken, men metoden er iboende ressursspesifikk.
Klienter som sender kall til denne metoden, må i stedet teste om redigeringsprogramdelen implementerer eller tilpasses til org.eclipse.ui.ide.IGotoMarker (i plugin-modulen org.eclipse.ui.ide), og i så fall sende kall til gotoMarker(IMarker). IDE-klassen har en bekvemmelig metode for å gjøre dette: IDE.gotoMarker(editor, marker).
Klienter som implementerer et redigeringsprogram som kan plassere seg selv basert på IMarker-informasjon, må implementere eller tilpasses til org.eclipse.ui.ide.IGotoMarker.Siden IGotoMarkers eneste metode er gotoMarker(IMarker), og den har samme signatur og spesifikasjon som den gamle IEditorPart.gotoMarker(IMarker), kan eksisterende redigeringsprogramimplementeringer tilpasses til denne endringen ved å ganske enkelt inkludere IGotoMarker i implements-leddet av klassedefinisjonen.
En binær plugin-moduler fra 2.1 med kode som sender kall til denne metoden, får et unntak av typen klasselinkfeil når den kjøres i en standard Eclipse 3.0-konfigurasjon.
Grensesnittet for redigeringsprogramoppstarteren, org.eclipse.ui.IEditorLauncher, implementeres av plugin-moduler som bidrar til eksterne redigeringsprogrammer. Den følgende metoden er fjernet fra dette grensesnittet. IEditorLauncher er deklarert i den generiske arbeidsbenken, men metoden er iboende ressursspesifikk.
er erstattet av
En binær plugin-moduler fra 2.1 med kode som sender kall til denne metoden, får et unntak av typen klasselinkfeil når den kjøres i en standard Eclipse 3.0-konfigurasjon.
De følgende metodene er fjernet fra org.eclipse.ui.IEditorRegistry-grensesnittet. IEditorRegistry er deklarert i den generiske arbeidsbenken, men metodene er iboende ressursspesifikke.
Det finnes nye konstanter som representerer systemets eksterne redigeringsprogram og identifikatorer for systemets redigeringsprogram på stedet (SYSTEM_EXTERNAL_EDITOR_ID og SYSTEM_INPLACE_EDITOR_ID). Disse to redigeringsprogrammene krever redigeringsprograminndata som implementerer eller tilpasses til org.eclipse.ui.IPathEditorInput. Vær oppmerksom på at deskriptoren for redigeringsprogrammet på stedet ikke vil finnes i Eclipse-konfigurasjoner som ikke støtter redigering på stedet.
Den følgende metoden er slettet fra org.eclipse.ui.IWorkbench-grensesnittet. IWorkbench er deklarert i den generiske arbeidsbenken, men metoden er iboende ressursspesifikk.
En binær plugin-moduler fra 2.1 med kode som sender kall til denne metoden, får et unntak når den kjøres i en standard Eclipse 3.0-konfigurasjon.
For å gjøre org.eclipse.ui.texteditor.AbstractTextEditor uavhengig av IFile, introduserer org.eclipse.ui.texteditor.AbstractDocumentProvider konseptet dokumentleverandøroperasjon (DocumentProviderOperation) og en operasjonskjører for dokumentleverandør (IRunnableContext). Når AbstractDocumentProvider blir bedt om å utføre tilbakestilling, lagring eller synkronisering, oppretter det dokumentleverandøroperasjoner og bruker operasjonskjøreren til å utføre dem. Den kjørbare konteksten kan oppgis av subklasser via metoden getOperationRunner. Dette er et sammendrag av endringene som klientene må tilpasses til:
AbstractDocumentProvider-subklassen org.eclipse.ui.editors.text.StorageDocumentProvider implementerer getOperationRunner-metoden til å alltid returnere null. Det betyr at subklasser av StorageDocumentProvider ikke skal være påvirket av denne endringen.
StorageDocumentProvider-subklassen org.eclipse.ui.editors.text.FileDocumentProvider implementerer getOperationRunner-metoden som returnerer en IRunnableContext for utføring av den gitte DocumentProviderOperations i en WorkspaceModifyOperation. Andre endringer i FileDocumentProvider:
Endringer i org.eclipse.ui.texteditor.AbstractTextEditor:
ResourceAction action= new AddMarkerAction(TextEditorMessages.getResourceBundle(), "Editor.AddBookmark.", this, IMarker.BOOKMARK, true); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.BOOKMARK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_BOOKMARK); setAction(IDEActionFactory.BOOKMARK.getId(), action);
action= new AddTaskAction(TextEditorMessages.getResourceBundle(), "Editor.AddTask.", this); //$NON-NLS-1$ action.setHelpContextId(ITextEditorHelpContextIds.ADD_TASK_ACTION); action.setActionDefinitionId(ITextEditorActionDefinitionIds.ADD_TASK); setAction(IDEActionFactory.ADD_TASK.getId(), action);
AbstractTextEditor-subklassen org.eclipse.ui.texteditor.StatusTextEditor har predikatmetoden isErrorStatus(IStatus). Subklasser kan overstyre for å fastsette hvor vidt en gitt status må betraktes som en feil.
Endringer i org.eclipse.ui.editors.text.AbstractDecoratedTextEditor:
Som en del av introduksjonen av støtten for annotasjoner i kommandogrensesnittet, er disse endringene gjort i Annotasjoner:
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
Eclipse 3.0 har nå støtte for generisk konsoll. Den generiske konsollen er tilgjengelig via Vindu > Vis visning > Grunnleggende > Konsoll, og den brukes av Eclipse-feilsøkingen og Ant-integreringen.
Visnings-IDen for konsollen er endret fra org.eclipse.debug.ui.ConsoleView til org.eclipse.ui.console.ConsoleView. Plugin-moduler for 2.1 som åpner konsollen programmatisk, vil mislykkes fordi den gamle visningen ikke finnes lenger.
I 3.0 ble returtypene for metodene org.eclipse.jdt.debug.core.IJavaBreakpointListener.breakpointHit(IJavaBreakpoint, IJavaThread) og installingBreakpoing(IJavaTarget, IJavaBreakpoint, IJavaType) endret fra boolsk til int for å tillate lytterne å stemme "don't care". I utgaver som er eldre enn 3.0, kan lytterne bare stemme "suspend" eller "don't suspend" når et avbruddspunkt påtreffes, og "install" eller "don't install" når et avbruddspunkt var i ferd med å bli installert. I 3.0 kan lyttere også stemme "don't care" for en hvilken som helst av disse varslingene. Dette gjør at klientene bare kan gi en avgjørende stemme i situasjoner som gjelder dem. For varsling om "avbruddspunkttreff" blir avbruddspunktet stoppet midlertidig hvis en hvilken som helst lytter stemmer "suspend", eller hvis alle lytterne stemmer "don't care", og det blir ikke stoppet midlertidig hvis minst en lytter stemmer "don't suspend" og ingen lyttere stemmer "suspend". Og på liknende måte, for "avbruddspunktinstallering" blir avbruddspunktet installert hvis hvilke som helst lyttere stemmer "don't care", og det blir ikke installert hvis minst en lytter stemmer "don't install" og ingen lytter stemmer "install". Implementorer må generelt returnere DONT_CARE hvis de ikke har en sterk overbevisning i en eller annen retning. Det er viktig å være klar over at for eksempel å stemme "suspend", vil overstyre en hvilken som helst annen lytters stemme på "don't suspend".
IJavaBreakpointListener-grensesnittet er implementert av klienter som oppretter eller reagerer på avbruddspunkter i Java-kode. Det finnes sannsynligvis få klienter utenfor selve JDT, bortsett fra den som rapporterte problemet (bug 37760), som denne endringen er en problemløser for. Dette er en avbruddspunktendring for eksisterende kode som implementerer IJavaBreakpointListener-grensesnittet. Denne koden må endres slik at det returneres en passende int-verdi før den kan kompileres eller kjøres i 3.0.
Før 3.0 hadde metodene i SWT-klassen org.eclipse.swt.dnd.Clipboard ved en forglemmelse fått tillatelse til å kjøre i andre tråder enn brukergrensesnittråden. Dette resulterte i feil i GTK der operativsystemet krever at alle utklippstavleinteraksjoner kan utføres i brukergrensesnittråden. Forglemmelsen ble ikke avdekket tidligere fordi mange applikasjoner er enkelttrådet, og mottar det meste av testingen fra Windows. For at utklippstavle-API skal kunne opprettholdes og fungere for flere plattformer, er spesifikasjonen og implementeringen av alle metoder for utklippstavle-API i 3.0 endret slik at det blir kastet et SWT-unntak (ERROR_THREAD_INVALID_ACCESS) hvis det startes fra en ikke-brukergrensesnittråd. Utklippstavletjenester blir vanligvis levert automatisk av Eclipse-komponenter, som for eksempel tekstredigeringsprogrammet, som isolerer mange klienter fra denne endringen. Eksisterende kode som ikke gjør direkte bruk av utklippstavlen, må forsikres om at det blir sendt kall til API-metodene i den riktige tråden, ved hjelp av Display.asyncExec eller syncExec når det passer slik at tilgangene går til brukergrensesnittråden.
I 3.0 rapporterer SWT tast ned-hendelser før arbeidet er gjort i operativsystemet. Dette er mye enklere enn det var før 3.0. Denne endringen ble gjort for å støtte tastbindinger i Eclipse som gjør det nødvendig å oppfange tasthendelser før noen widget har muligheten til å behandle tegnet. Konsekvensene av denne endringen er synlige for kode som håndterer org.eclipse.swt.SWT.KeyDown-hendelser på lavt nivå direkte. Det betyr for eksempel at når en lytter på en tekst-widget mottar en tast ned-hendelse, inkluderer widgetens innhold (getText()) ennå ikke tasten det nettopp ble trykt på (før 3.0 ville det gjøre det). Den anbefalte metoden for å få den fullstendige teksten fra widgeten, inkludert tasten, er å håndtere SWT.Modify- eller SWT.Verify-hendelsene på høyt nivå i stedet for SWT.KeyDown-hendelsen på lavt nivå. Kode som allerede gjør det på denne måten, blir ikke påvirket av denne endringen.
Når det før 3.0 var fokus i SWT-klassen org.eclipse.swt.widgets.Canvas eller en av subklassene (inkludert tilpassede widgeter), ville trykk på Ctrl+Tab, Skift+Tab, Ctrl+PgUp eller Ctrl+PgDn automatisk utløse en tabulatortraversering til neste/forrige widget uten å rapportere en tasthendelse. Denne virkemåten var uspesifisert, og den kjører i motsetning til regelen om at lerretene ser hver tast det trykkes på i dem. Den riktige måten å håndtere denne traverseringen på, er å registrere en traverseringslytter. For å kunne gi riktig støtte til Eclipse-tastbindinger i 3.0, ble standardvirkemåten endret slik at lerretet nå ser Ctrl+Tab-, Skift+Tab-, Ctrl+PgUp- og Ctrl+PgDn-tasthendelser i stedet for traversering. Hvis du bruker et ubehandlet lerret eller definerer en subklasse av bakgrunnen, må du huske på å registrere en traverseringslytter.
Musevalg av elementer i SWT-klassene org.eclipse.swt.widgets.Table og Tree genererer hendelsessekvensen MouseDown-Selection-MouseUp på samme måte i alle operativmiljøer. På samme måte genererer tastaturvalg hendelsessekvensen KeyDown-Selection-KeyUp på samme måte i alle operativmiljøer. Før 3.0 var hendelsesrekkefølgen ikke ensartet, med Motif og Photon i varians med resten ved at de alltid rapporterer valghendelsen først. Det vil si Selection-MouseDown-MouseUp eller Selection-KeyDown-KeyUp. For 3.0 er hendelsesrekkefølgen for Motif og Photon endret slik at den samsvarer med de andre. Eksisterende kode som tidligere fungerte riktig for {Windows, GTK} og {Motif, Photon}, blir sannsynligvis ikke påvirket. Du må imidlertid kontrollere koden slik at du kan forsikre deg om at den ikke avhenger av en ugyldig hendelsesrekkefølge.
org.eclipse.core.runtime.IStatus
har en
ny alvorskonstant, IStatus.CANCEL
, som kan brukes til å
oppgi avbrudd. Kallere av IStatus.getSeverity()
som er avhengig av at settet av alvorsgrader, er begrenset til IStatus.OK
,
INFO
, WARNING
og ERROR
, blir påvirket av
dette tillegget. Kallere av getSeverity
må oppdatere koden for å inkludere den nye alvorsgraden.
I Eclipse 3.0 skjer automatiske bygginger
av arbeidsområde nå i en bakgrunnstråd. Dette krevde en endring i
API-kontrakten til org.eclipse.core.resources.IResourceChangeEvent
. Kontrakten
IResourceChangeEvent
garanterte tidligere den følgende rekkefølgen
av hendelser for alle arbeidsområdeendringer:
PRE_DELETE
eller PRE_CLOSE
der det er aktueltPRE_AUTO_BUILD
POST_AUTO_BUILD
POST_CHANGE
Automatisk bygging kjører nå i
bakgrunnen, og det er ikke lenger noen garantier om det tidsmessige forholdet
mellom AUTO_BUILD
-hendelsene og POST_CHANGE
-hendelsen. I Eclipse 3.0 er
trinn 3-5 i strukturen ovenfor fjernet. Resultatet ser slik ut:
PRE_DELETE
eller PRE_CLOSE
der det er aktueltPOST_CHANGE
Plattformen vil med jevne mellomrom utføre en arbeidsområdebygging i bakgrunnen. Vær oppmerksom på at dette skjer uansett om den automatiske byggingen er aktivert eller deaktivert. Det blir ikke oppgitt nøyaktig når denne byggingen skal skje. Strukturen for byggeoperasjonen vil se slik ut:
PRE_BUILD
(PRE_BUILD
er det
nye navnet på PRE_AUTO_BUILD)
POST_BUILD
(POST_BUILD
er det
nye navnet på POST_AUTO_BUILD)
POST_CHANGE
Referansepunktet for deltaene som mottas av AUTO_BUILD-lytterne, vil være foreskjellig fra det for POST_CHANGE-lytterne. Byggelyttere mottar varsling om alle endringer siden slutten av siste byggeoperasjon. Lyttere etter endringen mottar en delta som beskriver alle endringer siden siste POST_CHANGE-varsling. Denne nye strukturen beholder tre karakteristika av lyttere til ressursendring som har vært sanne siden Eclipse 1.0:
POST_CHANGE
-lyttere mottar varsling om
absolutt alle ressursendringer som forekommer i løpet av den tiden de er registrert. Dette
inkluderer endringer som er gjort av byggerne, og endringer som er gjort av andre lyttere.PRE_AUTO_BUILD
-lytter mottar varsling om
alle ressursendringer, unntatt endringer som er gjort av byggere og
ressursendringslyttere.POST_AUTO_BUILD
-lyttere mottar varsling om alle
ressursendringer, unntatt endringer som er gjort av andre
POST_AUTO_BUILD
-lyttere.Det finnes imidlertid noen viktige
forskjeller med denne tilnæringen. Før Eclipse 3.0 ble det
alltid sendt kall til AUTO_BUILD-lyttere før POST_CHANGE
-lyttere. Av denne grunnen
var deltaene som ble mottatt av AUTO_BUILD-lyttere,
alltid et delsett av deltaene som ble mottatt av
POST_CHANGE
-lytterne.
Dette forholdet er nå i hovedsak
reversert. AUTO_BUILD-lyttere mottar en delta som er et supersett av alle
deltaene som er levert til POST_CHANGE
-lyttere siden
slutten av den forrige bakgrunnsbyggingen. Som før har AUTO_BUILD-lyttere
tillatelse til å endre arbeidsområdet, og POST_CHANGE-lyttere har ikke det.
Det vil ikke lenger være sant at
lytterne til en AUTO_BUILD
-hendelse blir varslet
ved fullføring av en arbeidsområdeendring.
Klientkode som registrerer
ressursendringslytter med IWorkspace.addResourceChangeListener(IResourceChangeListener)
,
blir sannsynligvis ikke påvirket av denne endringen, fordi AUTO_BUILD
-hendelser
aldri ble rapportert til disse lytterne. Imidlertid vil klienter som bruker
IWorkspace.addResourceChangeListener(IResourceChangeListener,int)
og oppgir en hendelsesmaske som inkluderer AUTO_BUILD
-hendelser,
sannsynligvis bli brutt av denne endringen hvis de gjør antakelser om når
AUTO_BUILD-lyttere kjører, og hvilken tråd de kjører i. Hvis en AUTO_BUILD-lytter
for eksempel oppdaterer en domenemodell slik at den gjenspeiler endringer i arbeidsområdet,
er det mulig at denne oppdateringen ikke har funnet sted når operasjonen for
arbeidsområdeendring returnerer. Vær oppmerksom på at bare
kode på brukergrensesnittnivå kan påvirkes på denne måten. Kode på kjernenivå som
kalles via API, kan kalles innen omfanget av en IWorkspaceRunnable
,
så det er ikke mulig å være sikker på når det blir sendt kall til
ressursendringslyttere. Den foreslåtte rettelsen er å bruke
POST_CHANGE
i stedet for byggelyttere hvis det er nødvendig at
varslingen skjer før operasjonen fullføres.
Det garanteres ikke lenger at
alle ressursendringer som forekommer i løpet av det dynamiske omfanget av en
IWorkspaceRunnable
, blir kjørt satsvist i en enkelt varsling. Denne mekanismen kan
fremdeles brukes til å kjøre endringer satsvist for å unngå unødvendige bygginger og
varslinger, men plattformen kan nå bestemme seg for å utføre varslinger i løpet av
operasjonen. Denne endringen i API-kontrakten blir sannsynligvis ikke en
stor endring for eksisterende klienter. Dette er det samme som at plattformen bestemmer seg
for å sende kall til IWorkspace.checkpoint
regelmessig i løpet av
operasjoner med lang kjøretid. Årsaken til denne endringen er at
det nå er mulig at flere tråder kan endre arbeidsområdet samtidig. Når en tråd er
ferdig med å endre arbeidsområdet, er det nødvendig med en varsling for å hindre problemer med
mottakelighet, selv om den andre operasjonen ennå ikke er fullført. Denne endringen
gjør også at brukerne kan begynne å arbeide med et sett av ressurser før
operasjonen er fullført. En bruker kan nå for eksempel
begynne å bla gjennom filer i et prosjekt som fremdeles er i ferd med å bli
hentet ut. Den nye metoden IWorkspace.run(IWorkspaceRunnable,
ISchedulingRule, int, IProgressMonitor)
har et valgfritt flagg, AVOID_UPDATE
,
som operasjoner kan bruke som et tips til plattformen for å oppgi om det er ønskelig
med regelmessige oppdateringer.
Dette påvirkes: Plugin-moduler som bidrar med
utvidelser til utvidelsespunktet org.eclipse.core.runtime.urlHandlers
.
Beskrivelse: Kontrakten for utvidelsespunktet
org.eclipse.core.runtime.urlHandlers
er endret til å bruke
tjenesten URL Stream Handler som leveres av OSGi. OSGi-støtten er bedre enn den
i Eclipse 2.1, og den håndterer dynamiske behandlere på riktig måte. På grunn av de ulike
designproblemene med den grunnleggende URL-behandlermekanismen i Java, må URLStreamHandlers
som er registrert med OSGi-håndterertjenesten, implementere
org.osgi.service.url.URLStreamHandlerService
.
Nødvendig handling: Tidligere måtte
behandlerklassen implementere java.net.URLStreamHandler
og utvide
utvidelsespunktet urlHandlers. Utvidelsespunktet er ikke lenger
støttet, og behandleren må oppdateres slik at den implementerer grensesnittet
org.osgi.service.url.URLStreamHandlerService
. OSGi-rammeverket har en
abstrakt basisklasse (org.osgi.service.url.AbstractURLStreamHandlerService
)
som trivielt kan gjøres om til subklasse for å fylle denne rollen.
I stedet for å registrere behandleren ved hjelp av et utvidelsespunkt, må plugin-moduler nå gjøre det ved å registrere behandleren som en tjeneste. Eksempel:
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);
Dette påvirkes: Plugin-moduler som leverer pakker som også leveres av andre plugin-moduler. Et svært begrenset antall plugin-moduler blir påvirket av denne endringen, og noen av de som blir påvirket, har faktisk fordel av det (se nedenfor).
Beskrivelse: I Eclipse 2.x søker klasselastere etter klasser i denne rekkefølgen: konsulterer (1) den overordnede klasselasteren (i praksis er dette klasselasteren for Java-oppstart), deretter (2) eget klassebaneinnhold og endelig (3) alle forutsetningene i den oppgitte rekkefølgen. OSGi tilbyr en optimalisering over denne modellen. I denne tilnærmingen vil en klasselaster konsultere (1) den overordnede klasselasteren (igjen faktisk klasselasteren for Java-oppstart), deretter enten (2a) en enkelt forutsetning som er kjent for å bidra med klasser i pakken det blir kjørt spørring mot, eller (2b) egne klassebaneoppføringer for den ønskede klassen.
Klasselasteren bestemmer om den selv skal konsulteres eller forutsetningene basert på de importerte og nødvendige pakkene. Denne informasjonen avledes fra plugin-innholdet i tilfeller med tradisjonelle plugin-moduler, og direkte oppgitt i tilfeller med plugin-moduler med eksplisitt OSGi-buntmanifest. I begge tilfeller er det kjent a priori hvilke klasselastere som leverer klassene for hvilke pakker. Dette gir både ytelsesforbedringer og en løsning for det irriterende problemet med mange forutsetninger som bidrar med de samme klassene.
Vi kan for eksempel se på tilfellet med Xerces og Xalan, som begge inneholder diverse klasser fra org.xml-pakker. Med den første tilnærmingen vil plugin-modulen Xerces se sin kopi av disse klassene, mens plugin-modulen Xalan vil se deres kopi. Siden disse plugin-modulene har behov for å kommunisere, forekommer det ClassCastExceptions. Med den andre tilnærmingen vil bare en av de to plugin-modulene bidra med de dupliserte klassene, og begge plugin-modulene ser de samme kopiene.
Nødvendig handling: Den nødvendige handlingen avhenger av spesifikasjonene i bruken. Påvirkede utviklere må se gjennom klassebanen, og løse eventuelle konflikter som kan oppstå.
Dette påvirkes: Plugin-moduler som forventer at beskyttelsesdomenet for klasselasteren alltid skal være definert.
Beskrivelse: I Eclipse 2.1 var klasselasterne for plugin-moduler java.security.SecureClassloaders, og hadde alltid beskyttelsesdomenet definert. I Eclipse 3.0 utvider ikke klasselasterne SecureClassloader, og definerer bare beskyttelsesdomenet hvis Java-sikkerhet er slått på (ikke vanlig).
Nødvendig handling: Den nødvendige handlingen er avhengig av scenariet der plugin-modulen bruker beskyttelsesdomenet.
Dette påvirkes: Plugin-moduler som omvandler objekter av typen org.eclipse.core.runtime.IPlugin* til org.eclipse.core.runtime.model.Plugin*Model. Selv om forholdet mellom disse grensesnittene og modellklassene ikke er oppgitt i Eclipse 2.1-APIet, opplyser vi eksplisitt om denne endringen fordi det er funnet forekomster av plugin-moduler som avhenger av dette forholdet i 2.1-implementeringen.
Beskrivelse: Eclipse-APIet har en
serie av grensesnitt (for eksempel IPluginDescriptor
)
og såkalte "model"-klasser (for eksempel PluginDescriptorModel
)
som er knyttet til plugin-moduler og plugin-registeret. I Eclipse 2.1-implementeringen
forekommer det at modellklassene implementerer de relevante grensesnittene. I den nye
OSGi-baserte kjøretiden er plugin-registeret betydelig omarbeidet for å tillate et skille mellom
klasselastingen og de nødvendige aspektene av plugin-moduler, og utvidelses- og
utvidelsespunktaspektene. På denne måten kan Eclipse 3.0-kjøretiden ikke
vedlikeholde implementeringsforholdet som finnes i 2.1.
Nødvendig handling: Plugin-moduler som avhenger av dette ikke-API-forholdet, må ha omarbeidet kode i henhold til bruken. Du finner mer informasjon om dette i delen om anbefalte endringer i dette dokumentet, og i Javadoc for de relaterte klassene og metodene.
Dette påvirkes: Plugin-moduler som bruker
org.eclipse.core.runtime.ILibrary
.
Beskrivelse: Den nye kjøretiden vedlikeholder klassebaneoppføringer i en form som er en annen enn og inkompatibel med Eclipse. Som resultat kan kompatibilitetslaget ikke modellere de underliggende OSGi-strukturene som ILibrary-objekter på riktig måte. Kjøretidens kompatibilitetsstøtte oppretter ILibrary-objekter, men må anta andre verdier for alt, bortsett fra bibliotekets bane.
Nødvendig handling: Brukere av ILibrary bør
vurdere å få tilgang til topptekstverdier (for eksempel Bundle-Classpath
) fra
den passende bunten (se Bundle.getHeaders()
), og bruke
hjelpeklassen ManifestElement
til å tolke oppføringene. Se klasse-Javadoc
hvis du vil ha mer informasjon.
Dette påvirkes: Plugin-moduler som har antakelser om layout for installeringsstruktur, plassering og lokalt filsystem.
Beskrivelse: Metoder som IPluginDescriptor.getInstallURL()
returnerer URLer i en bestemt form. Selv om formen ikke er oppgitt,
gjør ulike plugin-moduler antakelser basert på den gjeldende implementeringen. De kan for eksempel
forvente å få en file:
-URL, og bruke URL.getFile(), og bruke
java.io.File
-manipulering på resultatet. Hittil har dette vært en
akseptabel, men noe skrøpelig tilnærming. Hvis en plugin-modul for eksempel
er installert på en web-server, er det mulig at en http:
-URL blir
returnert. Den nye Eclipse 3.0-kjøretiden er enda mer fleksibel,
og den åpner for flere muligheter for utføringskonfigurasjoner (for eksempel
vedlikeholde hele plugin-moduler i JAR-filer i stedet for at de
deles i kataloger).
Det vil si at mens den nye
OSGi-baserte kjøretiden ikke faktisk bryter 2.1-APIet, eksponerer det flere tilfeller der
antakelser som er gjort i gjeldende plugin-moduler, er ugyldige.
Nødvendig handling: Plugin-skribenter må forsikre
seg om at informasjonen de må ha tilgang til, er tilgjengelig via getResource()
(og finnes i
klassebanen), eller bruke det relevante APIet til å få tilgang til innholdet i en plugin-modul
(for eksempel Bundle.getEntry(String)
).
Dette påvirkes: Ikke-plugin-kode som gir kall
til bestemte metoder fra klassen org.eclipse.core.boot.BootLoader
.
Beskrivelse: De statiske metodene BootLoader.startup(), shutdown() og run() er flyttet til org.eclipse.core.runtime.adaptor.EclipseStarter, som er en del av OSGi-rammeverket. Dette APIet er grensesnittet mellom main() i startup.jar og OSGi-rammeverket/Eclipse-kjøretiden. Omstruktureringen av kjøretiden tillot ikke at disse metodene var i BootLoader. Den gamle BootLoader-klassen er nå plassert i laget for kjøretidskompatibilitet og er foreldet, og de flyttede metodene er redusert til ingenting.
Det finnes ingen erstatning for den gamle BootLoader.getRunnable() fordi kjøretiden kan ikke lenger støtte anskaffelsen av individuelle applikasjoner. I stedet må brukerne oppgi den aktuelle applikasjonen når de starter plattformen.
Nødvendig handling: Generelt sett blir dette APIet brukt av svært få (det kan ikke brukes fra en Eclipse-plugin). I de sjeldne tilfellene det blir brukt, må koden tilpasses til å bruke tilsvarende metoder i EclipseStarter.
Dette påvirkes: Alle plugin-moduler.
Beskrivelse: I Eclipse 2.1 var det ikke nødvendig at en plugin-moduls bin.includes-linje fra build.properties inneholdt listen over JAR-filer fra bibliotekdeklarasjonen i plugin.xml-filen. Disse JAR-filene ble lagt til automatisk. I Eclipse 3.0 er listen over filer i bin.includes-delen i build.properties fullstendig, og den må inkludere filer som plugin-utviklerne har tenkt til inkludering i deres plugin-modul ved bygging og eksport.
Nødvendig handling: Forsikre deg om at bin.includes-linjen fra build.properties-filen inkluderer alle JAR-filene som er oppført i plugin.xml-filen.
Dette påvirkes: Plugin-moduler som eksponerer API som inkluderer elementer fra endret kjøretids-API.
Beskrivelse: Ulike plugin-moduler eksponerer API som inkluderer elementer fra kjøretids-APIet. Med de endringene av Eclipse 3.0-kjøretiden som er skissert her, må plugin-moduler for klienter revurdere bruken av kjøretids-API i sitt API.
Nødvendig handling: Dette scenariet er ganske sjeldent siden svært lite av kjøretids-APIet for Eclipse blir endret. Avhengig av scenariet må klienter endre deres API eller fortsette å være avhengig av kompatibilitetslaget.
Dette påvirkes: PlPlugin-moduler som bruker
org.eclipse.core.runtime.Platform.parsePlugins(..., Factory).
Beskrivelse: Metoden
org.eclipse.core.runtime.Platform.parsePlugins(..., Factory)
er flyttet. APIet som er knyttet
til Factory-argumentet, er flyttet fra plugin-modulen org.eclipse.core.runtime til
plugin-modulen org.eclipse.core.runtime.compatibility (som er avhengig av plugin-modulen
for kjøretid). Som et resultat er analysemetoden også flyttet.
Nødvendig handling: Brukere av denne metoden må bruke
den samme metoden for klassen org.eclipse.core.runtime.model.PluginRegistryModel
.
Dette påvirkes: Plugin-moduler som oppgir kode i klassebanen, men som ikke leverer denne koden (det vil si JAR-filen leveres av et fragment, for eksempel plugin-modulen org.eclipse.swt).
Beskrivelse: Den nye kjøretiden må konvertere plug.xml-filer til manifest.mf-filer i bakgrunnen. Dette gjøres gjennom en mekanisk omdanning og en analyse av jar-filene som oppgis og leveres av plugin-modulen. I tilfellet der en plugin-modul oppgir en jar-fil i klassebanen, men ikke leverer jar-filen, finnes det ingen kode som skal analyseres og plugin-konvertereren kan ikke generere en riktig manifest.mf.
Nødvendig handling: Leverandører av slike plugin-moduler må enten endres slik at de leverer den riktige jar-filen i selve plugin-modulen, eller manuelt opprette eller vedlikeholde en META-INF/MANIFEST.MF-fil for plugin-modulen. Dette kan vanligvis gjøres ved hjelp av PDE for å hente det første manifestet, og deretter tilføye det i den riktige Provide-Package-toppteksten.
Dette påvirkes: Skript (for eksempel build.xml-filer for Ant) som definerer klassebaner som inneholder kjøretidsrelaterte jar-filer og klassekataloger.
Beskrivelse: Den nye kjøretiden inneholder flere
plugin-moduler og jar-filer. Mandatet for introduksjonen
kommer fra refaktoriseringen av kjøretiden til konfigurerbare deler. For de fleste
kjøretidssituasjoner er disse endringene transparente.
Hvis du har tilpassede
build.xml-skript (eller liknende) som samtidig kompilerer kode mot
org.eclipse.core.runtime
, må du imidlertid oppdatere dem for at de skal fungere
på riktig måte. Et vanlig skript inneholder en klassebaneoppføring
i en <javac>-oppgave som refererer til plugin-modulen org.eclipse.core.runtime
på denne måten:
../org.eclipse.core.runtime/bin;../org.eclipse.core.runtime/runtime.jar
Plugin-modulen for kjøretid inneholder
fremdeles mye av den opprinnelige kjøretidskoden.
Ulike deler av kjøretiden
som bare finnes av kompatibilitetsårsaker, ligger imidlertid i en
kompatibilitets-plugin (org.eclipse.core.runtime.compatibility
).
Det meste av den nye
kjøretidskoden ligger i en samling av plugin-moduler (org.eclipse.osgi.*
).
Nødvendig handling: Utviklere bør tilføye oppføringene nedenfor etter behov for å eliminere kompileringsfeil. Det fullstendige settet av leverte jar-filer vises nedenfor, men vanlige brukere trenger bare et delsett i klassebanen på kompileringstidspunktet. Som vanlig er inkluderingen av /bin-katalogene valgfritt. Oppføringene vises her i logiske grupperinger etter leverende plugin-modul:
I tillegg kan de følgende jar-filene være nødvendige i spesielle tilfeller:
Ved oppdatering av slike skript bør du
også benytte muligheten til å rydde opp i (det vil si fjerne) referanser til
org.eclipse.core.boot
. Denne plugin-modulen er foreldet, og den
inneholder ikke lenger kode. Oppføringene kan fortsette å ligge i
klassebanen, men de har ingen hensikt, og bør fjernes. Bør fjernes:
../org.eclipse.core.boot/bin;../org.eclipse.core.boot/boot.jar
Dette påvirkes: Skript (for eksempel build.xml-filer for Ant) som bruker eclipse.buildScript-oppgaven.
Beskrivelse: PDE Build introduserte en ny egenskap i oppgaven eclipse.buildScript for å styre genereringen av byggeskript for plugin-moduler. Mandatet kommer fra introduksjonen av den nye OSGi-baserte kjøretiden.
Nødvendig handling: Hvis du vil bruke Eclipse 3.0 til å bygge et 2.1-basert produkt, må du introdusere egenskapen "buildingOSGi" i eclipse.buildScript, og definere den til false. Eksempel:
<eclipse.buildScript ... buildingOSGi="false"/>
Dette påvirkes: Skript (for eksempel build.xml-filer for Ant) som bruker eclipse.buildScript-oppgaven.
Beskrivelse: PDE Build introduserte en ny egenskap i oppgaven eclipse.buildScript for å styre genereringen av byggeskript for plugin-moduler. Mandatet kommer fra introduksjonen av den nye OSGi-baserte kjøretiden.
Nødvendig handling: Hvis du vil bruke Eclipse 3.0 til å bygge et 2.1-basert produkt, må du introdusere egenskapen "buildingOSGi" i eclipse.buildScript, og definere den til false. Eksempel:
<eclipse.buildScript ... buildingOSGi="false"/>
Dette påvirkes: Skript (for eksempel build.xml-filer for Ant) som bruker eclipse.buildScript-oppgaven.
Beskrivelse: PDE Build endrer virkemåten for oppgaven eclipse.fetch for å lette Eclipse-byggingen i en automatisert byggestil. Elementstilen støtter nå bare en oppføring om gangen, og scriptName blir alltid ignorert.
Nødvendig handling: Hvis du hadde en liste over oppføringer i "elements"-koden for et eclipse.fetch-kall, sprer du dem ut over flere kall til eclipse.fetch. Hvis du bruker å definere scriptName, må du være oppmerksom på at det genererte fetch-skriptet nå alltid er kalt "fetch_{elementId}". Eksempel:
<eclipse.fetch elements="plugin@org.eclipse.core.runtime, feature@org.eclipse.platform" .../>
blir til
<eclipse.fetch elements="plugin@org.eclipse.core.runtime" .../> <eclipse.fetch elements="feature@org.eclipse.platform" .../>
Filen install.ini er ikke lenger inkludert. I stedet brukes den nye config.ini-filen i konfigurasjonens underkatalog. Produkter som brukte install.ini-filen til å oppgi en primær funksjon (for eksempel til å oppgi varemerkeinformasjon), må i stedet endre config.ini-filen. I tillegg til det nye filnavnet er navnene på nøklene endret.
Verdien av feature.default.id-nøkkelen i 2.1 må defineres som verdien av den nye eclipse.product-nøkkelen. Verdien av eclipse.application må defineres til "org.eclipse.ui.ide.workbench".
Og endelig, i 2.1 var oppstartsbildet alltid splash.bmp i plugin-modulens varemerkekatalog. I 3.0 oppgis plasseringen av oppstartsbildet eksplisitt av osgi.splashPath-nøkkelen i config.ini.