Endringer som kreves når du tar i bruk 3.2-mekanismer og -APIer

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

  1. Oppstartskonfigurasjoner
  2. Oppstartsmodi
  3. Internasjonale komponenter for Unicode for Java (ICU4J)
  4. Kjøretidseling

Oppstartskonfigurasjoner

Ressurstilordning for oppstartskonfigurasjoner

Eclipse 3.2 har ny infrastruktur for tilknytning mellom oppstartskonfigurasjoner og ressurser. Denne tilordningen gjør det mulig for plattformen å utføre ressursbasert filtrering av oppstartskonfigurasjoner, og gjør det mulig for plattformen eventuelt å slette oppstartskonfigurasjoner når et tilknyttet prosjekt slettes. Oppstartsdialogboksen er forbedret så den støtter et sett med filtre som kan skjule konfigurasjoner som er knyttet til låste og slettede prosjekter. Oppstartsdialogboksen støtter også filtrering basert på valgte arbeidssett i det aktive arbeidsbenkvinduet, som også kan velges i oppstartsdialogboksen.

Det er klientens ansvar å administrere ressurstilordningen for oppstartskonfigurasjoner. Det er lagt til et API i ILaunchConfigurationWorkingCopy for å definere hvilke ressurser som er knyttet til en konfigurasjon, og et API i ILaunchConfiguration for å hente ressursen som er knyttet til en konfigurasjon. Du bør for eksempel vurdere oppstartsflipper, oppstartssnarveier og refaktoriseringsdeltakere når du migrerer. Kode som oppretter eller endrer oppstartskonfigurasjoner, bør også oppdatere ressurstilordninger.

Migreringsstøtte for oppstartskonfigurasjoner

Eclipse 3.2 har ny infrastruktur for migrering av oppstartskonfigurasjoner som er kompatible med de nye verktøyene. I Eclipse 3.2 er det for eksempel lagt til støtte for å utføre ressursbasert filtrering av oppstartskonfigurasjoner. Oppstartskonfigurasjoner må oppgraderes for å sørge for ressurstilordninger som tar i bruk denne nye funksjonen. Brukerne kan migrere oppstartskonfigurasjonene manuelt i sitt arbeidsområde fra preferansesiden Kjør/feilsøk > Oppstart > Oppstartskonfigurasjoner ved å klikke på knappen Migrer.

Et nytt valgfritt delegatattributt for migrering er lagt til i utvidelsespunktet launchConfigurationTypes og spesifiserer en klasse som implementerer det nye grensesnittet ILaunchConfigurationMigrationDelegate. Et migreringsdelegat er ansvarlig for å identifisere migreringskandidater og migrere dem.

Oppstartsmodi

Et nytt valgfritt attributt er lagt til i uvidelsespunktet launchModes for å støtte eksternaliseringen av overlappende handlingsetiketter for startmenyer. Klienter som bidrar med oppstartsmodi, må spesifisere riktig etikett til bruk for overlappende startmenyer som f.eks. "Kjør som". Det nye attributtet heter launchAsLabel. Riktige etiketter besørges av plattformen for kjørings-, feilsøkings- og profilstartingsmodi. For bakoverkompatibilitet når det nye attributtet ikke er spesifisert for en oppstartsmodus, genereres overlappende menyetiketter som før via MessageFormat med "{0} As". Se beslektet programfeil 105235.

Internasjonale komponenter for Unicode for Java (ICU4J)

ICU4J er et sett av Java-biblioteker som gir mer omfattende støtte til Unicode, programvareglobalisering og internasjonalisering. ICU4J ble lagt til i plattformbyggingen for Eclipse 3.2 for å kunne levere denne funksjonaliteten til Eclipse-fellesskapet. Du ser det i byggingen som en plugin-modul med navnet com.ibm.icu. Eclipse-plattformen bruker ICU-APIer i Eclipse 3.2.

Migrering

Migrering av applikasjonskode kan gjøres trinnvist, noe som betyr at fullstendig adoptering av hele ICU4J-funksjonen ikke er nødvendig for å kunne utnytte alle fordelene ved å bruke ICU4J. Se ICU4J-siden i Eclipse wiki hvis du vil vite mer om hvordan du migrerer koden til å kunne bruke ICU4J.

Erstatningsplugin-modul for ICU4J

Tilføyingen av plugin-modulen ICU4J legger til ca. 3 MB i størrelsen. Noen applikasjoner ønsker kanskje ikke å bruke ICU4J hvis applikasjonsstørrelse er viktigere enn ICU4J-funksjonene. Hvis det er tilfellet, er en erstatningsplugin-modul (com.ibm.icu.base) tilgjengelig fra Eclipse-plattformens byggeside. Last ned plugin-modulen, fjern plugin-modulen com.ibm.icu og kildemotstykkene fra katalogen /plugins, og slipp erstatningsplugin-modulen. Dette er nødvendig fordi Eclipse-plattformen adopterte ICU-APIene for 3.2, så hvis du bare fjerner plugin-modulen ICU, vil det resultere i kompileringsfeil i plattformkoden. Erstatningen for plugin-modulen har en størrelse på ca. 100 kB, og den sender ganske enkelt kall til standard JDKs implementering av de mest brukte klassene og APIene i ICU4J. Du kan lese ICU4J-siden i Eclipse wiki hvis du vil vite mer om hvordan du bruker erstatningen av ICU-plugin-modulen.

Virkning for JFace - ViewerSorter og StructuredViewer

For å kunne støtte ICU4J i JFace, var det nødvendig med noen kreative API-tillegg for å hindre referanser til ICU-klasser i API. Dette resulterte i tillegg av det følgende:

  1. En ny klasse med navnet org.eclipse.jface.viewers.ViewerComparator, som nå har org.eclipse.jface.viewers.ViewerSorter som en subklasse.
  2. To nye metoder i org.eclipse.jface.viewers.StructuredViewer, for å støtte tilføyingen av org.eclipse.jface.viewers.ViewerComparator.

Begrunnelse

Klassen ViewerSorter har fellesmetoden getCollator() som returnerer en java.text.Collator. Siden denne metoden er API, kan det ikke endres til å bruke en ICU-sorterer. ICU-klasser kan heller ikke være en del av APIet (signaturer) fordi en direkte plugin-avhengighet av ICU ville hindre at JFace blir brukt frittstående (med SWT). For å imøtekomme disse begrensningene, ble ViewerComparator-klassen som bruker en java.util.Comparator, i stedet for en ICU-sorterer, lagt til. Dette ble gjort fordi ICUs sortererklassse implementerer java.util.Comparator, så en hvilken som helst StructuredViewer kan nå bruke ICUs sorterer i stedet for java.text.Collator, ment JFace trenger ikke å legge til en avhengighet av plugin-modulen ICU4J. De to nye metodene som er lagt til i StructuredViewer, støtter bruk av ICUs sorterer for å sortere innholdet i visningsprogrammet via en ViewerComparator, i stedet for en ViewerSorter. Det anbefales at en hvilken som helst StructuredViewer nå bruker disse metodene for å hente/definere visningsprogrammets sorterer (sammenlikner), i stedet for metodene getSorter() og setSorter(ViewerSorter).

Kjøretidseling

Nye kjøretids-APIer

Bunten org.eclipse.equinox.common inkluderer flere nye API-klasser (f.eks. Assert og ListenerList) som har fellesnavn. vis koden har en klasse med samme navn og brukerne importerer * setninger for å importere både den lokale klassen og klasser fra kjøretid, kan du få følgende feilmelding:

Typen ABC er tvetydig
  

Organisering av import og valg av riktig importkilde skille løse dette problemet.

Eksplisitte klassebaner i tilpassede byggeskripter

Som følge av at koden flyttes til nye kjøretids-plugin-moduler, kan tilpassede skripter som eksplisitt refererer til org.eclipse.core.runtime, ha behov for legge til en eller flere av følgende plugin-moduler: