I dette afsnit beskrives de ændringer, der er nødvendige, hvis du forsøger at ændre din 3.1-plugin, så den kan benytte 3.2-mekanismer og -API'er.
Eclipse 3.2 indeholder ny infrastruktur for tilknytning af Startkonfigurationer til ressourcer. Denne mapping tillader platformen at udføre ressourcebaseret filtrering på startkonfigurationer og tillade platformen evt. at slette startkonfigurationer, når et tilknyttet projekt slettes. Startdialogboksen er udvidet til at understøtte et sæt filtre for evt. at skjule konfigurationer, der er knyttet til lukkede eller slettede projekter. Ligeledes understøtter startdialogboksen filtrering baseret på valgte arbejdssæt i det aktive arbejdsbænkvindue, som også kan vælges i startdialogboksen.
Det er klientens ansvar at administrere ressourcemapping for startkonfigurationer. Et API er tilføjet til
ILaunchConfigurationWorkingCopy
for at angive ressourcer, der er knyttet til en konfiguration, og API'et er føjet til ILaunchConfiguration
for at få ressourcerne knyttet til en konfiguration. Der skal f.eks. tages hensyn til startskilleblade, startgenveje og refactoring-deltagere ved overførsel. Kode, der opretter eller ændrer startkonfigurationer skal også opdatere ressourcetilknytninger vha. mapping.
Eclipse 3.2 indeholder ny infrastruktur for overførsel af startkonfigurationer, så de er kompatible med nye værktøjer.
F.eks. er der i Eclipse 3.2 tilføjet understøttelse til at anvende ressourcebaseret filtrering på startkonfigurationer.
Startkonfigurationer skal opgraderes til at stille ressourcetilknytninger vha. mapping til rådighed for at anvende denne nye funktion. Brugere kan manuelt overføre startkonfigurationer i deres arbejdsområde fra indstillingssiden
Udfør/fejlfinding > Starter > Startkonfigurationer ved at trykke på knappen Overfør.
En ny valgfri delegeringsattribut for overførsel er føjet til udvidelsespunktet launchConfigurationTypes
og angiver en klasse, der implementerer den nye grænseflade ILaunchConfigurationMigrationDelegate
.
En overførselsdelegering er ansvarlig for identifikation af overførselskandidater og overførslen af dem.
En ny valgfri attribut er føjes til udvidelsespunktet launchModes
for at understøtte eksternaliseringen af etiketter for funktioner for startkaskademenu. Klienter, der leverer starttilstande, skal angive den korrekte etiket, der skal bruges til startkaskademenuer som "Udfør som". Den nye attribut kaldes launchAsLabel
. Korrekte etiketter er stillet til rådighed af platformen til starttilstandene for udfør, fejlfind og profilstart.
Af hensyn til kompatibilitet bagud er den nye attribut ikke specificeret for en starttilstand, kaskademenuen genereres som før via MessageFormat med "{0} As
". Se den relaterede programfejl 105235.
ICU4J er et sæt Java-biblioteker, der indeholder mere omfattende understøttelse til Unicode, softwareglobalisering og internationalisering. For at stille denne funktionalitet til rådighed i Eclipse-samfundet, blev ICU4J tilføjet til platformbygningen af Eclipse 3.2. Du kan se den i bygget som en plugin ved navn com.ibm.icu. Eclipse-platformen anvender ICU API'er i Eclipse 3.2.
Overførsel af programkode kan gøres trinvis, dvs. at fuld indarbejdelse af alle ICU4J-funktioner ikke er nødvendig for at høste fordelene ved brugen af ICU4J. Se siden ICU4J på Eclipse Wiki for at få flere oplysninger om, hvordan du overfører koden for at anvende ICU4J.
Tilføjelsen af ICU4J-plugin'en tilføjer 3 Mb til footprint. Nogle programmer vil ikke absorbereabsorbere ICU4J, hvis programstørrelse går forud for indarbejdelse af ICU4J. Hvis det er tilfældet, kan man anvende en erstatningsplugin (com.ibm.icu.base) fra siden Eclipse platform build page. Overfør plugin'en, fjern plugin'en com.ibm.icu og dens tilsvarende kilde fra biblioteket /plugins, og placér erstatningsplugin'en. Det er nødvendigt, fordi Eclipse-platformen indarbejdede ICU API'et for 3.2, så hvis ICU-plugin'en blot fjernes, vil det resultere i kompileringsfejl i platformkoden. Den pågældende erstatningsplugin er på ca. 100 Kb og kalder simpelthen igennem til JDK's standard-implementering af de mest almindeligt anvendte klasser og API'er i ICU4J. Igen kan du læse siden ICU4J på Eclipse Wiki for at få flere oplysninger om ICU-erstatningsplugin'en.
For at understøtte ICU4J i JFace kræves der nogle kreative API-tilføjelser for at forhindre henvisninger til ICU-klasser i API. Det resulterede i tilføjelsen af:
org.eclipse.jface.viewers.ViewerComparator
, som org.eclipse.jface.viewers.ViewerSorter
nu er en underklasse af. org.eclipse.jface.viewers.StructuredViewer
for at understøtte tilføjelsen af org.eclipse.jface.viewers.ViewerComparator
.Klassen ViewerSorter
har en offentlig klasse getCollator()
, der returnerer en java.text.Collator
. Da denne metode er API, kan den ikke blot ændres til en ICU-sammenligner. Desuden kan ICU-klasser ikke være en del af API'et (signaturer), da en direkte plugin-afhængighed af ICU vil forhindre JFace fra at blive anvendt enkeltstående (med SWT). For at imødegå disse betingelser er en ViewerComparator
-klasse, der anvender en java.util.Comparator
i stedet for en ICUCollator, tilføjet. Dette er gjort, fordi ICU's Collator-klasse implementerer java.util.Comparator
, så enhver StructuredViewer
nu kan bruge ICU's Collator i stedet for java.text.Collator
, men JFace behøver ikke tilføje en afhængighed på ICU4J-plugin'en.
De to nye metoder. der er tilføjet til StructuredViewer
, understøtter brug af ICU's Collator for at sortere indholdet af fremviseren via enViewerComparator
i stedet for en ViewerSorter
. Det anbefales, at enhver StructuredViewer
nu bruger disse metoder til at hente/angive fremviserens sortering (comparator) i stedet for metoderne getSorter()
og setSorter(ViewerSorter)
.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
Bundet org.eclipse.equinox.common indeholder adskillige nye API-klasser, f.eks. Assert
og
ListenerList
, der har fælles navne. Hvis koden har en klasse med samme navn og anvender sætningerne som import * for at importere både lokale klasser og klasser fra runtime, kan du få vist følgende fejlmeddelelse.
Typen ABC er flertydig.
Hvis du organiserer importen og vælger den korrekte importkilde bør det løse problemet.
Som et resultat af, at koden er flyttet til nye runtime-plugins, er det muligt, at tilpassede scripts, der eksplicit henviser til org.eclispe.core.runtime, skal have tilføjet en eller flere af følgende plugins: