Αυτή η ενότητα περιγράφει τις αλλαγές που απαιτούνται εάν επιθυμείτε να αλλάξετε την πρόσθετη λειτουργίας σας εκδοχής 2.1 για να υιοθετήσετε τους μηχανισμούς και τα API εκδοχής 3.0.
Το περιβάλλον εκτέλεσης του Eclipse 3.0 είναι σε σημαντικό βαθμό διαφορετικό. Η υποκείμενη υλοποίηση βασίζεται στην προδιαγραφή πλαισίου OSGi. Το περιβάλλον εκτέλεσης του Eclipse 3.0 περιλαμβάνει ένα επίπεδο συμβατότητας (στην πρόσθετη λειτουργία org.eclipse.core.runtime.compatibility) το οποίο διατηρεί τα API εκδοχής 2.1. Οι προγραμματιστές πρόσθετων λειτουργιών που ενδιαφέρονται για επιπλέον απόδοση και λειτουργία πρέπει να εξετάσουν την υιοθέτηση των API εκδοχής 3.0 και να αφαιρέσουν την εξάρτησή τους στο επίπεδο συμβατότητας. Ο κώδικας συμβατότητας εμφανίζεται σε τρία μέρη:
Το παρακάτω κείμενο περιγράφει με περισσότερες λεπτομέρειες τις κλάσεις και τις μεθόδους που υπάρχουν για σκοπούς συμβατότητας καθώς και οδηγίες για τον τρόπο ενημέρωσης της πρόσθετης λειτουργίας σας.
Το περιβάλλον εκτέλεσης του Eclipse έχει υποστεί βελτιστοποίηση δομής σε δύο μέρη: διαχείριση φόρτωσης κλάσεων και προαπαιτούμενων στοιχείων και διαχείριση επεκτάσεων/σημείων επέκτασης. Αυτός ο διαχωρισμός επιτρέπει τη φυσική/άριστη υιοθέτηση της προδιαγραφής πλαισίου OSGi για τη διαχείριση φόρτωσης κλάσεων και προαπαιτούμενων στοιχείων. Αυτό με τη σειρά του ενεργοποιεί ένα πλήθος δυνατοτήτων στο περιβάλλον εκτέλεσης από δυναμική εγκατάσταση/ενημέρωση/απεγκατάσταση πρόσθετης λειτουργίας σε ασφάλεια και αυξημένη δυνατότητα ρυθμίσεων.
Ενώ θα συνεχίσουμε να αναφερόμαστε σε πρόσθετες λειτουργίες, στο νέο περιβάλλον εκτέλεσης μια πρόσθετη λειτουργία αποτελεί στην πραγματικότητα μια δέσμη και επιπλέον μερικές επεκτάσεις και σημεία επέκτασης. Ο όρος δέσμη ορίζεται από την προδιαγραφή πλαισίου OSGi και αναφέρεται σε μια συλλογή ειδών και πόρων καθώς και συσχετισμένων πληροφοριών προαπαιτούμενων στοιχείων μεταξύ των δεσμών. Το μητρώο επεκτάσεων αποτελεί τη νέα μορφή του μητρώου πρόσθετων λειτουργιών και περιγράφει λεπτομερώς μόνο πληροφορίες επεκτάσεων και σημείων επέκτασης. Σε γενικές γραμμές το API του μητρώου επεκτάσεων είναι το ίδιο με το σχετικό API του μητρώου πρόσθετων λειτουργιών (για περισσότερες πληροφορίες ανατρέξτε στην ενότητα Μητρώα).
Στο περιβάλλον εκτέλεσης Eclipse 2.x το αντικείμενο πρόσθετης λειτουργίας διαθέτει ένα πλήθος ρόλων και αρμοδιοτήτων:
Στο πλαίσιο του περιβάλλον εκτέλεσης του Eclipse 3.0, αυτοί οι ρόλοι και οι αρμοδιότητες αναλύονται σε διακριτά αντικείμενα.
Η Plugin υλοποιεί επίσης την BundleActivator. Αυτό αναγνωρίζει τη διευκόλυνση του να διαθέτει ένα κεντρικό αντικείμενο το οποίο αναπαριστά τον κύκλο ζωής και τη σημασιολογία μιας πρόσθετης λειτουργίας. Σημειώστε, ωστόσο, ότι αυτό δεν επιτρέπει την έντονη απόδοση αρχικών τιμών των δομών δεδομένων η οποία αποτελεί κοινή πρακτική στις πρόσθετες λειτουργίες σήμερα. Δεν μπορούμε να τονίσουμε αρκετά το γεγονός ότι οι πρόσθετες λειτουργίες μπορούν να ενεργοποιηθούν λόγω μιας σχεδόν περιφερειακής κλάσης στην οποία γινόταν παραπομπή κατά την επαλήθευση μιας κλάσης σε κάποια άλλη πρόσθετη λειτουργία. Δηλαδή, επειδή ενεργοποιήθηκε η πρόσθετη λειτουργία σας δεν σημαίνει απαραίτητα ότι η λειτουργία της απαιτείται. Σημειώστε επίσης ότι είστε ελεύθεροι να ορίσετε μια διαφορετική κλάση BundleActivator ή να μην έχετε κανένα ενεργοποιητή δέσμης.
Τα βήματα που απαιτούνται για τη σύνδεση μιας κλάσης εκδοχής 2.x Plugin στο Eclipse 3.0 εξαρτώνται από τη λειτουργία της κλάσης. Όπως περιγράφηκε παραπάνω, οι περισσότερες εργασίες κύκλου ζωής εκκίνησης ανήκουν σε μια από τις παρακάτω κατηγορίες:
Στο νέο περιβάλλον εκτέλεσης υπάρχει ένας διαχωρισμός μεταξύ των πληροφοριών και των δομών, που απαιτούνταν για την εκτέλεση μιας πρόσθετης λειτουργίας, και αυτών που σχετίζονταν με τις επεκτάσεις και τα σημεία επέκτασης μιας πρόσθετης λειτουργίας. Οι πρώτες ορίζονται και γίνεται διαχείρισή τους από την προδιαγραφή πλαισίου OSGi. Οι τελευταίες αποτελούν έννοιες ειδικά για το Eclipse και προστίθενται από τον κώδικα περιβάλλοντος εκτέλεσης του Eclipse. Αντίστοιχα, το αρχικό μητρώο πρόσθετων λειτουργιών και τα σχετικά αντικείμενα έχουν χωριστεί σε δέσμες OSGi και στο μητρώο επεκτάσεων του Eclipse .
Τα μέρη της IPluginRegistry που ασχολούνται με την προδιαγραφή εκτέλεσης (π.χ., οι IPluginDescriptor, ILibrary, IPrequisite) έχουν καταργηθεί και τα εναπομείναντα μέρη που σχετίζονται με επεκτάσεις και σημεία επέκτασης έχουν μετακινηθεί στην IExtensionRegistry. Επιπλέον, τα επονομαζόμενα αντικείμενα μοντέλων που σχετίζονται με το μητρώο πρόσθετων λειτουργιών στο σύνολό του έχουν πλέον καταργηθεί. Αυτά τα είδη αναπαριστώνται και αποδίδονται σε αυτά αρχικές τιμές από το περιβάλλον εκτέλεσης κυρίως για την υποστήριξη εργαλείων όπως το PDE. Δυστυχώς, ήταν συχνό το φαινόμενο του επιπέδου πληροφοριών που απαιτούνταν να ξεπερνούσε τις δυνατότητες ή τα ενδιαφέροντα του περιβάλλοντος εκτέλεσης (π.χ., αποθήκευση αριθμών γραμμών για στοιχεία plugin.xml) και τελικά οι πιθανοί καταναλωτές των πληροφοριών του περιβάλλοντος εκτέλεσης έπρεπε να διατηρούν ούτως ή άλλως τις δομές τους.
Στο νέο περιβάλλον εκτέλεσης έχουμε επαναθεωρήσει τις λειτουργίες που παρέχονται από το περιβάλλον εκτέλεσης και πλέον παρέχονται μόνο εκείνες που είναι είτε βασικές για την εκτέλεση του περιβάλλοντος εκτέλεσης είτε είναι εξαιρετικά δύσκολες να γίνουν από άλλους. Όπως αναφέρθηκε παραπάνω, τα αντικείμενα μοντέλων μητρώου πρόσθετων λειτουργιών έχουν καταργηθεί όπως και το API ανάλυσης πρόσθετων λειτουργιών. Το νέο μητρώο επεκτάσεων διατηρεί τις απαραίτητες πληροφορίες που σχετίζονται με τις επεκτάσεις. Μια νέα δομή κατάστασης (δείτε το org.eclipse.osgi.service.resolver.State και φιλικά στοιχεία) αναπαριστά και επιτρέπει το χειρισμό των απαραίτητων πληροφοριών που σχετίζονται με την εκτέλεση.
Στο Eclipse 3.0 η δομή τμήματος κώδικα NL έχει ενημερωθεί για να γίνει περισσότερο συνεπής. Παλαιότερα οι μεταφράσεις αρχείων όπως το plugin.properties θεωρούνταν ότι βρίσκονταν εντός των αρχείων JAR που παρέχονταν από τα τμήματα κώδικα. Εφόσον τα αρχικά αρχεία βρίσκονται στον κεντρικό κατάλογο της σχετικής πρόσθετης λειτουργίας κεντρικού συστήματος, μια περισσότερο συνεπής θέση θα εντόπιζε τα μεταφρασμένα αρχεία στον κεντρικό κατάλογο των τμημάτων κώδικα NL. Για παράδειγμα,
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar
Σημειώστε ότι το αρχείο nl1.jar παλαιότερα θα περιείχε τις μεταφράσεις για το αρχείο plugin.properties. Αυτά τα αρχεία βρίσκονται τώρα στον κεντρικό κατάλογο του τμήματος κώδικα και το αρχείο JAR περιέχει μεταφράσεις οποιωνδήποτε πόρων που μπορούν να μεταφραστούν (π.χ., αρχείων που φορτώνονται μέσω του φορτωτή κλάσεων) στην πρόσθετη λειτουργία κεντρικού συστήματος.
Φυσικά η δομή τμήματος κώδικα NL του Eclipse 2.1 υποστηρίζετε ακόμη για πρόσθετες λειτουργίες κεντρικού συστήματος εκδοχής 2.1 που εκτελούνται στο Eclipse 3.0. Παρόλα αυτά δεν μπορείτε να χρησιμοποιήσετε ένα τμήμα κώδικα NL εκδοχής 2.1 σε μια πρόσθετη λειτουργία εκδοχής 3.0. Πρέπει να γίνει ενημέρωση του τμήματος κώδικα αναφορικά με τη νέα δομή.
Καταργήθηκε ολόκληρο το πακέτο org.eclipse.core.boot. Η κλάση BootLoader συγχωνεύτηκε με το org.eclipse.core.runtime.Platform αφού δεν ήταν λογικό να υπάρχει διαχωρισμός μεταξύ της εκκίνησης και του περιβάλλοντος εκτέλεσης. Σημειώστε ότι στην πραγματικότητα η πρόσθετη λειτουργία org.eclipse.core.boot διασπάστηκε και ολόκληρος ο κώδικάς της μετακινήθηκε είτε στο νέο περιβάλλον εκτέλεσης είτε στο επίπεδο συμβατότητας.
Η IPlatformConfiguration ανέκαθεν αποτελούσε ένα είδος το οποίο οριζόταν από και για το συστατικό στοιχείο εγκατάσταση/ενημέρωση του Eclipse. Με την αναδιοργάνωση του περιβάλλοντος εκτέλεσης είμαστε σε θέση να επαναφέρουμε αυτό το είδος στη σωστή του θέση. Αυτή η κλάση δεν έχει αλλάξει σε μεγάλο βαθμό και έχει συσκευαστεί εκ νέου ως org.eclipse.update.configurator.IPlatformConfiguration.
Η IPlatformRunnable έχει μετακινηθεί στην org.eclipse.core.runtime.IPlatformRunnable.
Η μέθοδος getDeclaringPlugin()
(και στις δύο κλάσεις) προσφέρει μια ανοδική σύνδεση στην πρόσθετη λειτουργία η οποία δηλώνει την επέκταση ή το σημείο επέκτασης (αντίστοιχα).
Το νέο μοντέλο μητρώου διαχωρίζει τις πτυχές εκτέλεσης των πρόσθετων λειτουργιών από τις πτυχές επέκτασης/σημείου επέκτασης και δεν περιέχει πλέον την IPluginDescriptors.
Οι χρήστες αυτού του API πρέπει να εξετάσουν τη νέα μέθοδο getParentIdentifier() που βρίσκεται τόσο στην IExtension όσο και στην IExtensionPoint.
Στο αρχικό περιβάλλον εκτέλεσης το μητρώο πρόσθετων λειτουργιών διαχειριζόταν μια πλήρη εικόνα των ρυθμίσεων του περιβάλλοντος εκτέλεσης. Στο Eclipse 3.0 αυτή η εικόνα χωρίζεται μεταξύ του πλαισίου OSGi και του μητρώου επεκτάσεων. Για αυτό το λόγο αυτές οι κλάσεις έχουν καταργηθεί. Οι σημειώσεις κατάργησης περιέχουν λεπτομέρειες σχετικά με τον τρόπο με τον οποίο πρέπει να ενημερώσετε τον κώδικά σας.
Στο νέο περιβάλλον εκτέλεσης δεν γίνεται διαχείριση των αντικειμένων Plugin από το περιβάλλον εκτέλεσης και συνεπώς δεν υπάρχει γενικά πρόσβαση σε αυτά μέσω της Platform. Ομοίως, το μητρώο πρόσθετων λειτουργιών δεν υπάρχει ούτε παρέχει πρόσβαση στα αρχεία περιγραφής πρόσθετων λειτουργιών. Υπάρχουν διαθέσιμες, ωστόσο, κατάλληλες μέθοδοι αντικατάστασης και περιγράφονται λεπτομερώς στο Javadoc των καταργημένων μεθόδων σε αυτές τις κλάσεις.
Όλα τα είδη σε αυτό το πακέτο έχουν καταργηθεί. Ανατρέξτε στην ανάλυση στην ενότητα μητρώα για περισσότερες πληροφορίες.
Οι πελάτες της μεθόδου IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) πρέπει να επιστρέψουν σε αυτές τις χρήσεις της μεθόδου και να εξετάσουν τη χρήση της μεθόδου ενισχυμένων δυνατοτήτωνIWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). Η παλαιά μέθοδος IWorkspace.run λαμβάνει ένα κλείδωμα ολόκληρου του χώρου εργασίας για τη διάρκεια της IWorkspaceRunnable. Αυτό σημαίνει ότι μια λειτουργία που πραγματοποιείται με αυτή τη μέθοδο δεν θα είναι ποτέ σε θέση να εκτελεστεί ταυτόχρονα με άλλες λειτουργίες που αλλάζουν το χώρο εργασίας. Στο Eclipse 3.0 πολλές μακρόχρονες λειτουργίες έχουν μετακινηθεί σε νήματα παρασκηνίου, ώστε η πιθανότητα διενέξεων μεταξύ λειτουργιών έχει σε μεγάλο βαθμό αυξηθεί. Εάν μια αποκλειστική λειτουργία στο προσκήνιο μπλοκάρεται από μια μακρόχρονη λειτουργία στο παρασκήνιο, το περιβάλλον χρήστη μπλοκάρεται μέχρι να ολοκληρωθεί η λειτουργία στο παρασκήνιο ή μέχρι να ακυρωθεί μια από τις λειτουργίες.
Η προτεινόμενη λύση είναι η εναλλαγή όλων των παραπομπών στην παλαιά IWorkspace.run έτσι ώστε να χρησιμοποιούν τη νέα μέθοδο με μια παράμετρο κανόνων προγραμματισμού. Ο κανόνας προγραμματισμού πρέπει να αποτελεί τον πιο ιδιαίτερα ακριβή κανόνα που να περιλαμβάνει τους κανόνες για όλες τις αλλαγές από αυτή τη λειτουργία. Εάν η λειτουργία επιχειρήσει να τροποποιήσει πόρους εκτός της εμβέλειας του κανόνα προγραμματισμού, θα παρουσιαστεί μια εξαίρεση του χρόνου εκτέλεσης. Ο ακριβής κανόνας προγραμματισμού, ο οποίος απαιτείται από μια δεδομένη λειτουργία χώρου εργασίας, δεν έχει καθοριστεί και μπορεί να αλλάξει ανάλογα με τον εγκατεστημένο παροχέα χώρου αποθήκευσης σε ένα δεδομένα έργο. Η μέθοδος κατασκευής IResourceRuleFactory
πρέπει να χρησιμοποιείται για τη λήψη του κανόνα προγραμματισμού για μια λειτουργία αλλαγής πόρων. Εάν επιθυμείτε, μπορεί να χρησιμοποιηθεί μια κλάση MultiRule για τον καθορισμό πολλαπλών κανόνων για πόρους και η μέθοδος διευκόλυνσης MultiRule.combine μπορεί να χρησιμοποιηθεί για το συνδυασμό κανόνων από διάφορες λειτουργίες αλλαγής πόρων.
Εάν δεν απαιτείται κλείδωμα, μπορεί να χρησιμοποιηθεί ένας κανόνας προγραμματισμού null. Με αυτό τον τρόπο επιτρέπεται στο εκτελέσιμο στοιχείο να τροποποιεί όλους τους πόρους στο χώρο εργασίας αλλά δεν αποτρέπει άλλα νήματα επίσης να τροποποιούν ταυτόχρονα το χώρο εργασίας. Για απλές αλλαγές στο χώρο εργασίας αυτός αποτελεί συχνά την ευκολότερη και περισσότερο φιλική λύση όσον αφορά την ταυτόχρονη χρήση.
filteredSelection
από την selection
:
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new StructuredSelection(selectedResources);
}
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new StructuredSelection(selectedResources);
}
if (selection.isEmpty()) { IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); if (window != null) { IWorkbenchPart part = window.getPartService().getActivePart(); if (part instanceof IEditorPart) { IEditorInput input = ((IEditorPart) part).getEditorInput(); if (input instanceof IFileEditorInput) { selection = new StructuredSelection(((IFileEditorInput) input).getFile()); } } } }
IActionBars actionBars= getActionBars(); if (actionBars != null) { actionBars.setGlobalActionHandler(IDEActionFactory.ADD_TASK.getId(), getAction(textEditor, IDEActionFactory.ADD_TASK.getId())); actionBars.setGlobalActionHandler(IDEActionFactory.BOOKMARK.getId(), getAction(textEditor, IDEActionFactory.BOOKMARK.getId())); }
Υπάρχει πλέον ρητή έννοια ενός είδους σημείωσης. Ανατρέξτε στις Annotation.getType() και Annotation.setType(). Το είδος σημείωσης μπορεί να αλλάξει κατά τη διάρκεια του κύκλου ζωής του. Έχει προστεθεί ένα νέο σημείο επέκτασης για τη δήλωση ειδών σημειώσεων: "org.eclipse.ui.editors.annotationTypes". Ένα είδος σημείωσης διαθέτει όνομα και μπορεί να δηλωθεί ως υπο-είδος ενός άλλου είδους σημείωσης που έχει δηλωθεί. Μια δήλωση είδους σημείωσης μπορεί επίσης να χρησιμοποιεί τα γνωρίσματα "markerType" και "markerSeverity" για να καθορίσει ότι οι δείκτες ενός δεδομένου είδους και μιας δεδομένης σοβαρότητας πρέπει να αναπαριστώνται στις λειτουργίες επεξεργασίας κειμένου ως σημειώσεις ενός συγκεκριμένου είδους σημείωσης. Τα γνωρίσματα "markerType" και "markerSeverity" στο "org.eclipse.ui.editors.markerAnnotationSpecification" δεν πρέπει να χρησιμοποιούνται. Οι προδιαγραφές σημείωσης δείκτη συνεπώς γίνονται ανεξάρτητες από τους δείκτες και το όνομα είναι παραπλανητικό. Ωστόσο, το όνομα διατηρείται για να διασφαλιστεί η συμβατότητα με παλαιότερες εκδόσεις.
Οι χρήσεις των υποκλάσεων της AbstractMarkerAnnotationModel αυτόματα εντοπίζουν και ορίζουν τα σωστά είδη σημειώσεων για σημειώσεις που δημιουργούν από δείκτες. Για την ανάκτηση με προγραμματισμό του είδους σημείωσης για ένα δεδομένο δείκτη ή ένα δεδομένο ζεύγος markerType και markerSeverity χρησιμοποιήστε το org.eclipse.ui.texteditor.AnnotationTypeLookup.
Παρέχεται πρόσβαση στην ιεραρχία των ειδών σημειώσεων από την IAnnotationAccessExtension. Για ένα δεδομένο είδος σημείωσης μπορείτε να λάβετε την αλυσίδα των υπερ-ειδών και να ελέγξετε κατά πόσο ένα είδος σημείωσης αποτελεί υπο-είδος ενός άλλου είδους σημείωσης. Η DefaultMarkerAnnotationAccess υλοποιεί αυτή τη διεπαφή.
Το είδος σημείωσης αποτελεί το κλειδί για την εύρεση της συσχετισμένης προδιαγραφής σημείωσης δείκτη. Καθώς τα είδη σημειώσεων μπορούν να επεκτείνουν άλλα είδη σημειώσεων, υπάρχει επίσης μια άδηλη σχέση μεταξύ των προδιαγραφών σημειώσεων δείκτη. Συνεπώς μια προδιαγραφή σημείωσης δείκτη για ένα δεδομένο είδος σημείωσης ολοκληρώνεται από τις προδιαγραφές σημείωσης δείκτη που δίνονται για τα υπερ-είδη του δεδομένου είδους σημείωσης. Επομένως, η προδιαγραφή σημείωσης δείκτη δεν χρειάζεται να είναι ολοκληρωμένη όπως απαιτούνταν παλαιότερα. Οι προδιαγραφές σημείωσης δείκτη ανακτώνται από την AnnotationPreferences. Χρησιμοποιώντας την org.eclipse.ui.texteditor.AnnotationPreferenceLookup, μπορείτε να ανακτήσετε προτιμήσεις σημειώσεων για ένα δεδομένο είδος σημείωσης, το οποίο εκτελεί με διαφάνεια την ολοκλήρωση των προτιμήσεων μαζί με την αλυσίδα υπερ-ειδών σημειώσεων.
Η προδιαγραφή σημείωσης δείκτη έχει επεκταθεί με τρία επιπλέον γνωρίσματα για να επιτρέπει τον ορισμό των προσαρμοσμένων προτιμήσεων ενός δεδομένου είδους σημείωσης στον κατακόρυφο χάρακα. Τα γνωρίσματα αυτά είναι: "icon", "symbolicIcon", και "annotationImageProvider". Ως τιμή για το "icon" καθορίζεται η διαδρομή σε ένα αρχείο που περιέχει την εικόνα του εικονιδίου. Ως τιμή του "symbolicIcon" μπορεί να είναι ένα από τα "error", "warning", "info", "task" και "bookmark". Το γνώρισμα "symbolicIcon" χρησιμοποιείται για την αναφορά στην πλατφόρμα ότι η σημείωση πρέπει να απεικονίζεται με τις ίδιες εικόνες που χρησιμοποιούνται από την πλατφόρμα για την παρουσίαση σφαλμάτων, προειδοποιήσεων, πληροφοριών, εργασιών και σελιδοδεικτών αντίστοιχα. Ως τιμή του "annotationImageProvider" καθορίζεται μια κλάση που υλοποιεί την org.eclipse.ui.texteditor.IAnnotationImageProvider, η οποία επιτρέπει μια πλήρως προσαρμοσμένη παρουσίαση σημειώσεων.
Ο κατακόρυφος χάρακας χρησιμοποιεί τις συσχετισμένες IAnnotationAccess/IAnnotationAccessExtension για το σχεδιασμό σημειώσεων. Ο κατακόρυφοα χάρακας δεν καλεί πλέον την Annotation.paint. Γενικά, οι σημειώσεις δεν σχεδιάζονται πλέον από μόνες τους. Οι μέθοδοι "paint" και "getLayer" καταργήθηκαν για να καταστήσουν τη σημείωση τελικά ανεξάρτητο περιβάλλοντος χρήστη. Η DefaultMarkerAnnotationAccess λειτουργεί ως προεπιλεγμένη υλοποίηση της IAnnotationAccess/IAnnotationAccessExtension. Η DefaultMarkerAnnotationAccess υλοποιεί την ακόλουθη στρατηγική για την εφαρμογή χρώματος σε σημειώσεις: Εάν μια σημείωση υλοποιεί την IAnnotationPresentation, καλείται η IAnnotationPresentation.paint. Εάν όχι, ο παροχέας εικόνας σημείωσης αναζητείται στις προτιμήσεις σημειώσεων. Ο παροχέας εικόνας σημείωσης διατίθεται μόνο εάν έχει καθοριστεί και εάν έχει ήδη φορτωθεί η πρόσθετη λειτουργία που ορίζει την περικλείουσα προδιαγραφή σημείωσης δείκτη. Εάν υπάρχει ένας παροχέας εικόνας σημείωσης, η κλήση προωθείται σε αυτόν. Εάν όχι, αναζητείται το καθορισμένο "icon". Το "symbolicIcon" χρησιμοποιείται ως τελική εναλλακτική λύση. Για τη σχεδίαση σημειώσεων, το επίπεδο παρουσίασης σημειώσεων είναι σχετικό. Η DefaultMarkerAnnotationAccess αναζητάει το επίπεδο παρουσίασης χρησιμοποιώντας την ακόλουθη στρατηγική: Εάν οι προτιμήσεις σημειώσεων καθορίζουν ένα επίπεδο παρουσίασης, χρησιμοποιείται το καθορισμένο επίπεδο. Εάν δεν υπάρχει κάποιο επίπεδο και η σημείωση υλοποιεί την IAnnotationPresentation, χρησιμοποιείται η IAnnotationPresentation.getLayer διαφορετικά επιστρέφεται το προεπιλεγμένο επίπεδο παρουσίασης (το οποίο είναι 0).
Τα ακόλουθα είδη σημειώσεων δηλώνονται από την πρόσθετη λειτουργία 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>
Η καθορισμένη επέκταση markerAnnotationSpecification δεν παρέχει τα γνωρίσματα "markerType" και "markerSeverity". Ορίζουν το γνώρισμα "symbolicIcon" με την κατάλληλη τιμή. Επομένως, δεν καλούνται πλέον οι μέθοδοι MarkerAnnotation.paint και MarkerAnnotation.getLayer, για παράδειγμα η αντικατάσταση των μεθόδων αυτών δεν έχει κανένα αποτέλεσμα. Οι πελάτες που επηρεάζονται πρέπει να υλοποιούν την IAnnotationPresentation.
Με την εισαγωγή των καταστάσεων λειτουργίας εκκίνησης με δυνατότητα επέκτασης στην εκδοχή 3.0, μπορεί να υπάρχουν περισσότεροι από ένας εκπρόσωποι εκκίνησης για ένα είδος ρυθμίσεων εκκίνησης. Οι εκδόσεις πριν την 3.0 υποστήριζαν μόνο έναν εκπρόσωπο εκκίνησης για κάθε είδος ρυθμίσεων εκκίνησης. Η μέθοδος ILaunchConfigurationType.getDelegate()
έχει καταργηθεί. Η μέθοδος getDelegate(String mode)
πρέπει να χρησιμοποιηθεί στη θέση του για την ανάκτηση του εκπροσώπου εκκίνησης για μια συγκεκριμένη κατάσταση λειτουργίας εκκίνησης.
Η καταργημένη μέθοδος έχει αλλάξει ώστε να επιστρέφει τον εκπρόσωπο εκκίνησης για την κατάσταση λειτουργίας run
.
Οι ομάδες καρτέλας εκκίνησης και οι καρτέλες εκκίνησης δεν ειδοποιούνται κατά την ολοκλήρωση μιας εκκίνησης. Η μέθοδος launched(ILaunch)
στις διεπαφές ILaunchConfigurationTab
και ILaunchConfigurationTabGroup
καταργήθηκε και δεν καλείται πλέον. Εάν βασίζεστε σε αυτή τη μέθοδο για τη λειτουργία εκκίνησης μπορεί να αποδειχθεί προβληματική, εφόσον οι καρτέλες υπάρχουν μόνο κατά την εκτέλεση της εκκίνησης από το πλαίσιο διαλόγου εκκίνησης. Επίσης, με την εισαγωγή της εκκίνησης στο παρασκήνιο, αυτή η μέθοδος δεν μπορεί να καλείται, καθώς το πλαίσιο διαλόγου εκκίνησης κλείνει πριν εμφανιστεί το αντικείμενο εκκίνησης που προκύπτει.
Έχουν προστεθεί δύο μέθοδοι στη διεπαφή ILaunchConfigurationTab
- η ενεργοποιημένη και η απενεργοποιημένη. Οι νέες αυτές μέθοδοι κύκλου ζωής καλούνται κατά την είσοδο και την έξοδο μιας καρτέλας αντίστοιχα. Οι υπάρχουσες υλοποιήσεις της ILaunchConfigurationTab
, η οποία αποτελεί υποκλάση της αφηρημένης κλάσης που παρέχεται από την πρόσθετη λειτουργία εντοπισμού και διόρθωσης σφαλμάτων (AbstractLaunchConfigurationTab
), έχουν συμβατότητα με αρχεία δυαδικής μορφής, εφόσον οι μέθοδοι υλοποιούνται στην αφηρημένη κλάση.
Σε παλαιότερες εκδόσεις μια καρτέλα λάμβανε το μήνυμα initializeFrom
κατά την ενεργοποίησή της και το μήνυμα performApply
κατά την απενεργοποίηση της. Με αυτόν τον τρόπο το πλαίσιο καρτέλας ρυθμίσεων εκκίνησης παρείχε επικοινωνία μεταξύ των καρτέλων μέσω ρυθμίσεων εκκίνησης (ενημερώνοντας τις ρυθμίσεις με τις τρέχουσες τιμές γνωρισμάτων κατά την έξοδο μιας καρτέλας και ενημερώνοντας την πρόσφατα εισαγόμενη καρτέλα). Ωστόσο, εφόσον πολλές καρτέλες δεν εκτελούν επικοινωνία μεταξύ των καρτέλων, αυτό μπορεί να αποδειχθεί ανεπαρκές. Επίσης, δεν υπήρχε τρόπος να ξεχωρίσει μια καρτέλα που ενεργοποιείται από μια καρτέλα που εμφανίζει επιλεγμένες ρυθμίσεις εκκίνησης για πρώτη φορά. Οι μέθοδοι που μόλις προστέθηκαν επιτρέπουν στις καρτέλες να ξεχωρίζουν μεταξύ της ενεργοποίησης και της απόδοσης αρχικών τιμών καθώς και μεταξύ της απενεργοποίησης και της αποθήκευσης τρεχουσών τιμών.
Η προεπιλεγμένη υλοποίηση της activated
, που παρέχεται από την καρτέλα "Αφηρημένη", καλεί την initializeFrom
. Ομοίως η προεπιλεγμένη υλοποίηση της deactivated
καλεί την performApply
. Οι καρτέλες που επιθυμούν να εκμεταλλευτούν το νέο API πρέπει να αντικαταστήσουν αυτές τις μεθόδους όπως απαιτείται.
Γενικά, για καρτέλες που δεν εκτελούν επικοινωνία μεταξύ καρτελών, η προτεινόμενη προσέγγιση είναι να υλοποιήσετε εκ νέου αυτές τις μεθόδους ώστε να μην εκτελούν καμία ενέργεια.
Σε παλαιότερες εκδόσεις, η εναλλαγή προοπτικών καθοριζόταν στις ρυθμίσεις εκκίνησης, μέσω των γνωρισμάτων ρυθμίσεων εκκίνησης ATTR_TARGET_DEBUG_PERSPECTIVE
και ATTR_TARGET_RUN_PERSPECTIVE
. Με την προσθήκη των καταστάσεων λειτουργίας εκκίνησης με δυνατότητα επέκτασης στην εκδοχή 3.0, αυτή η προσέγγιση δεν ευσταθεί. Η εναλλαγή προοπτικών καθορίζεται από τη βάση είδους ρυθμίσεων εκκίνησης, για κάθε κατάσταση λειτουργίας που ένα είδος ρυθμίσεων εκκίνησης υποστηρίζει. Προστέθηκε API στο DebugUITools
για τον ορισμό και τη λήψη της προοπτικής που συσχετίζεται με ένα είδος ρυθμίσεων εκκίνησης για μια συγκεκριμένη κατάσταση λειτουργίας εκκίνησης.
Ένα επιπρόσθετο προαιρετικό στοιχείο launchMode
προστέθηκε στο σημείο επέκτασης launchConfigurationTabGroup
, το οποίο επιτρέπει σε ομάδα καρτέλων που συνεισφέρεται να καθορίσει μια προεπιλεγμένη προοπτική για ένα είδος και μια κατάσταση λειτουργίας ρυθμίσεων εκκίνησης.
Από το περιβάλλον χρήστη του Eclipse, οι χρήστες μπορούν να τροποποιήσουν την προοπτική που συσχετίζεται με ένα είδος ρυθμίσεων εκκίνησης ανοίγοντας το πλαίσιο διαλόγου εκκίνησης και επιλέγοντας έναν κόμβο είδους ρυθμίσεων εκκίνησης στη διακλάδωση (παρά μεμονωμένες ρυθμίσεις). Εμφανίζεται μια καρτέλα η οποία επιτρέπει στο χρήστη να ορίσει μια προοπτική για κάθε κατάσταση λειτουργίας εκκίνησης που υποστηρίζεται.
Προστέθηκαν δύο μέθοδοι στην κλάση VMRunnerConfiguration
για την υποστήριξη της ρύθμισης και της ανάκτησης μεταβλητών περιβάλλοντος. Οι υλοποιητές της IVMRunner
πρέπει να καλέσουν την VMRunnerConfiguration.getEnvironment()
και να μεταβιβάσουν αυτό το περιβάλλον στο JVM που εκτελείται. Οι πελάτες που χρησιμοποιούν την DebugPlugin.exec(String[] cmdLine, File workingDirectory)
μπορούν να το επιτύχουν αυτό καλώντας στη θέση της την DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp)
. Απλά αρκεί η μεταβίβαση του αποτελέσματος από την getEnvironment()
.
Σε προηγούμενες εκδόσεις η VMRunnerConfiguration
είχε ένα γνώρισμα για την περιγραφή μιας διαδρομής εκκίνησης. Αυτό το γνώρισμα αποτελεί μια συλλογή των Strings
που θα καθοριστούν στο όρισμα Xbootclasspath
. Προστέθηκαν τρία νέα γνωρίσματα στη κλάση VMRunnerConfiguration για την υποστήριξη των JVM που επιτρέπουν την πρόταση και την προσάρτηση στη διαδρομή εκκίνησης. Οι νέες μέθοδοι/γνωρίσματα που προστέθηκαν είναι:
getPrependBootClassPath()
- επιστρέφει μια συλλογή καταχωρήσεων που θα προταθούν στη διαδρομή εκκίνησης (το όρισμα -Xbootclasspath/p
)getMainBootClassPath()
- επιστρέφει μια συλλογή καταχωρήσεων που θα τοποθετηθούν στη διαδρομή εκκίνησης (το όρισμα -Xbootclasspath
)getAppendBootClassPath()
- επιστρέφει μια συλλογή καταχωρήσεων που θα προσαρτηθούν στη διαδρομή εκκίνησης (το όρισμα -Xbootclasspath/a
)Το παλαιό γνώρισμα getBootClassPath()
υπάρχει ακόμα και περιέχει μια πλήρη διαδρομή αντίστοιχη με αυτή των τριών νέων γνωρισμάτων. Ωστόσο, οι κλάσεις VMRunners
, που υποστηρίζουν τις νέες επιλογές της διαδρομής εκκίνησης, πρέπει να εκμεταλλευτούν τα νέα γνωρίσματα.
Έχει γίνει επανεπεξεργασία της λειτουργίας αντιγράφου εργασίας μοντέλου Java στην εκδοχή 3.0 για την παροχή σε μεγάλο βαθμό αυξημένης λειτουργικότητας. Πριν την εκδοχή 3.0 το μοντέλο Java επέτρεπε τη δημιουργία μεμονωμένων αντιγράφων εργασίας των μονάδων μεταγλώττισης. Θα μπορούσαν να γίνουν αλλαγές στο αντίγραφο εργασίας και να δεσμευτούν αργότερα. Υπήρχε υποστήριξη για περιορισμένη ανάλυση ενός αντιγράφου εργασίας στο περιβάλλον του υπόλοιπου μέρους του μοντέλου Java. Ωστόσο, δεν υπήρχε τρόπος αυτές οι αναλύσεις να λάβουν υπόψη τους περισσότερα από ένα αντίγραφα εργασίας κάθε φορά.
Οι αλλαγές στην εκδοχή 3.0 καθιστούν δυνατή τη δημιουργία και τη διαχείριση συνόλων αντιγράφων εργασίας μονάδων μεταγλώττισης και την εκτέλεση αναλύσεων με την παρουσία όλων των αντιγράφων εργασίας σε ένα σύνολο. Για παράδειγμα, είναι πλέον δυνατόν ένας πελάτης, όπως η βελτιστοποίηση δομής JDT, να δημιουργήσει αντίγραφα εργασίας για μία ή περισσότερες μονάδες μεταγλώττισης που εξετάζει να τροποποιήσει και στη συνέχεια να αναλύσει τις παραπομπές ειδών μεταξύ των αντιγράφων εργασίας. Παλαιότερα αυτό γινόταν μόνο μετά τη δέσμευση των αλλαγών στα αντίγραφα εργασίας της μονάδας μεταγλώττισης.
Το API μοντέλου Java αλλάζει με δύο τρόπους για την προσθήκη αυτής της βελτιωμένης υποστήριξης:
(1) Η λειτουργία που προηγουμένως βρισκόταν στην IWorkingCopy
και μεταβιβαζόταν στην ICompilationUnit
ενοποιήθηκε στην ICompilationUnit
.
Η διεπαφή IWorkingCopy
χρησιμοποιούταν μόνο σε αυτή τη θέση και ήταν χωρίς λόγο περισσότερο γενική από ό,τι χρειαζόταν να είναι. Με αυτή την αλλαγή απλοποιείται το API. Η IWorkingCopy
καταργήθηκε. Άλλες θέσεις στο API όπου χρησιμοποιείται η IWorkingCopy
ως παράμετρος ή είδος αποτελέσματος επίσης καταργήθηκαν. Η αντικατάσταση των μεθόδων API αναφέρουν την ICompilationUnit
αντί της IWorkingCopy
.
(2) Η διεπαφή IBufferFactory
αντικαταστάθηκε από την WorkingCopyOwner
.
Η βελτιωμένη υποστήριξη για τα αντίγραφα εργασίας απαιτεί ένα αντικείμενο στο οποίο να ανήκουν τα αντίγραφα εργασίας. Παρόλο που η IBufferFactory
βρίσκεται στη σωστή θέση, το όνομα δεν αποδίδει επαρκώς τον τρόπο με τον οποίο λειτουργεί ο νέος μηχανισμός αντιγράφου εργασίας. Η WorkingCopyOwner
είναι περισσότερο υποδηλωτική. Επιπρόσθετα, η WorkingCopyOwner
δηλώνεται ως αφηρημένη κλάση, παρά ως διεπαφή, για να επιτρέπει στην έννοια του κατόχου αντιγράφου εργασίας να εξελιχθεί στο μέλλον. Η μία μέθοδος στην IBufferFactory
μετακινείται στην WorkingCopyOwner
χωρίς να επηρεαστεί. Η WorkingCopyOwner
δεν υλοποιεί την IBufferFactory
για να καταστήσει σαφές ότι η IBufferFactory
αποτελεί παρελθόν. Η IBufferFactory
καταργήθηκε. Άλλες θέσεις στο API όπου η IBufferFactory
εμφανίζεται ως παράμετρος ή είδος αποτελέσματος επίσης καταργήθηκαν. Η αντικατάσταση των μεθόδων API αναφέρουν την WorkingCopyOwner
αντί της IBufferFactory
.
Αυτές οι αλλαγές δεν επηρεάζουν τη συμβατότητα με αρχεία δυαδικής μορφής.
Κατά τη μετάβαση όλες οι παραπομπές στο είδος IWorkingCopy
θα πρέπει στη θέση του να παραπέμπουν στο ICompilationUnit
. Η μόνη υλοποίηση του IWorkingCopy
υλοποιεί επίσης το ICompilationUnit
, που σημαίνει ότι αντικείμενα του είδους IWorkingCopy
μπορούν με ασφάλεια να μετατραπούν σε ICompilationUnit
.
Μια κλάση που υλοποιεί την IBufferFactory
χρειάζεται να αντικατασταθεί από μια υποκλάση της WorkingCopyOwner
. Παρόλο που η WorkingCopyOwner
δεν υλοποιεί την ίδια την IBufferFactory
, θα ήταν δυνατόν να δηλωθεί η υποκλάση της WorkingCopyOwner
που υλοποιεί την IBufferFactory
και με αυτόν τον τρόπο δημιουργείται μια γέφυρα ανάμεσα στην παλαιά και τη νέα (η IBufferFactory
δηλώνει την createBuffer(IOpenable)
ενώ η WorkingCopyOwner
δηλώνει την createBuffer(ICompilationUnit)
. Η ICompilationUnit
επεκτείνει την IOpenable
).
Επειδή οι αλλαγές περιλαμβάνουν την περιπλοκή της IWorkingCopy
και της IBufferFactory
, προτείνουμε να ασχοληθείτε και με τις δύο ταυτόχρονα. Οι λεπτομέρειες των καταργημένων στοιχείων έχουν ως εξής:
IWorkingCopy
(πακέτο org.eclipse.jdt.core
)
public void commit(boolean, IProgressMonitor)
καταργήθηκε.
ICompilationUnit
απευθείας:
public void commitWorkingCopy(boolean, IProgressMonitor)
wc.commit(b,monitor)
ως ((ICompilationUnit) wc).commitWorkingCopy(b,monitor)
public void destroy()
καταργήθηκε.
ICompilationUnit
απευθείας:
public void discardWorkingCopy(boolean, IProgressMonitor)
wc.destroy()
ως ((ICompilationUnit) wc).discardWorkingCopy()
public IJavaElement findSharedWorkingCopy(IBufferFactory)
καταργήθηκε.
ICompilationUnit
απευθείας:
public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
WorkingCopyOwner
αντικαθιστά την IBufferFactory.
public IJavaElement getOriginal(IJavaElement)
καταργήθηκε.
IJavaElement
απευθείας:
public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
ως elt.getPrimaryElement()
IWorkingCopy.getOriginal
, η IJavaElement.getPrimaryElement
δεν επιστρέφει null
εάν η λειτουργία λήψης δεν αποτελεί αντίγραφο εργασίας.public IJavaElement getOriginalElement()
καταργήθηκε.
ICompilationUnit
απευθείας:
public ICompilationUnit getPrimary()
wc.getOriginalElement()
ως ((ICompilationUnit) wc).getPrimary()
IWorkingCopy.getOriginalElement
, η IWorkingCopy.getPrimary
δεν επιστρέφει null
εάν η λειτουργία λήψης δεν αποτελεί αντίγραφο εργασίας.public IJavaElement[] findElements(IJavaElement)
καταργήθηκε.
ICompilationUnit
απευθείας.wc.findElements(elts)
ως ((ICompilationUnit) wc).findElements(elts)
public IType findPrimaryType()
καταργήθηκε.
ICompilationUnit
απευθείας.wc.findPrimaryType()
ως ((ICompilationUnit) wc).findPrimaryType()
public IJavaElement getSharedWorkingCopy(IProgressMonitor, IBufferFactory, IProblemRequestor)
καταργήθηκε.
ICompilationUnit
απευθείας:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner, IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
αντικαθιστά την IBufferFactory.
public IJavaElement getWorkingCopy()
καταργήθηκε.
ICompilationUnit
απευθείας:
public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
ως ((ICompilationUnit) wc).getWorkingCopy(null)
public IJavaElement getWorkingCopy(IProgressMonitor, IBufferFactory, IProblemRequestor)
καταργήθηκε.
ICompilationUnit
απευθείας:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner, IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
αντικαθιστά την IBufferFactory.
public boolean isBasedOn(IResource)
καταργήθηκε.
ICompilationUnit
απευθείας:
public boolean hasResourceChanged()
wc.isBasesOn(res)
ως ((ICompilationUnit) wc).hasResourceChanged()
public boolean isWorkingCopy()
καταργήθηκε.
ICompilationUnit
απευθείας.wc.isWorkingCopy()
ως ((ICompilationUnit) wc).isWorkingCopy()
public IMarker[] reconcile()
καταργήθηκε.
ICompilationUnit
απευθείας:
public void reconcile(boolean,IProgressMonitor)
wc.reconcile()
ως ((ICompilationUnit) wc).reconcile(false, null)
null
. Η μέθοδος με την οποία αντικαταστάθηκε δεν επιστρέφει αποτέλεσμα.public void reconcile(boolean, IProgressMonitor)
καταργήθηκε.
ICompilationUnit
απευθείας.wc.reconcile(b,monitor)
ως ((ICompilationUnit) wc).reconcile(b,monitor)
public void restore()
καταργήθηκε.
ICompilationUnit
απευθείας.wc.restore()
ως ((ICompilationUnit) wc).restore()
IType
(πακέτο org.eclipse.jdt.core
)
public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[], IProgressMonitor)
καταργήθηκε.
public ITypeHierarchy newSupertypeHierarchy(c, IProgressMonitor)
IWorkingCopy[]
σε ICompilationUnit[]
.public ITypeHierarchy newTypeHierarchy(IWorkingCopy[], IProgressMonitor)
καταργήθηκε.
public ITypeHierarchy newTypeHierarchy(ICompilationUnit[], IProgressMonitor)
IWorkingCopy[]
σε ICompilationUnit[]
.IClassFile
(πακέτο org.eclipse.jdt.core
)
public IJavaElement getWorkingCopy(IProgressMonitor, IBufferFactory)
καταργήθηκε.
public ICompilationUnit getWorkingCopy(WorkingCopyOwner, IProgressMonitor)
WorkingCopyOwner
αντικαθιστά την IBufferFactory.
JavaCore
(πακέτο org.eclipse.jdt.core
)
public IWorkingCopy getSharedWorkingCopies(IBufferFactory)
καταργήθηκε.
public ICompilationUnit[] getWorkingCopies(WorkingCopyOwner)
WorkingCopyOwner
αντικαθιστά την IBufferFactory.
ICompilationUnit[]
σε IWorkingCopy[]
.SearchEngine
(πακέτο org.eclipse.jdt.core
)
public SearchEngine(IWorkingCopy[])
καταργήθηκε.
public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
σε ICompilationUnit[]
.Η πρόσθετη λειτουργία org.eclipse.help, η οποία συνήθως περιείχε τα API και τα σημεία επέκτασης για συνεισφορά στο σύστημα βοήθειας και επέκτασή του, καθώς και για την εμφάνιση βοήθειας, πλέον περιέχει μόνο τα API και τα σημεία επέκτασης για τη συνεισφορά πόρων βοήθειας και την πρόσβαση σε αυτούς. Ένα τμήμα της προεπιλεγμένης υλοποίησης του περιβάλλοντος βοήθειας, το οποίο περιεχόταν σε αυτή την πρόσθετη λειτουργία, έχει μετακινηθεί σε μια νέα πρόσθετη λειτουργία org.eclipse.help.base μαζί με τα API για την επέκταση της υλοποίησης. Τα API και το σημείο επέκτασης για τη συνεισφορά περιβάλλοντος βοήθειας και την εμφάνιση βοήθειας έχουν μετακινηθεί στην πρόσθετη λειτουργία org.eclipse.ui. Αυτή η αναδιάρθρωση επιτρέπει στις εφαρμογές να έχουν μεγαλύτερη ευελιξία αναφορικά με το σύστημα βοήθειας. Η νέα δομή επιτρέπει στις εφαρμογές που βασίζονται στο γενικό πάγκο εργασίας να παρέχουν το δικό τους περιβάλλον βοήθειας και/ή υλοποίηση βοήθειας ή εξολοκλήρου παράλειψη του συστήματος βοήθειας.
Επειδή τα πακέτα σημείων επέκτασης και τα API που επηρεάζονται προορίζονται μόνο για χρήση από το σύστημα βοήθειας, είναι απίθανο να επηρεαστούν οι υπάρχουσες πρόσθετες λειτουργίες από αυτή την αλλαγή. Περιλαμβάνονται εδώ μόνο για να έχουμε μια πληρέστερη εικόνα:
Στην εκδοχή 3.0 έχει προστεθεί νέο API για την υλοποίηση προσαρμοσμένων αναζητήσεων. Το αρχικό API καταργήθηκε στην εκδοχή 3.0 και προτείνουμε οι πελάτες να συνδέονται στο νέο API στα πακέτα org.eclipse.search.ui και org.eclipse.search.ui.text.
Οι πελάτες πρέπει να δημιουργήσουν υλοποιήσεις των διεπαφών ISearchQuery
, ISearchResult
και ISearchResultPage
. Η υλοποίηση της ISearchResultPage
πρέπει να παρασχεθεί στο νέο σημείο επέκτασης org.eclipse.search.searchResultViewPages
.
Οι προεπιλεγμένες υλοποιήσεις των ISearchResult
και ISearchResultPage
παρέχονται στο πακέτο org.eclipse.search.ui.text
.
Πριν την εκδοχή 3.0 η κλήση της DirectoryDialog.setMessage(String σειρά χαρακτήρων) ή της MessageBox.setMessage(String σειρά χαρακτήρων) του SWT με τιμή null για τη σειρά χαρακτήρων θα είχε ως αποτέλεσμα ένα πλαίσιο διαλόγου χωρίς κείμενο στον τίτλο. Αυτή η συμπεριφορά δεν ήταν καθορισμένη (η μεταβίβαση της τιμής null δεν επιτρεπόταν ποτέ) και δημιουργούσε προβλήματα με την μέθοδο getMessage η οποία δεν επιτρεπόταν επιστρέφει την τιμή null. Στην εκδοχή 3.0 η μεταβίβαση τιμής null έχει ως αποτέλεσμα την εμφάνιση μιας εξαίρεσης IllegalArgumentException και οι προδιαγραφές έχουν αλλάξει για να το δηλώνουν αυτό επαναφέροντάς τη στη γραμμή με τη μέθοδο Dialog.setMessage στις υπερκλάσεις τους. Εάν χρησιμοποιείτε την Dialog.setMessage, βεβαιωθείτε ότι η σειρά χαρακτήρων που μεταβιβάζεται δεν είναι ποτέ null. Απλά μεταβιβάστε μια κενή σειρά χαρακτήρων εάν επιθυμείτε ένα πλαίσιο διαλόγου χωρίς κείμενο στον τίτλο.
Η υποστήριξη ταυτόχρονων λειτουργιών απαιτεί πιο σύνθετους τρόπους για την εμφάνιση της αποκλειστικής προόδου. Ως μέρος της προσπάθειας για τη βελτίωση της αποκριτικότητας υλοποιήθηκε επιπρόσθετη υποστήριξη προόδου στην κλάση IProgressService. Ο υπάρχον τρόπος για την εμφάνιση προόδου με την ProgressMonitorDialog λειτουργεί ακόμη. Ωστόσο, για τη βελτίωση της εμπειρίας για τους χρήστες προτείνουμε τη μετάβαση στη νέα IProgressService.
Το έγγραφο Showing Modal Progress in Eclipse 3.0 περιγράφει τον τρόπο μετάβασης στη νέα IProgressService.
Το σημείο επέκτασης των ομάδων ενεργειών για τον εντοπισμό και διόρθωση σφαλμάτων (org.eclipse.debug.ui.debugActionGroups) αφαιρέθηκε. Στο Eclipse 3.0 ο πάγκος εργασίας εισήγαγε υποστήριξη για την Activities μέσω του σημείου επέκτασης org.eclipse.platform.ui.activities. Αυτή η υποστήριξη παρέχει ό,τι παρείχαν και οι ομάδες ενεργειών για τον εντοπισμό και διόρθωση σφαλμάτων και επίσης είναι ευκολότερη στη χρήση της (υποστηρίζει μοτίβα αντί να καθορίζει διεξοδικά όλες τις ενέργειες) και διαθέτει ένα προγραμματιστικό API που την υποστηρίζει. Εάν αποτύχει η αφαίρεση των παραπομπών στο παλαιό σημείο επέκτασης, δεν θα προκύψουν σφάλματα. Οι παραπομπές στο σημείο επέκτασης απλά θα αγνοηθούν. Οι προμηθευτές προϊόντος ενθαρρύνονται να χρησιμοποιούν την υποστήριξη Activities του πάγκου εργασίας για το συσχετισμό ενεργειών λειτουργίας εντοπισμού και διόρθωσης σφαλμάτων ανάλογα τη γλώσσα με δραστηριότητες ανάλογα τη γλώσσα (για παράδειγμα, οι ενέργειες λειτουργίας εντοπισμού και διόρθωσης σφαλμάτων σε γλώσσα C++ θα μπορούσαν να συσχετιστούν με μια δραστηριότητα που ονομάζεται "Ανάπτυξη C++").
Η IBreakpointManager πλέον ορίζει τις μεθόδους setEnabled(boolean) και isEnabled(). Όταν απενεργοποιείται η λειτουργία διαχείρισης σημείων διακοπής, οι λειτουργίες εντοπισμού και διόρθωσης σφαλμάτων πρέπει να αγνοούν όλα τα καταχωρημένα σημεία διακοπής. Η πλατφόρμα εντοπισμού και διόρθωσης σφαλμάτων παρέχει επίσης ένα νέο μηχανισμό λειτουργίας ακρόασης, την IBreakpointManagerListener, η οποία επιτρέπει στους πελάτες να καταχωρούνται με τη λειτουργία διαχείρισης σημείων διακοπής για να ειδοποιούνται όταν αλλάζει η ενεργοποίησή της. Η προβολή "Σημεία διακοπής" καλεί αυτό το API από μια νέα ενέργεια εναλλαγής, η οποία επιτρέπει στο χρήστη την επιλογή "Παράλειψη όλων των σημείων διακοπής." Οι λειτουργίες εντοπισμού και διόρθωσης σφαλμάτων, οι οποίες δεν λαμβάνουν υπόψη τους την ενεργοποίηση της λειτουργία διαχείρισης σημείων διακοπής, θα εμφανιστούν κατά συνέπεια κάπως κατεστραμμένες εάν ο χρήστης επιχειρήσει να χρησιμοποιήσει αυτή τη λειτουργία.
Οι γλώσσες που είναι παρόμοιες με την Java (όπως οι JSP, SQLJ, JWS, κ.α.) πρέπει να είναι σε θέση να συμμετέχουν στην αναζήτηση Java. Συγκεκριμένα, οι υλοποιητές αυτού του είδους γλωσσών πρέπει να είναι σε θέση να:
Ένας τέτοιου είδους υλοποιητής καλείται συστατικό στοιχείο συμμετοχής αναζήτησης. Επεκτείνει την κλάση SearchParticipant. Τα συστατικά στοιχεία συμμετοχής αναζήτησης μεταβιβάζονται σε ερωτήματα αναζήτησης (δείτε τις SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).
Για την ευρετηριοποίηση ή τον εντοπισμό αντιστοιχιών χρειάζεται ένα συστατικό στοιχείο συμμετοχής αναζήτησης να ορίσει μια υποκλάση της SearchDocument, η οποία να μπορεί να ανακτήσει τα περιεχόμενα του εγγράφου αντικαθιστώντας είτε την getByteContents() είτε την getCharContents(). Επιστρέφεται μια χρήση αυτής της υποκλάσης στην getDocument(String).
Ένα συστατικό στοιχείο συμμετοχής αναζήτησης που επιθυμεί να ευρετηριοποιήσει κάποιο έγγραφο θα χρησιμοποιήσει την SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) για να προγραμματίσει την ευρετηριοποίηση του δεδομένου εγγράφου στο δεδομένο ευρετήριο. Μόλις το έγγραφο είναι έτοιμο για ευρετηριοποίηση, το υποκείμενο πλαίσιο καλεί την SearchParticipant.indexDocument(SearchDocument, IPath). Το συστατικό στοιχείο συμμετοχής αναζήτησης λαμβάνει το περιεχόμενο του εγγράφου, το αναλύει και προσθέτει καταχωρήσεις ευρετηρίου χρησιμοποιώντας την SearchDocument.addIndexEntry(char[], char[]).
Μόλις ολοκληρωθεί η ευρετηριοποίηση, μπορεί στη συνέχεια να τεθεί ερώτημα στα ευρετήρια και να εντοπιστούν οι αντιστοιχίες με τη χρήση της SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor). Η πρώτη ζητάει από κάθε συστατικό στοιχείο συμμετοχής αναζήτησης τα ευρετήρια που απαιτούνται από το ερώτημα αυτό με τη χρήση της SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope). Για κάθε καταχώρηση ευρετηρίου, οι οποία αντιστοιχεί στο δεδομένο μοτίβο, δημιουργείται ένα έγγραφο αναζήτησης με ερώτηση στο συστατικό στοιχείο συμμετοχής αναζήτησης (δείτε τη getDocument(String)). Όλα αυτά τα έγγραφα μεταβιβάζονται στο συστατικό στοιχείο συμμετοχής αναζήτησης έτσι ώστε να μπορεί να εντοπίζει αντιστοιχίες χρησιμοποιώντας την locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor). Το συστατικό στοιχείο συμμετοχής αναζήτησης ειδοποιεί την SearchRequestor για τις αντιστοιχίες αναζήτησης με τη χρήση της acceptSearchMatch(SearchMatch) και μεταβιβάζοντας μια χρήση υποκλάσης της SearchMatch.
Ένα συστατικό στοιχείο συμμετοχής αναζήτησης μπορεί να αναθέσει μέρος της εργασίας του στο προεπιλεγμένο συστατικό στοιχείο συμμετοχής αναζήτησης Java. Μια χρήση αυτού του προεπιλεγμένου συστατικού στοιχείου συμμετοχής λαμβάνεται με τη χρήση της SearchEngine.getDefaultSearchParticipant(). Για παράδειγμα όταν του ζητείται να εντοπίσει αντιστοιχίες, ένα συστατικό στοιχείο συμμετοχής SQLJ μπορεί να δημιουργήσει έγγραφα .java από τα δικά του έγγραφα .sqlj και να αναθέσει την εργασία στο προεπιλεγμένο συστατικό στοιχείο συμμετοχής μεταβιβάζοντάς του τα έγγραφα .java.