Nødvendige endringer når 3.0-mekanismene og -APIene tas i bruk

Denne delen beskriver endringer som er nødvendige hvis du prøver å endre en plugin-modul fra 2.1 slik at den tar i bruk mekanismene og APIene for 3.0.

Org.eclipse.core.runtime.compatibility

Eclipse 3.0-kjøretiden er betydelig forandret. Den underliggende implementeringen er basert på spesifikasjonen for OSGi-rammeverket. Eclipse 3.0-kjøretiden inkluderer et kompatibilitetslag (i plugin-modulen org.eclipse.core.runtime.compatibility) som vedlikeholder 2.1-APIene. Plugin-utviklere som er interessert i ekstra ytelse og funksjonalitet, bør vurdere å ta i bruke APIene for 3.0 og fjerne avhengigheten av kompatibilitetslaget. Kompatibilitetskode blir vist på tre steder:

Teksten nedenfor inneholder flere opplysninger om hvilke klasser og metoder som finnes av kompatibilitetshensyn, i tillegg til retningslinjer for oppdatering av plugin-modulen.

Plugin-moduler og bunter

Eclipse-kjøretiden er refaktorisert til to deler: Klasselasting og nødvendig styring, og styring av utvidelse/utvidelsespunkt. Denne delingen tillater naturlig/sømløs adoptering av spesifikasjonen av OSGi-rammeverk for klasselasting og obligatorisk styring. Dette aktiverer så en serie av ny funksjonalitet i kjøretiden fra installering/oppdatering/avinstallering av dynamisk plugin-modul til sikkerhet og forbedret konfigurerbarhet.

Mer om plugin-moduler: I den nye kjøretiden er en plugin-modul i virkeligheten en bunt pluss noen utvidelser og utvidelsespunkter. Begrepet bunt er definert av spesifikasjonen av OSGi-rammeverket, og det refererer til en samling av typer og ressurser og tilknyttet obligatorisk buntinformasjon. Utvidelsesregisteret er den nye formen for plugin-register, og det inneholder bare informasjon om utvidelser og utvidelsespunkter. APIet for utvidelsesregisteret er stort sett det samme som det relevante APIet for plugin-registeret (du finner mer informasjon under Registre).

I Eclipse 2.x-kjøretiden har plugin-objektet flere roller og ansvarsområder:

I Eclipse 3.0-kjøretiden faktoriseres disse rollene og ansvarsområdene til distinkte objekter.

Bunt
Bunter er OSGi-enheten for modularitet. Det finnes en klasselaster per bunt, og det er mulig å konstruere diagrammer over klasselastingsavhengighet i Eclipse-bunter. Bunter har livssykluser for start og stopp, og OSGi-rammeverket kringkaster buntrelaterte hendelser (for eksempel installer, behandle, start, stopp, avinstaller, ...) til interesserte parter. I motsetning til Plugin-klassen for Eclipse, er Bundle-klassen for OSGi ikke utvidbar. Det vil si at utviklere ikke har muligheten til å definere sin egen buntklasse.
BundleActivator
BundleActivator er et grensesnitt som er definert av OSGi-rammeverket. Hver bunt kan definere en buntaktivatorklasse på en måte som likner på hvordan en plugin-modul definerer sin Plugin-klasse. Rammeverket oppretter en forekomst av den oppgitte klassen, og den brukes til å implementere behandlingen av livssyklusen for start() og stop(). Det er imidlertid en viktig forskjell i naturen for denne livssyklusbehandlingen. I Eclipse er det vanlig (selv om det ikke anbefales) at Plugin-klassene utfører både initialisering og registrering. I OSGi kan aktivatorene bare utføre registrering. Store mengder initialiseringer (eller annet arbeid) i BundleActivator.start() truer systemets levetid.
BundleContext
BundleContext er OSGi-mekanismen for eksponering av generelle systemfunksjoner til individuelle bunter. Hver bunt har en unik og privat forekomst av BundleContext som de kan bruke til å få tilgang til systemfunksjoner (for eksempel getBundles() for å oppdage alle buntene på systemet).
Plugin
Den nye Plugin er svært lik den opprinnelige Plugin-klassen for Eclipse, men med disse unntakene: Plugin-objekter er ikke lenger nødvendige for eller styrt av kjøretiden, og forskjellige metoder er foreldet. Dette er hovedsakelig en hendig mekanisme som gir en vert nyttige funksjoner og mekanismer, men den er ikke lenger absolutt nødvendig. Mye av funksjonaliteten er også tilgjengelig i Platform-klassen i kjøretiden.

Plugin implementerer også BundleActivator. Den gjenkjenner fordelen med å ha ett sentralt objekt som representerer livssyklusen og semantikken for en plugin-modul. Du bør imidlertid være oppmerksom på at dette ikke sanksjonerer den stadige initialiseringen av datastrukturer som er vanlig i plugin-moduler i dag. Vi kan ikke fremheve sterkt nok at plugin-moduler kan aktiveres på grunn av at det blir referert til en noe perifer klasse under verifiseringen av en klasse i en annen plugin-modul. Det vil si at selv om plugin-modulen blir aktivert, betyr det ikke nødvendigvis at funksjonen er nødvendig. Vær også oppmerksom på at du kan definere en annen BundleActivator-klasse, eller at du ikke trenger å ha en buntaktivator i det hele tatt.

Trinnene som er nødvendig for å portere Plugin-klasse for 2.x til Eclipse 3.0, avhenger av hva klassen gjør. Som beskrevet ovenfor tilhører det meste av livssyklusarbeidet for oppstart en av disse kategoriene:

Initialisering
Initialisering av datastrukturer og modeller blir ofte utført i Plugin.startup(). Den naturlige/åpenbare tilordningen vil være å gjøre dette arbeidet i en BundleActivator.start(), det vil si å forlate funksjonen i Plugin. Dette frarådes på det sterkeste. Som med plugin-moduler fra 2.x, kan plugin-moduler/bunter for 3.0 startes av mange forskjellige årsaker i mange forskjellige omstendigheter.
Et faktisk eksempel fra Eclipse 2.0 belyser dette tilfellet. Det fantes en plugin-modul som initialiserte en stor modell som krevde innlasting av ca. 11 MB kode og mange MB data. Det fantes svært vanlige scenarier der denne plugin-modulen ble aktivert for å finne ut om prosjektikonet som ble presentert i navigatoren, skulle dekoreres med en bestemt koding. Denne testen krevde ikke at noe av initialiseringen ble gjort i startup(), men likevel måtte alle brukere, i alle scenarier, betale minne- og tidsbelastningen for denne stadige initialiseringen.
Den alternative tilnærmingen er å utføre slik initialisering i en klassisk, lat stil. I stedet for å initialisere modeller når plugin-modulen/bunten er aktivert, kan det for eksempel gjøres når det faktisk er behov for dem (for eksempel i en sentralisert modells aksessormetode). For mange scenarier vil dette bety nesten det samme tidspunktet, men for andre scenarier vil denne tilnærmingen utsette initialiseringen (kanskje uendelig). Vi anbefaler at du tar deg god tid når du porterer plugin-moduler fra 2.1, slik at du kan vurdere hvilken strategi du vil bruke.
Registrering
Oppstarten for plugin-modulen er et passende tidspunkt til å registrere lyttere, tjenester og annet, og til å starte bakgrunnsbehandling av tråder (som for eksempel lytter på en socket). Plugin.start() kan være et fornuftig sted å gjøre dette arbeidet på. Det kan også være lurt å utsette en annen utløser til senere (for eksempel bruken av en bestem funksjon eller et bestemt dataelement).
Globale plugin-data
Plugin-klassen kan fortsette å spille denne rollen. Hovedsaken er at Plugin-objekter ikke lenger er globalt tilgjengelige via en systemstyrt liste. I Eclipse 2.x kunne du finne en hvilken som helst plugin-moduls Plugin-objekt via plugin-registeret. Dette er ikke lenger mulig. I de fleste tilfeller er denne typen tilgang ikke nødvendig. Plugin-moduler det blir gitt tilgang til via registeret, blir vanligvis brukt som generiske plugin-moduler i stedet for å sende kall til domenespesifikke metoder. Det tilsvarende nivået av funksjonalitet kan oppnås ved å få tilgang til og endre de tilsvarende buntobjektene.

Registre og plugin-modellen

I den nye kjøretiden er det et skille mellom informasjonen og strukturene som trengs for å utføre en plugin-modul, og som er relatert til en plugin-moduls utvidelser og utvidelsespunkter. Den første delen defineres og styres spesifikasjonen av OSGi-rammeverket. Den andre delen er Eclipse-spesifikke konsepter og er tilføyd av koden for Eclipse-kjøretiden. Det opprinnelige plugin-registeret og de relaterte objektene er delt i henholdsvis OSGi-bunter og Eclipses utvidelsesregister.

De delene av IPluginRegistry som gjelder utføringsspesifikasjon (for eksempel IPluginDescriptor, ILibrary, IPrequisite) er foreldet, og de resterende delene som gjelder utvidelser og utvidelsespunkter, er flyttet til IExtensionRegistry. Videre er de såkalte modellobjektene som er knyttet til plugin-registeret, nå foreldet i sin helhet. Det ble opprettet forekomst av disse typene og de ble presentert av kjøretiden hovedsakelig for å støtte verktøy som PDE. Uheldigvis skjedde det ofte at det nødvendige informasjonsnivået overskred kjøretidens funksjonalitet eller interesser (for eksempel huske linjenumre for plugin.xml-elementer), og til sist måtte de potensielle konsumentene av kjøretidens informasjon vedlikeholde sine egne strukturer likevel.

I den nye kjøretiden har vi revurdert kjøretidens funksjoner, og leverer nå bare de som enten er viktige for kjøretidsutføring eller er svært vanskelige for andre å utføre. Som nevnt ovenfor, er både plugin-registerets modellobjekter og analyse-APIet for plugin-moduler foreldet. Det nye utvidelsesregisteret vedlikeholder den viktigste utvidelsesrelaterte informasjonen. En ny state-struktur (se org.eclipse.osgi.service.resolver.State og venner) som representerer og tillater endringen av den viktigste utføringsrelaterte informasjonen.

NL-fragmentstruktur

I Eclipse 3.0 er NL-fragmentstrukturen oppdatert til å bli mer konsistent. Tidligere ble det antatt at oversettelser av filer som plugin.properties fantes i JAR-filer som leveres av fragmenter. Siden de opprinnelige filene ligger i roten av den relevante verts-plugin-modulen, vil en mer konsistent plassering få de oversatte filene plassert i roten av NL-fragmentene. Eksempel:

  org.eclipse.ui.workbench.nl/
     fragment.xml
     plugin_fr.properties
     plugin_pt_BR.properties
     ...
     nl1.jar

Vær oppmerksom på at filen nl1.jar tidligere inneholdt oversettelsene av plugin.properties. Disse filene ligger nå i roten av fragmentet, og JAR-filen inneholder oversettelser av eventuelle oversettbare ressurser (det vil si filer som lastes inn via klasselasteren) i verts-plugin-modulen.

NL-fragmentstrukturen fra Eclipse 2.1 støttes selvsagt fremdeles for plugin-moduler fra 2.1 som kjøres i Eclipse 3.0. Du kan imidlertid ikke bruke et NL-fragment fra 2-1 i en 3.0-plugin. Fragmentet må oppdateres til den nye strukturen.

Oversikt over API-endringer

org.eclipse.core.boot (pakken org.eclipse.core.boot)

Hele org.eclipse.core.boot-pakken er foreldet. BootLoader er slått sammen med org.eclipse.core.runtime.Platform fordi det ikke lenger virker fornuftig å ha en deling mellom oppstart og kjøretid. Vær oppmerksom på at plugin-modulen org.eclipse.core.boot faktisk er delt opp, og all koden er flyttet til enten den nye kjøretiden eller kompatibilitetslaget.

IPlatformConfiguration har alltid vært en type som er definert av og for Eclipse-komponenten Installer/oppdater. Ved hjelp av omorganiseringen av kjøretiden kan vi plassere denne typen der den hører hjemme. Denne klassen forblir stort sett uendret, og den er ompakket som org.eclipse.update.configurator.IPlatformConfiguration.

IPlatformRunnable er flyttet til org.eclipse.core.runtime.IPlatformRunnable.

IExtension og IExtensionPoint (pakken org.eclipse.core.runtime)

Metoden getDeclaringPlugin() (i begge klasser) gir en link oppover til plugin-modulen som deklarerer utvidelsen eller utvidelsespunktene (henholdsvis). Den nye registermodellen skiller utvidelsesaspektet for plugin-moduler fra utvidelses-/utvidelsespunktaspektene, og inneholder ikke lenger IPluginDescriptors. Brukere av dette APIet bør vurdere den nye metoden getParentIdentifier(), som finnes for både IExtension og IExtensionPoint.

ILibrary, IPluginDescriptor, IPluginRegistry og IPrerequisite (pakken org.eclipse.core.runtime)

I den opprinnelige kjøretiden vedlikeholdt plugin-registeret et fullstendig bilde av kjøretidskonfigurasjonen. I Eclipse 3.0 er dette bildet delt på OSGi-rammeverket og utvidelsesregisteret. Disse klassene er foreldet. Foreldelsesmerknadene inneholder detaljert informasjon om hvordan du kan oppdatere koden.

Plattform og plugin-modul (pakken org.eclipse.core.runtime)

I den nye kjøretiden styres ikke Plugin-objekter lenger av kjøretiden, og det er dermed ikke mulig å få generisk tilgang til dem via plattformen. På liknende måte finnes ikke plugin-registeret lenger eller det gir ikke tilgang til plugin-deskriptorer. Det finnes imidlertid passende erstatningsmetoder som er beskrevet i Javadoc for de foreldede metodene i disse klassene.

org.eclipse.core.runtime.model (pakken org.eclipse.core.runtime.model)

Alle typene i denne pakken blir nå foreldet. Du finner mer informasjon i diskusjonen om registre.

IWorkspaceRunnable og IWorkspace.run (pakken org.eclipse.core.resources)

Klienter av metoden IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) bør gå tilbake til denne metoden igjen, og vurdere å bruke den mer omfattende metoden IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). Den gamle IWorkspace.run-metoden låser hele arbeidsområdet i hele varigheten av IWorkspaceRunnable. Dette betyr at en operasjon som er utført med denne metoden, aldri vil kunne kjøre samtidig med andre operasjoner som endrer arbeidsområdet. I Eclipse 3.0 kan mange operasjoner med lang kjøretid være flyttet til bakgrunnstråder, slik at sannsynligheten for konflikter mellom operasjoner økes betraktelig. Hvis en modal forgrunnsoperasjon er blokkert av en bakgrunnsoperasjon med lang kjøretid, blir brukergrensesnittet blokkert til bakgrunnsoperasjonen er fullført, eller til en av operasjonene avbrytes.

Den foreslåtte løsningen er å endre alle referanser til den gamle IWorkspace.run til å bruke den nye metoden med en planleggingsregelparameter. Planleggingsregelen bør være den mest finkornede regelen som omfatter reglene for alle endringer av denne operasjonen. Hvis operasjonen prøver å endre ressurser utenfor planleggingsregelens omfang, oppstår et kjøretidsunntak. Nøyaktig hvilken planleggingsregel som kreves av en gitt operasjon, oppgis ikke, og det kan endres avhengig av leverandøren av det installerte datalageret for et gitt prosjekt. IResourceRuleFactory-factory bør brukes til å hente planleggingsregelen for en ressursendrende operasjon. Hvis det er ønskelig, kan en MultiRule brukes til å oppgi flere ressursregler, og metoden MultiRule.combine kan brukes til å kombinere regler fra forskjellige ressursendrende operasjoner.

Hvis det ikke er nødvendig med en lås, kan en null-planleggingsregel brukes. Dette vil gjøre at den kjørbare kan endre alle ressurser i arbeidsområdet, men det vil ikke hindre at andre tråder også endrer det samtidig. Hvis du skal gjøre enkle endringer i arbeidsområdet, er dette ofte den enkleste og mest samtidighetsvennlige løsningen.

IWorkbenchPage (pakken org.eclipse.ui)

IEditorDescriptor (pakken org.eclipse.ui)

ISharedImages (pakken org.eclipse.ui)

IWorkbenchActionConstants (pakken org.eclipse.ui)

IWorkbenchPreferenceConstants (pakken org.eclipse.ui)

IExportWizard (pakken org.eclipse.ui)

IImportWizard (pakken org.eclipse.ui)

INewWizard (pakken org.eclipse.ui)

WorkbenchHelp (pakken org.eclipse.ui.help)

IHelp (pakken org.eclipse.help)

ITextEditorActionConstants (pakken org.eclipse.ui.texteditor)

IAbstractTextEditorHelpContextIds (pakken org.eclipse.ui.texteditor)

BasicTextEditorActionContributor (pakken org.eclipse.ui.texteditor)

TextEditorActionContributor (pakken org.eclipse.ui.editors.text)

Utvidelsespunktet annotationTypes (plugin-modulen org.eclipse.ui.editors)

Annotasjonstype er nå et eksplisitt begrep. Se Annotation.getType() og Annotation.setType(). En annotasjonstype kan bli endret i løpet av annotasjonens levetid. Det er lagt til et nytt utvidelsespunkt for deklareringen av annotasjonstyper: org.eclipse.ui.editors.annotationTypes. En annotasjonstype har et navn og kan deklareres som en subtype av en annen deklarert annotasjonstype. En annotasjonstypedeklarasjon kan også bruke attributtene markerType og markerSeverity til å oppgi at merker av en gitt type og med en gitt alvorsgrad skal representeres i tekstredigeringsprogrammer som annotasjoner av en bestemt annotasjonstype. Attributtene markerType og markerSeverity i org.eclipse.ui.editors.markerAnnotationSpecification skal ikke lenger brukes. Spesifikasjoner av merkeannotasjoner blir derved uavhengig av merker, og navnet er derfor villedende. Navnet blir imidlertid beholdt for å sikre tilbakekompatibilitet.

Forekomster av subklasser av AbstractMarkerAnnotationModel oppdager og definerer automatisk de riktige annotasjonstypene for annotasjoner de oppretter fra merker. Når du skal hente annotasjonstypen programmatisk for et gitt merke eller et gitt par av markerType og markerSeverity, bruker du org.eclipse.ui.texteditor.AnnotationTypeLookup.

Tilgang til hierarkiet av annotasjonstyper gis av IAnnotationAccessExtension. For en gitt annotasjonstype kan du hente kjeden av supertyper og kontrollere om en annotasjonstype er en subtype av en annen annotasjonstype. DefaultMarkerAnnotationAccess implementerer dette grensesnittet.

Utvidelsespunktet markerAnnotationSpecification (plugin-modulen org.eclipse.ui.editors)

Annotasjonstypen er nøkkelen som brukes til å finne den tilknyttede merkeannotasjonsspesifikasjonen. Siden annotasjonstyper kan utvide andre annotasjonstyper, finnes det også et implisitt forhold mellom merkeannotasjonsspesifikasjoner. Derfor fullføres en merkeannotasjonsspesifikasjon for en gitt annotasjonstype av merkeannotasjonsspesifikasjonene som er gitt for supertypene av den gitte annotasjonstypen. Merkeannotasjonsspesifikasjonen trenger derfor ikke å være fullstendig slik den måtte tidligere. Merkeannotasjonsspesifikasjoner hentes av AnnotationPreferences. Ved hjelp av org.eclipse.ui.texteditor.AnnotationPreferenceLookup kan du hente en annotasjonspreferanse for en gitt annotasjonstype som transparent utfører fullføringen av preferansen sammen med supertypekjeden for annotasjonen.

En merkeannotasjonsspesifikasjon er utvidet med tre tilleggsattributter slik at det blir mulig å definere tilpassede utseender for en gitt annotasjonstype i den loddrette linjalen. Disse attributtene er "icon", "symbolicIcon" og "annotationImageProvider". Verdien for "icon" er banen til en fil som inneholder ikonbildet. Verdien for "symbolicIcon" kan være en av "error", "warning", "info", "task" eller "bookmark". Attributtet "symbolicIcon" brukes til å fortelle plattformen at annotasjonen skal bruke de samme bildene som de som brukes av plattformen til å presentere henholdsvis feil, advarsler, info, oppgaver og bokmerker. Verdien for "annotationImageProvider" er en klasse som implementerer org.eclipse.ui.texteditor.IAnnotationImageProvider som tillater presentasjon av en fullstendig tilpasset annotasjon.

Den loddrette linjalen bruker den tilknyttede IAnnotationAccess/IAnnotationAccessExtension til å tegne annotasjoner. Den loddrette linjalen sender ikke lenger kall til Annotation.paint. Generelt sett skal annotasjoner ikke lenger tegne seg selv. Metodene "paint" og "getLayer" er foreldet fordi det er meningen at annotasjoner skal bli uavhengige av brukergrensesnitt. DefaultMarkerAnnotationAccess tjener som standardimplementering av IAnnotationAccess/IAnnotationAccessExtension. DefaultMarkerAnnotationAccess implementerer den følgende strategien for tegning av annotasjoner: Hvis en annotasjon implementerer IAnnotationPresentation, sendes det kall til IAnnotationPresentation.paint. Hvis ikke, blir det slått opp på annotasjonsbildeleverandøren i annotasjonspreferansene. Annotasjonsbildeleverandøren er bare tilgjengelig hvis den er oppgitt, og hvis plugin-modulen som definerer den innkapslende merkeannotasjonsspesifikasjonen, allerede er lastet inn. Hvis det finnes en annotasjonsbildeleverandør, blir kallet videresendt til denne. Hvis ikke, blir det slått opp på det oppgitte "icon". "symbolicIcon" brukes som en siste reserve. Annotasjonspresentasjonslaget er relevant til tegning av annotasjoner. DefaultMarkerAnnotationAccess slår opp presentasjonslaget ved hjelp av den følgende strategien: Hvis annotasjonspreferansen oppgir et presentasjonslag, blir det oppgitte laget brukt. Hvis det ikke finnes noe lag og annotasjonen implementerer IAnnotationPresentation, brukes IAnnotationPresentation.getLayer. I andre tilfeller returneres standard presentasjonslag (som er 0).

Migrere til utvidelsespunktet annotationTypes (plugin-modulen org.eclipse.ui.editors)

De følgende annotasjonstypene deklareres av plugin-modulen org.eclipse.ui.editors:

   <extension point="org.eclipse.ui.editors.annotationTypes">
      <type
         name="org.eclipse.ui.workbench.texteditor.error"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="2">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.warning"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="1">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.info"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="0">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.task"
         markerType="org.eclipse.core.resources.taskmarker">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.bookmark"
         markerType="org.eclipse.core.resources.bookmark">
      </type>
   </extension>

Den definerte utvidelsen markerAnnotationSpecification har ikke lenger attributtene markerType og markerSeverity. De definerer attributtet symbolicIcon med den tilsvarende verdien. Derfor blir det ikke lenger sendt kall til MarkerAnnotation.paint og MarkerAnnotation.getLayer, noe som betyr at overstyring av disse metodene ikke lenger har noen virkning. Påvirkede klienter bør implementere IAnnotationPresentation.

ILaunchConfigurationType (pakken org.eclipse.debug.core)

Med introduksjonen av utvidbare oppstartsmoduser i 3.0, kan det finnes mer enn en oppstartsdelegat for en oppstartskonfigurasjonstype. Utgaver før 3.0 støttet bare en oppstartsdelegat per oppstartskonfigurasjonstype. Metoden ILaunchConfigurationType.getDelegate() er foreldet. Metoden getDelegate(String mode) kan i stedet brukes til å hente oppstartsdelegaten for en bestemt oppstartsmodus. Den foreldede metoden er endret til å returnere oppstartsdelegaten for modusen run.

ILaunchConfigurationTab og ILaunchConfigurationTabGroup (pakken org.eclipse.debug.ui)

Oppstartsflippgrupper og oppstartsflipper blir ikke lenger varslet når en oppstart er fullført. Metoden launched(ILaunch) i grensesnittene ILaunchConfigurationTab og ILaunchConfigurationTabGroup er foreldet, og det blir ikke lenger sendt kall til dem. Avhengigheten av denne metoden for oppstartsfunksjon var alltid problematisk, fordi det bare finnes flipper når oppstarten blir utført fra oppstatsdialogboksen. I tillegg kan det ikke lenger sendes kall til denne metoden etter introduksjonen av bakgrunnsoppstart, fordi oppstartsdialogboksen blir lukket før det resulterende oppstartsobjektet finnes.

ILaunchConfigurationTab og AbstractLaunchConfigurationTab (pakken org.eclipse.debug.ui)

Det er lagt til to metoder i grensesnittet ILaunchConfigurationTab - aktivert og deaktivert. Det blir sendt kall til disse nye livssyklusmetodene når det blir gått henholdsvis inn på og ut av en flipp. Eksisterende implementeringer av ILaunchConfigurationTab som subklassifiserer den abstrakte klassen som er levert av plugin-modulen for feilsøking (AbstractLaunchConfigurationTab), er binært kompatible fordi metodene blir implementert i den abstrakte klassen.

I tidligere utgaver ble meldingen initializeFrom sendt til en flipp når den ble aktivert, og meldingen performApply når den ble deaktivert. På denne måten leverte oppstartskonfigurasjonsflippen kommunikasjon mellom flippene via en oppstartskonfigurasjon (ved å oppdatere konfigurasjonen med gjeldende attributtverdier når det blir gått ut av en flipp, og oppdatere flippen det nylig ble gått inn i). Siden mange flipper ikke utfører kommunikasjon mellom flipper, kan dette imidlertid være ineffektivt. I tillegg var det ikke mulig å skille mellom en flipp som ble aktivert, og en flipp som viser en valgt oppstartskonfigurasjon for første gang. Med de nylig tilføyde metodene kan flippene skille mellom aktivering og initialisering, og deaktivering og lagring av gjeldende verdier.

Standardimplementeringen av activated, fra den abstrakte flippen, sender kall til initializeFrom. Og standardimplementeringen av deactivated sender kall til performApply. Flipper som ønsker å utnytte det nye APIet, bør overstyre disse metodene etter behov. For flipper som ikke utfører kommunikasjon mellom flipper, er den anbefalte metoden å implementere disse metodene på nytt slik at de gjør ingenting.

Utvidelsespunkttypen launchConfigurationTabGroup (pakken org.eclipse.debug.ui)

I tidligere utgaver ble perspektivveksling oppgitt i en oppstartskonfigurasjon, via oppstartskonfigurasjonsattributtene ATTR_TARGET_DEBUG_PERSPECTIVE og ATTR_TARGET_RUN_PERSPECTIVE. Med tilføyingen av utvidbare oppstartsmoduser i 3.0, utfører denne metoden ikke lenger skalering. Perspektivveksling blir nå oppgitt på oppstartskonfigurasjonstypebasis, per oppstartsmodus som en oppstartskonfigurasjonstype støtter. Det er tilføyd et API i DebugUITools for å definere og hente perspektivet som er knyttet til en oppstartskonfigurasjonstype for en bestemt oppstartsmodus.

I tillegg er det valgfrie launchMode-elementet lagt til i utvidelsespunktet launchConfigurationTabGroup, som tillater at en oppgitt flippgruppen kan oppgi et standardperspektiv for en oppstartskonfigurasjonstype og -modus.

Fra Eclipse-brukergrensesnittet kan brukerne redigere perspektivet som er knyttet til en oppstartskonfigurasjonstype, ved å åpne oppstartskonfigurasjonsdialogboksen og velge en oppstartskonfigurasjonstypenode i treet (i stedet for en individuell konfigurasjon). Det vises en flipp som tillater at brukeren definerer et perspektiv med hver støttede oppstartsmodus.

[Bare JDT] IVMRunner (pakken org.eclipse.jdt.launching)

Det er lagt til to metoder i klassen VMRunnerConfiguration som støtter definering og henting av miljøvariabler. Implementerere av IVMRunner skal sende kall til VMRunnerConfiguration.getEnvironment() og sende dette miljøet til den utførte JVM. Klienter som bruker DebugPlugin.exec(String[] cmdLine, File workingDirectory), kan gjøre dette ved å sende kall til DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp) i stedet. Innsending av resultatet fra getEnvironment() er tilstrekkelig.

[Bare JDT] Klassene VMRunnerConfiguration og Bootstrap (pakken org.eclipse.jdt.launching)

I tidligere utgaver hadde VMRunnerConfiguration ett attributt for å beskrive en oppstartsbane. Attributtet er en samling av Strings som skal oppgis i argumentet -Xbootclasspath. Det er lagt til tre nye attributter i VMRunnerConfiguration som støtter JVMer som tillater tilføying før og etter oppstartsbanen. Dette er de nye metodene/attributtene som er lagt til:

Det gamle attributtet getBootClassPath() finnes fremdeles, og det inneholder en fullstendig bane som tilsvarer den for de tre nye attributtene. VMRunners som støtter de nye oppstartsbanealternativene, bør imidlertid utnytte de nye attributtene.

[Bare JDT] Forbedret støtte for arbeidskopier (pakken org.eclipse.jdt.core)

Funksjonen for arbeidskopi av Java-modell er omarbeidet i 3.0 slik at den gir forbedret funksjonalitet. Før 3.0 tillot Java-modellen oppretting av individuelle arbeidskopier av kompileringsenheter. Endringer kan gjøres i arbeidskopien og iverksettes senere. Det var støtte for begrenset analyse av en arbeidskopi i konteksten av resten av Java-modellen. Disse endringene kunne imidlertid ikke ta hensyn til mer enn en av arbeidskopiene om gangen.

Ved hjelp av endringene i 3.0 er det mulig å opprette og administrere sett av arbeidskopier av kompileringsenheter, og å utføre analyser av ale arbeidskopiene i et sett. Nå er det for eksempel mulig for en klient som JDT-refaktorisering å opprette arbeidskopier for en eller flere kompileringsenheter som blir vurdert for endring, og deretter å behandle typereferanser mellom arbeidskopiene. Tidligere var dette bare mulig etter ar endringene i arbeidskopiene av kompileringsenheten var iverksatt.

Java-modellens API er endret på to måter for å legge til denne forbedrede støtten:

(1) Funksjonaliteten som tidligere ble funnet i IWorkingCopy og arvet av ICompilationUnit, er konsolidert til ICompilationUnit. Grensesnittet IWorkingCopy ble bare brukt på dette stedet, og det var mye mer generelt enn det trengte å være. Denne endringen forenkler APIet. IWorkingCopy er foreldet. Andre steder der IWorkingCopy blir brukt som en parameter eller resultattype, er også foreldet. De erstattende API-metodene nevner ICompilationUnit i stedet for IWorkingCopy.

(2) Grensesnittet IBufferFactory er erstattet av WorkingCopyOwner. Den forbedrede støtten for arbeidskopier krever at det finnes et objekt som eier arbeidskopiene. Selv om IBufferFactory er på riktig sted, formidler ikke navnet tilstrekkelig hvordan den nye arbeidskopimekanismen fungerer. WorkingCopyOwner er et mer beskrivende navn. I tillegg er WorkingCopyOwner deklarert som en abstrakt klasse, i stedet for som et grensesnitt, slik at begrepet arbeidskopieier kan bli brukt i fremtiden. Den ene metoden i IBufferFactory flyttes til WorkingCopyOwner uten endring. WorkingCopyOwner implementerer ikke IBufferFactory, dette gjør det klart at IBufferFactory er noe som tilhører fortiden. IBufferFactory er foreldet. Andre steder i APIet der IBufferFactory vises som en parameter eller resultattype, er også foreldet. De erstattende API-metodene nevner WorkingCopyOwner i stedet for IBufferFactory.

Disse endringene bryter ikke den binære kompatibiliteten.

Ved migrering bør alle referanser til typen IWorkingCopy i stedet referere til ICompilationUnit. Den eneste implementeringen av IWorkingCopy, implementerer ICompilationUnit også. Det betyr at objekter av typen IWorkingCopy trygt kan overføres til ICompilationUnit.

En klasse som implementerer IBufferFactory, må erstattes av en subklasse av WorkingCopyOwner. Selv om WorkingCopyOwner ikke implementerer selve IBufferFactory, vil det være mulig å deklarere subklassen av WorkingCopyOwner som implementerer IBufferFactory og derved oppretter en bro mellom gamle og nye (IBufferFactory deklarerer createBuffer(IOpenable), mens WorkingCopyOwner deklarerer createBuffer(ICompilationUnit). ICompilationUnit utvider IOpenable).

Siden endringene som omfatter IWorkingCopy og IBufferFactory, er griper inn i hverandre, anbefales det at du behandler begge samtidig. Dette er detaljene for foreldelsen:

Restrukturering av plugin-modulen org.eclipse.help

Plugin-modulen org.eclipse.help, som brukes til å oppbevare APIer og utvidelsespunkter som bidrar til og utvider hjelpesystemer, i tillegg til å vise hjelp, inneholder nå bare APIer og utvidelsespunkter som bidrar og gir tilgang til hjelperessurser. En del av standardimplementeringen av brukergrensesnittet for hjelp som ligger i plugin-modulen, er flyttet til den nye plugin-modulen org.eclipse.help.base sammen med APIer for utvidelse av implementeringen. APIene og utvidelsespunktet for bidrag til brukergrensesnittet for hjelp og for å vise hjelp er flyttet til plugin-modulen org.eclipse.ui. Denne omstruktureringen gir applikasjonene større fleksibilitet når det gjelder hjelpefunksjonen. Den nye strukturen gjør at applikasjoner som er basert på den generiske arbeidsbenken, kan ha sine egne brukergrensesnitt for hjelp og/eller hjelpeimplementeringer, eller utelate hjelpefunksjonen fullstendig.

Siden de påvirkede utvidelsespunktene og API-pakkene bare er beregnet på å bli brukt av selve hjelpefunksjonen, er det usannsynlig at eksisterende plugin-moduler blir påvirket av denne endringen. De er bare tatt med her for å gjøre det hele komplett:

Nytt API for søk i brukergrensesnittet

Et nytt API for implementering av tilpassede søk er lagt til i 3.0. Det opprinnelige APIet er foreldet i 3.0, og det anbefales at klienter porterer det nye APIet i pakkene org.eclipse.search.ui og org.eclipse.search.ui.text.

Klienter må opprette implementeringer av ISearchQuery, ISearchResult og ISearchResultPage. ISearchResultPage-implementeringen må deretter legges inn i det nye utvidelsespunktet org.eclipse.search.searchResultViewPages.

Standardimplementeringer for ISearchResult og ISearchResultPage leveres i pakken org.eclipse.search.ui.text.

Nullmeldinger i MessageBox and DirectoryDialog (pakken org.eclipse.swt.widgets)

Hvis det før 3.0 ble sendt kall til SWTs DirectoryDialog.setMessage(Streng streng) eller MessageBox.setMessage(Streng streng) med en nullverdi for streng, ville det resultere i en dialogboks uten tekst i tittelen. Denne virkemåten var uspesifisert (sending av null har aldri vært tillatt) og oppretter problemer med getMessage som ikke er tillatt for å returnere null. I 3.0 resulterer sending av null i at det oppstår et IllegalArgumentException-unntak, og spesifikasjonene er endret for å oppgi dette, noe som setter det på linje med metoden i superklassen Dialog.setMessage. Hvis du bruker Dialog.setMessage, må du forsikre deg om at strengen som sendes, aldri er null. Du kan sende en tom streng hvis du ønsker en dialogboks uten tekst i tittelen.

Forbedring av tilbakemelding om modal fremdrift

Støtte for samtidige operasjoner krever mer sofistikerte metoder for å vise modal fremdrift. Som en del av forsøket på å øke mottakeligheten er det implementert ekstra fremdriftsstøtte i klassen IProgressService. Den eksisterende måten å vise fremdrift på med ProgressMonitorDialog, fungerer fremdeles. For å forbedre brukererfaringen, anbefales imidlertid migrering til den nye IProgressService.

Dokumentet om å vise modal fremdrift i Eclipse 3.0 beskriver hvordan du migrerer til den nye IProgressService.

Feilsøking av handlingsgrupper er fjernet

Utvidelsespunktet for feilsøking av handlingsgrupper (org.eclipse.debug.ui.debugActionGroups) er fjernet. I Eclipse 3.0 introduserte arbeidsbenken støtte for aktiviteter via utvidelsespunktet org.eclipse.platform.ui.activities. Denne støtten sørger for all funksjonaliteten i feilsøkingen av handlingsgrupper, og den er også enklere å bruke (støtte for mønstre i stedet for at alle handlinger blir oppgitt fullstendig), og det finnes et programmatisk API som støtter dette. Hvis referanser til det gamle utvidelsespunktet ikke blir fjernet, medfører det ikke noen feil. Referanser til utvidelsespunktet blir ganske enkelt ignorert. Produktleverandører oppfordres til å bruke støtten for arbeidsbenkaktiviteter til å knytte språkspesifikke feilsøkingshandlinger til språkspesifikke aktiviteter (for eksempel kan feilsøkingshandlinger i C++ knyttes til en aktivitet kalt "Developing C++").

BreakpointManager kan deaktiveres

IBreakpointManager definerer nå metodene setEnabled(boolean) og isEnabled(). Når avbruddspunktstyreren er deaktivert, skal feilrettingsprogrammene ignorere alle registrerte avbruddspunkter. Feilsøkingsplattformen har også en ny lyttermekanisme, IBreakpointManagerListener, som tillater at klientene blir registrert hos avbruddspunktstyreren for å bli varslet når aktiveringen endres. Avbruddspunktvisningen sender kall til dette APIet fra en ny aktiver/deaktiver-handling som gjør at brukeren kan "hoppe over alle avbruddspunkter". Feilsøkere som ikke overholder avbruddspunktstyrerens aktivering, vil derved virke noe redusert hvis brukeren prøver denne funksjonen.

[Bare JDT] Java-søkedeltakere (pakken org.eclipse.jdt.core.search)

Språk som likner på Java for (for eksempel JSP, SQLJ, JWS) skal kunne delta i Java-søk. Spesielt skal de som implementerer slike språk, være i stand til å

En slik implementerer kalles en søkedeltaker. Den utvider klassen SearchParticipant. Søkedeltakere sendes til søkespørringer (se SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).

For enten indeksering eller søking etter samsvar må en søkedeltaker definere en subklasse av SearchDocument som kan hente innholdet i dokumentet ved å overstyre enten getByteContents() eller getCharContents(). En forekomst av denne subklassen retureneres i getDocument(String).

En søkedeltaker som ønsker å indeksere et eller annet dokument, bruker SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) til å planlegge indekseringen av det gitte dokumentet i den gitte indeksen. Når dokumentet er klart til å bli indeksert, sender det underliggende rammeverket kall til SearchParticipant.indexDocument(SearchDocument, IPath). Søkedeltakeren henter deretter dokumentets innhold, analyserer det og legger til indeksoppføringer ved hjelp av SearchDocument.addIndexEntry(char[], char[]).

Når indekseringen er fullført, er det mulig å sende spørringer på indeksene og finne samsvar ved hjelp av SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor). Den ber først hver deltaker om indeksene som er nødvendige for denne spørringen, ved hjelp av SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope). For hver indeksoppføring som samsvarer med det gitte mønsteret, blir det opprettet et søkedokument ved hjelp av søkedeltakeren (se getDocument(String)). Alle disse dokumentene blir sendt til søkedeltakeren slik at den kan finne samsvar ved hjelp av locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor). Søkedeltakeren varsler SearchRequestor om søkesamsvar ved hjelp av acceptSearchMatch(SearchMatch), og det blir sendt en forekomst av en subklasse av SearchMatch.

En søkedeltaker kan delegere en del av arbeidet til standard Java-søkedeltaker. En forekomst av denne standarddeltakeren oppnås ved hjelp av SearchEngine.getDefaultSearchParticipant(). Når en SQLJ-deltaker blir bedt om å finne samsvar, kan SQLJ-deltakeren opprette .java-dokumenter fra .sqlj-dokumentene og delegere arbeidet til standarddeltakeren ved å sende .java-dokumentene.