Απαιτούμενες αλλαγές κατά την υιοθέτηση των μηχανισμών και των API της εκδοχής 3.0

Αυτή η ενότητα περιγράφει τις αλλαγές που απαιτούνται εάν επιθυμείτε να αλλάξετε την πρόσθετη λειτουργίας σας εκδοχής 2.1 για να υιοθετήσετε τους μηχανισμούς και τα API εκδοχής 3.0.

Αποδέσμευση από το org.eclipse.core.runtime.compatibility

Το περιβάλλον εκτέλεσης του 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, αυτοί οι ρόλοι και οι αρμοδιότητες αναλύονται σε διακριτά αντικείμενα.

Δέσμη
Οι δέσμες αποτελούν τη μονάδα τμηματικής διάρθρωσης OSGi. Υπάρχει ένας φορτωτής κλάσεων για κάθε δέσμη και μπορούν να κατασκευαστούν παρόμοια του Eclipse γραφήματα εξαρτήσεων φόρτωσης κλάσεων μεταξύ των δεσμών. Οι δέσμες έχουν κύκλο ζωής για εκκίνηση και τερματισμό και το πλαίσιο OSGi μεταδίδει συμβάντα που σχετίζονται με δέσμες (π.χ., εγκατάσταση, ανάλυση, εκκίνηση, τερματισμό, απεγκατάσταση, ...) στα ενδιαφερόμενα μέρη. Σε αντίθεση με την κλάση Plugin του Eclipse, η κλάση Bundle του OSGi δεν μπορεί να επεκταθεί. Δηλαδή οι προγραμματιστές δεν έχουν την ευκαιρία να ορίσουν τη δική τους κλάση δεσμών.
BundleActivator
Η BundleActivator αποτελεί μια διεπαφή που ορίζεται από το πλαίσιο OSGi. Κάθε δέσμη μπορεί να ορίζει μια κλάση ενεργοποιητή δεσμών όπως και μια πρόσθετη λειτουργία μπορεί να ορίσει τη δική της κλάση Plugin. Γίνεται δημιουργία χρήσης της καθορισμένης κλάσης από το πλαίσιο και χρησιμοποιείται για την υλοποίηση της διεργασίας του κύκλου ζωής start() και stop(). Υπάρχει, ωστόσο, μια σημαντική διαφορά στη φύση αυτής της διεργασίας του κύκλου ζωής. Στο Eclipse συνηθίζεται (παρόλο που δεν συνιστάται) να εκτελούν οι κλάσεις Plugin τόσο την απόδοση αρχικών τιμών όσο και την καταχώρηση. Στο OSGi οι ενεργοποιητές πρέπει να εκτελέσουν μόνο την καταχώρηση. Η εκτέλεση μεγάλου πλήθους αποδόσεων αρχικών τιμών (ή οποιαδήποτε άλλη εργασία) στην BundleActivator.start() απειλεί τη ζωτικότητα του συστήματος.
BundleContext
Τα BundleContexts αποτελούν το μηχανισμό OSGi για την έκθεση γενικών λειτουργιών συστήματος σε μεμονωμένες δέσμες. Κάθε δέσμη διαθέτει μια μοναδική και ιδιωτική χρήση της BundleContext, την οποία μπορούν να χρησιμοποιήσουν για πρόσβαση στη λειτουργία συστήματος (π.χ., η getBundles() για την ανακάλυψη όλων των δεσμών στο σύστημα).
Πρόσθετη λειτουργία
Η νέα κλάση Plugin μοιάζει πολύ με την κλάση Plugin του αρχικού Eclipse με τις ακόλουθες εξαιρέσεις: Τα αντικείμενα Plugin δεν απαιτούνται ούτε γίνεται διαχείρισή τους πλέον από το περιβάλλον εκτέλεσης και έχουν καταργηθεί διάφορες μέθοδοι. Στην πραγματικότητα αποτελεί ένα μηχανισμό διευκόλυνσης που παρέχει χρήσιμες λειτουργίες και μηχανισμούς αλλά δεν είναι πλέον απολύτως απαραίτητος. Το μεγαλύτερο μέρος της λειτουργίας που παρέχεται εκεί διατίθεται επίσης στην κλάση Platform στο περιβάλλον εκτέλεσης.

Η Plugin υλοποιεί επίσης την BundleActivator. Αυτό αναγνωρίζει τη διευκόλυνση του να διαθέτει ένα κεντρικό αντικείμενο το οποίο αναπαριστά τον κύκλο ζωής και τη σημασιολογία μιας πρόσθετης λειτουργίας. Σημειώστε, ωστόσο, ότι αυτό δεν επιτρέπει την έντονη απόδοση αρχικών τιμών των δομών δεδομένων η οποία αποτελεί κοινή πρακτική στις πρόσθετες λειτουργίες σήμερα. Δεν μπορούμε να τονίσουμε αρκετά το γεγονός ότι οι πρόσθετες λειτουργίες μπορούν να ενεργοποιηθούν λόγω μιας σχεδόν περιφερειακής κλάσης στην οποία γινόταν παραπομπή κατά την επαλήθευση μιας κλάσης σε κάποια άλλη πρόσθετη λειτουργία. Δηλαδή, επειδή ενεργοποιήθηκε η πρόσθετη λειτουργία σας δεν σημαίνει απαραίτητα ότι η λειτουργία της απαιτείται. Σημειώστε επίσης ότι είστε ελεύθεροι να ορίσετε μια διαφορετική κλάση BundleActivator ή να μην έχετε κανένα ενεργοποιητή δέσμης.

Τα βήματα που απαιτούνται για τη σύνδεση μιας κλάσης εκδοχής 2.x Plugin στο Eclipse 3.0 εξαρτώνται από τη λειτουργία της κλάσης. Όπως περιγράφηκε παραπάνω, οι περισσότερες εργασίες κύκλου ζωής εκκίνησης ανήκουν σε μια από τις παρακάτω κατηγορίες:

Απόδοση αρχικών τιμών
Η δομή δεδομένων και η απόδοση αρχικών τιμών μοντέλου πραγματοποιείται συχνά στην Plugin.startup(). Η φυσική/εμφανής αντιστοίχιση θα είναι να πραγματοποιηθεί αυτή η εργασία σε μια BundleActivator.start(), δηλαδή να αφήσει τη λειτουργία στην κλάση Plugin. Αυτό δεν συνιστάται σε καμία περίπτωση. Όπως συμβαίνει και με τις πρόσθετες λειτουργίες εκδοχής 2.x, οι πρόσθετες λειτουργίες/δέσμες εκδοχής 3.0 μπορούν να εκκινήσουν για πολλούς διαφορετικούς λόγους σε πολλές διαφορετικές περιπτώσεις.
Ένα πραγματικό παράδειγμα αυτού από το Eclipse 2.0 θα διαλευκάνει αυτή την περίπτωση. Υπήρχε μια πρόσθετη λειτουργία, η οποία απέδιδε αρχικές τιμές σε ένα μεγάλο μοντέλο, που απαιτούσε τη φόρτωση περίπου 11MB κώδικα και πολλά megabyte δεδομένων. Υπήρχαν αρκετά κοινές περιπτώσεις χρήσης όπου αυτή η πρόσθετη λειτουργία ενεργοποιούταν για να ανακαλυφθεί εάν στο εικονίδιο έργου, που παρουσιαζόταν στη λειτουργία πλοήγησης, θα έπρεπε να χρησιμοποιηθούν διακριτικά με μια συγκεκριμένη σήμανση. Αυτή η δοκιμή δεν απαιτούσε καμία ενέργεια απόδοσης αρχικών τιμών στην startup() αλλά όλοι οι χρήστες σε όλες τις περιπτώσεις χρήσης έπρεπε να ξοδέψουν μνήμη και χρόνο για αυτή την έντονη λειτουργία απόδοσης αρχικών τιμών.
Η εναλλακτική προσέγγιση ήταν να εκτελεστεί η απόδοση αρχικών τιμών με το συνηθισμένο χρονοβόρο τρόπο. Για παράδειγμα, αντί να γίνει η απόδοση αρχικών τιμών στα μοντέλα κατά την ενεργοποίηση της πρόσθετης λειτουργίας/δέσμης, να γίνεται όταν πραγματικά είναι απαραίτητο (π.χ., σε μια συγκεντρωμένη μέθοδο πρόσβασης μοντέλου). Για πολλές περιπτώσεις χρήσης αυτό θα χρειαστεί σχεδόν τον ίδιο χρόνο αλλά για κάποια άλλα σενάρια αυτή η προσέγγιση θα αναβάλει την απόδοση αρχικών τιμών (ίσως επ' άπειρον). Συνιστάμε να μην βιαστείτε κατά τη σύνδεση των πρόσθετων λειτουργιών εκδοχής 2.1 και να επανεξετάσετε τη στρατηγική απόδοσης αρχικών τιμών που χρησιμοποιείται.
Καταχώρηση
Η εκκίνηση της πρόσθετης λειτουργίας αποτελεί την κατάλληλη χρονική στιγμή για την καταχώρηση λειτουργιών ακρόασης, υπηρεσιών κ.α. και την εκκίνηση νημάτων επεξεργασίας παρασκηνίου (π.χ., λειτουργία ακρόασης σε μια δίοδο επικοινωνίας). Η Plugin.start() μπορεί να αποτελεί ένα λογικό μέρος για την εκτέλεση αυτής της εργασίας. Μπορεί επίσης να είναι λογικό να καθυστερήσει μέχρι να ενεργοποιηθεί αυτόματα κάποια άλλη (π.χ., η χρήση μιας συγκεκριμένης λειτουργίας ή στοιχείου δεδομένων).
Καθολικά δεδομένα πρόσθετων λειτουργιών
Η κλάση σας Plugin μπορεί να συνεχίσει να έχει αυτό το ρόλο. Το κύριο ζήτημα είναι ότι τα αντικείμενα Plugin δεν είναι καθολικά προσβάσιμα μέσω μιας λίστας την οποία διαχειρίζεται το σύστημα. Στο Eclipse 2.x μπορούσατε να ανακαλύψετε οποιαδήποτε αντικείμενα Plugin πρόσθετων λειτουργιών μέσω του μητρώου πρόσθετων λειτουργιών. Αυτό πλέον δεν είναι δυνατόν. Στις περισσότερες περιπτώσεις αυτό το είδος πρόσβασης δεν απαιτείται. Τα Plugins στα οποία υπάρχει πρόσβαση μέσω του μητρώου συνήθως χρησιμοποιούνται σαν γενικά Plugins παρά για την κλήση μεθόδων ειδικά για τομέα. Το αντίστοιχο επίπεδο δυνατότητας μπορεί να αποκτηθεί με την πρόσβαση στα αντίστοιχα αντικείμενα Bundle και τη διαχείρισή τους.

Μητρώα και το μοντέλο πρόσθετων λειτουργιών

Στο νέο περιβάλλον εκτέλεσης υπάρχει ένας διαχωρισμός μεταξύ των πληροφοριών και των δομών, που απαιτούνταν για την εκτέλεση μιας πρόσθετης λειτουργίας, και αυτών που σχετίζονταν με τις επεκτάσεις και τα σημεία επέκτασης μιας πρόσθετης λειτουργίας. Οι πρώτες ορίζονται και γίνεται διαχείρισή τους από την προδιαγραφή πλαισίου OSGi. Οι τελευταίες αποτελούν έννοιες ειδικά για το Eclipse και προστίθενται από τον κώδικα περιβάλλοντος εκτέλεσης του Eclipse. Αντίστοιχα, το αρχικό μητρώο πρόσθετων λειτουργιών και τα σχετικά αντικείμενα έχουν χωριστεί σε δέσμες OSGi και στο μητρώο επεκτάσεων του Eclipse .

Τα μέρη της IPluginRegistry που ασχολούνται με την προδιαγραφή εκτέλεσης (π.χ., οι IPluginDescriptor, ILibrary, IPrequisite) έχουν καταργηθεί και τα εναπομείναντα μέρη που σχετίζονται με επεκτάσεις και σημεία επέκτασης έχουν μετακινηθεί στην IExtensionRegistry. Επιπλέον, τα επονομαζόμενα αντικείμενα μοντέλων που σχετίζονται με το μητρώο πρόσθετων λειτουργιών στο σύνολό του έχουν πλέον καταργηθεί. Αυτά τα είδη αναπαριστώνται και αποδίδονται σε αυτά αρχικές τιμές από το περιβάλλον εκτέλεσης κυρίως για την υποστήριξη εργαλείων όπως το PDE. Δυστυχώς, ήταν συχνό το φαινόμενο του επιπέδου πληροφοριών που απαιτούνταν να ξεπερνούσε τις δυνατότητες ή τα ενδιαφέροντα του περιβάλλοντος εκτέλεσης (π.χ., αποθήκευση αριθμών γραμμών για στοιχεία plugin.xml) και τελικά οι πιθανοί καταναλωτές των πληροφοριών του περιβάλλοντος εκτέλεσης έπρεπε να διατηρούν ούτως ή άλλως τις δομές τους.

Στο νέο περιβάλλον εκτέλεσης έχουμε επαναθεωρήσει τις λειτουργίες που παρέχονται από το περιβάλλον εκτέλεσης και πλέον παρέχονται μόνο εκείνες που είναι είτε βασικές για την εκτέλεση του περιβάλλοντος εκτέλεσης είτε είναι εξαιρετικά δύσκολες να γίνουν από άλλους. Όπως αναφέρθηκε παραπάνω, τα αντικείμενα μοντέλων μητρώου πρόσθετων λειτουργιών έχουν καταργηθεί όπως και το API ανάλυσης πρόσθετων λειτουργιών. Το νέο μητρώο επεκτάσεων διατηρεί τις απαραίτητες πληροφορίες που σχετίζονται με τις επεκτάσεις. Μια νέα δομή κατάστασης (δείτε το org.eclipse.osgi.service.resolver.State και φιλικά στοιχεία) αναπαριστά και επιτρέπει το χειρισμό των απαραίτητων πληροφοριών που σχετίζονται με την εκτέλεση.

Δομή τμήματος κώδικα NL

Στο 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. Πρέπει να γίνει ενημέρωση του τμήματος κώδικα αναφορικά με τη νέα δομή.

Επισκόπηση αλλαγών API

org.eclipse.core.boot (πακέτο org.eclipse.core.boot)

Καταργήθηκε ολόκληρο το πακέτο 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.

IExtension και IExtensionPoint (πακέτο org.eclipse.core.runtime)

Η μέθοδος getDeclaringPlugin() (και στις δύο κλάσεις) προσφέρει μια ανοδική σύνδεση στην πρόσθετη λειτουργία η οποία δηλώνει την επέκταση ή το σημείο επέκτασης (αντίστοιχα). Το νέο μοντέλο μητρώου διαχωρίζει τις πτυχές εκτέλεσης των πρόσθετων λειτουργιών από τις πτυχές επέκτασης/σημείου επέκτασης και δεν περιέχει πλέον την IPluginDescriptors. Οι χρήστες αυτού του API πρέπει να εξετάσουν τη νέα μέθοδο getParentIdentifier() που βρίσκεται τόσο στην IExtension όσο και στην IExtensionPoint.

ILibrary, IPluginDescriptor, IPluginRegistry και IPrerequisite (πακέτο org.eclipse.core.runtime)

Στο αρχικό περιβάλλον εκτέλεσης το μητρώο πρόσθετων λειτουργιών διαχειριζόταν μια πλήρη εικόνα των ρυθμίσεων του περιβάλλοντος εκτέλεσης. Στο Eclipse 3.0 αυτή η εικόνα χωρίζεται μεταξύ του πλαισίου OSGi και του μητρώου επεκτάσεων. Για αυτό το λόγο αυτές οι κλάσεις έχουν καταργηθεί. Οι σημειώσεις κατάργησης περιέχουν λεπτομέρειες σχετικά με τον τρόπο με τον οποίο πρέπει να ενημερώσετε τον κώδικά σας.

Platform και Plugin (πακέτο org.eclipse.core.runtime)

Στο νέο περιβάλλον εκτέλεσης δεν γίνεται διαχείριση των αντικειμένων Plugin από το περιβάλλον εκτέλεσης και συνεπώς δεν υπάρχει γενικά πρόσβαση σε αυτά μέσω της Platform. Ομοίως, το μητρώο πρόσθετων λειτουργιών δεν υπάρχει ούτε παρέχει πρόσβαση στα αρχεία περιγραφής πρόσθετων λειτουργιών. Υπάρχουν διαθέσιμες, ωστόσο, κατάλληλες μέθοδοι αντικατάστασης και περιγράφονται λεπτομερώς στο Javadoc των καταργημένων μεθόδων σε αυτές τις κλάσεις.

org.eclipse.core.runtime.model (πακέτο org.eclipse.core.runtime.model)

Όλα τα είδη σε αυτό το πακέτο έχουν καταργηθεί. Ανατρέξτε στην ανάλυση στην ενότητα μητρώα για περισσότερες πληροφορίες.

IWorkspaceRunnable και IWorkspace.run (πακέτο org.eclipse.core.resources)

Οι πελάτες της μεθόδου IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) πρέπει να επιστρέψουν σε αυτές τις χρήσεις της μεθόδου και να εξετάσουν τη χρήση της μεθόδου ενισχυμένων δυνατοτήτωνIWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). Η παλαιά μέθοδος IWorkspace.run λαμβάνει ένα κλείδωμα ολόκληρου του χώρου εργασίας για τη διάρκεια της IWorkspaceRunnable. Αυτό σημαίνει ότι μια λειτουργία που πραγματοποιείται με αυτή τη μέθοδο δεν θα είναι ποτέ σε θέση να εκτελεστεί ταυτόχρονα με άλλες λειτουργίες που αλλάζουν το χώρο εργασίας. Στο Eclipse 3.0 πολλές μακρόχρονες λειτουργίες έχουν μετακινηθεί σε νήματα παρασκηνίου, ώστε η πιθανότητα διενέξεων μεταξύ λειτουργιών έχει σε μεγάλο βαθμό αυξηθεί. Εάν μια αποκλειστική λειτουργία στο προσκήνιο μπλοκάρεται από μια μακρόχρονη λειτουργία στο παρασκήνιο, το περιβάλλον χρήστη μπλοκάρεται μέχρι να ολοκληρωθεί η λειτουργία στο παρασκήνιο ή μέχρι να ακυρωθεί μια από τις λειτουργίες.

Η προτεινόμενη λύση είναι η εναλλαγή όλων των παραπομπών στην παλαιά IWorkspace.run έτσι ώστε να χρησιμοποιούν τη νέα μέθοδο με μια παράμετρο κανόνων προγραμματισμού. Ο κανόνας προγραμματισμού πρέπει να αποτελεί τον πιο ιδιαίτερα ακριβή κανόνα που να περιλαμβάνει τους κανόνες για όλες τις αλλαγές από αυτή τη λειτουργία. Εάν η λειτουργία επιχειρήσει να τροποποιήσει πόρους εκτός της εμβέλειας του κανόνα προγραμματισμού, θα παρουσιαστεί μια εξαίρεση του χρόνου εκτέλεσης. Ο ακριβής κανόνας προγραμματισμού, ο οποίος απαιτείται από μια δεδομένη λειτουργία χώρου εργασίας, δεν έχει καθοριστεί και μπορεί να αλλάξει ανάλογα με τον εγκατεστημένο παροχέα χώρου αποθήκευσης σε ένα δεδομένα έργο. Η μέθοδος κατασκευής IResourceRuleFactory πρέπει να χρησιμοποιείται για τη λήψη του κανόνα προγραμματισμού για μια λειτουργία αλλαγής πόρων. Εάν επιθυμείτε, μπορεί να χρησιμοποιηθεί μια κλάση MultiRule για τον καθορισμό πολλαπλών κανόνων για πόρους και η μέθοδος διευκόλυνσης MultiRule.combine μπορεί να χρησιμοποιηθεί για το συνδυασμό κανόνων από διάφορες λειτουργίες αλλαγής πόρων.

Εάν δεν απαιτείται κλείδωμα, μπορεί να χρησιμοποιηθεί ένας κανόνας προγραμματισμού null. Με αυτό τον τρόπο επιτρέπεται στο εκτελέσιμο στοιχείο να τροποποιεί όλους τους πόρους στο χώρο εργασίας αλλά δεν αποτρέπει άλλα νήματα επίσης να τροποποιούν ταυτόχρονα το χώρο εργασίας. Για απλές αλλαγές στο χώρο εργασίας αυτός αποτελεί συχνά την ευκολότερη και περισσότερο φιλική λύση όσον αφορά την ταυτόχρονη χρήση.

IWorkbenchPage (πακέτο org.eclipse.ui)

IEditorDescriptor (πακέτο org.eclipse.ui)

ISharedImages (πακέτο org.eclipse.ui)

IWorkbenchActionConstants (πακέτο org.eclipse.ui)

IWorkbenchPreferenceConstants (πακέτο org.eclipse.ui)

IExportWizard (πακέτο org.eclipse.ui)

IImportWizard (πακέτο org.eclipse.ui)

INewWizard (πακέτο org.eclipse.ui)

WorkbenchHelp (πακέτο org.eclipse.ui.help)

IHelp (πακέτο org.eclipse.help)

ITextEditorActionConstants (πακέτο org.eclipse.ui.texteditor)

IAbstractTextEditorHelpContextIds (πακέτο org.eclipse.ui.texteditor)

BasicTextEditorActionContributor (πακέτο org.eclipse.ui.texteditor)

TextEditorActionContributor (πακέτο org.eclipse.ui.editors.text)

σημείο επέκτασης annotationTypes (πρόσθετη λειτουργία org.eclipse.ui.editors)

Υπάρχει πλέον ρητή έννοια ενός είδους σημείωσης. Ανατρέξτε στις 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 υλοποιεί αυτή τη διεπαφή.

σημείο επέκτασης markerAnnotationSpecification (πρόσθετη λειτουργία org.eclipse.ui.editors)

Το είδος σημείωσης αποτελεί το κλειδί για την εύρεση της συσχετισμένης προδιαγραφής σημείωσης δείκτη. Καθώς τα είδη σημειώσεων μπορούν να επεκτείνουν άλλα είδη σημειώσεων, υπάρχει επίσης μια άδηλη σχέση μεταξύ των προδιαγραφών σημειώσεων δείκτη. Συνεπώς μια προδιαγραφή σημείωσης δείκτη για ένα δεδομένο είδος σημείωσης ολοκληρώνεται από τις προδιαγραφές σημείωσης δείκτη που δίνονται για τα υπερ-είδη του δεδομένου είδους σημείωσης. Επομένως, η προδιαγραφή σημείωσης δείκτη δεν χρειάζεται να είναι ολοκληρωμένη όπως απαιτούνταν παλαιότερα. Οι προδιαγραφές σημείωσης δείκτη ανακτώνται από την 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).

Μετάβαση στο σημείο επέκτασης annotationTypes (πρόσθετη λειτουργία org.eclipse.ui.editors)

Τα ακόλουθα είδη σημειώσεων δηλώνονται από την πρόσθετη λειτουργία 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.

ILaunchConfigurationType (πακέτο org.eclipse.debug.core)

Με την εισαγωγή των καταστάσεων λειτουργίας εκκίνησης με δυνατότητα επέκτασης στην εκδοχή 3.0, μπορεί να υπάρχουν περισσότεροι από ένας εκπρόσωποι εκκίνησης για ένα είδος ρυθμίσεων εκκίνησης. Οι εκδόσεις πριν την 3.0 υποστήριζαν μόνο έναν εκπρόσωπο εκκίνησης για κάθε είδος ρυθμίσεων εκκίνησης. Η μέθοδος ILaunchConfigurationType.getDelegate() έχει καταργηθεί. Η μέθοδος getDelegate(String mode) πρέπει να χρησιμοποιηθεί στη θέση του για την ανάκτηση του εκπροσώπου εκκίνησης για μια συγκεκριμένη κατάσταση λειτουργίας εκκίνησης. Η καταργημένη μέθοδος έχει αλλάξει ώστε να επιστρέφει τον εκπρόσωπο εκκίνησης για την κατάσταση λειτουργίας run.

ILaunchConfigurationTab και ILaunchConfigurationTabGroup (πακέτο org.eclipse.debug.ui)

Οι ομάδες καρτέλας εκκίνησης και οι καρτέλες εκκίνησης δεν ειδοποιούνται κατά την ολοκλήρωση μιας εκκίνησης. Η μέθοδος launched(ILaunch) στις διεπαφές ILaunchConfigurationTab και ILaunchConfigurationTabGroup καταργήθηκε και δεν καλείται πλέον. Εάν βασίζεστε σε αυτή τη μέθοδο για τη λειτουργία εκκίνησης μπορεί να αποδειχθεί προβληματική, εφόσον οι καρτέλες υπάρχουν μόνο κατά την εκτέλεση της εκκίνησης από το πλαίσιο διαλόγου εκκίνησης. Επίσης, με την εισαγωγή της εκκίνησης στο παρασκήνιο, αυτή η μέθοδος δεν μπορεί να καλείται, καθώς το πλαίσιο διαλόγου εκκίνησης κλείνει πριν εμφανιστεί το αντικείμενο εκκίνησης που προκύπτει.

ILaunchConfigurationTab και AbstractLaunchConfigurationTab (πακέτο org.eclipse.debug.ui)

Έχουν προστεθεί δύο μέθοδοι στη διεπαφή ILaunchConfigurationTab - η ενεργοποιημένη και η απενεργοποιημένη. Οι νέες αυτές μέθοδοι κύκλου ζωής καλούνται κατά την είσοδο και την έξοδο μιας καρτέλας αντίστοιχα. Οι υπάρχουσες υλοποιήσεις της ILaunchConfigurationTab, η οποία αποτελεί υποκλάση της αφηρημένης κλάσης που παρέχεται από την πρόσθετη λειτουργία εντοπισμού και διόρθωσης σφαλμάτων (AbstractLaunchConfigurationTab), έχουν συμβατότητα με αρχεία δυαδικής μορφής, εφόσον οι μέθοδοι υλοποιούνται στην αφηρημένη κλάση.

Σε παλαιότερες εκδόσεις μια καρτέλα λάμβανε το μήνυμα initializeFrom κατά την ενεργοποίησή της και το μήνυμα performApply κατά την απενεργοποίηση της. Με αυτόν τον τρόπο το πλαίσιο καρτέλας ρυθμίσεων εκκίνησης παρείχε επικοινωνία μεταξύ των καρτέλων μέσω ρυθμίσεων εκκίνησης (ενημερώνοντας τις ρυθμίσεις με τις τρέχουσες τιμές γνωρισμάτων κατά την έξοδο μιας καρτέλας και ενημερώνοντας την πρόσφατα εισαγόμενη καρτέλα). Ωστόσο, εφόσον πολλές καρτέλες δεν εκτελούν επικοινωνία μεταξύ των καρτέλων, αυτό μπορεί να αποδειχθεί ανεπαρκές. Επίσης, δεν υπήρχε τρόπος να ξεχωρίσει μια καρτέλα που ενεργοποιείται από μια καρτέλα που εμφανίζει επιλεγμένες ρυθμίσεις εκκίνησης για πρώτη φορά. Οι μέθοδοι που μόλις προστέθηκαν επιτρέπουν στις καρτέλες να ξεχωρίζουν μεταξύ της ενεργοποίησης και της απόδοσης αρχικών τιμών καθώς και μεταξύ της απενεργοποίησης και της αποθήκευσης τρεχουσών τιμών.

Η προεπιλεγμένη υλοποίηση της activated, που παρέχεται από την καρτέλα "Αφηρημένη", καλεί την initializeFrom. Ομοίως η προεπιλεγμένη υλοποίηση της deactivated καλεί την performApply. Οι καρτέλες που επιθυμούν να εκμεταλλευτούν το νέο API πρέπει να αντικαταστήσουν αυτές τις μεθόδους όπως απαιτείται. Γενικά, για καρτέλες που δεν εκτελούν επικοινωνία μεταξύ καρτελών, η προτεινόμενη προσέγγιση είναι να υλοποιήσετε εκ νέου αυτές τις μεθόδους ώστε να μην εκτελούν καμία ενέργεια.

launchConfigurationTabGroup σημείο επέκτασης Type (πακέτο org.eclipse.debug.ui)

Σε παλαιότερες εκδόσεις, η εναλλαγή προοπτικών καθοριζόταν στις ρυθμίσεις εκκίνησης, μέσω των γνωρισμάτων ρυθμίσεων εκκίνησης ATTR_TARGET_DEBUG_PERSPECTIVE και ATTR_TARGET_RUN_PERSPECTIVE. Με την προσθήκη των καταστάσεων λειτουργίας εκκίνησης με δυνατότητα επέκτασης στην εκδοχή 3.0, αυτή η προσέγγιση δεν ευσταθεί. Η εναλλαγή προοπτικών καθορίζεται από τη βάση είδους ρυθμίσεων εκκίνησης, για κάθε κατάσταση λειτουργίας που ένα είδος ρυθμίσεων εκκίνησης υποστηρίζει. Προστέθηκε API στο DebugUITools για τον ορισμό και τη λήψη της προοπτικής που συσχετίζεται με ένα είδος ρυθμίσεων εκκίνησης για μια συγκεκριμένη κατάσταση λειτουργίας εκκίνησης.

Ένα επιπρόσθετο προαιρετικό στοιχείο launchMode προστέθηκε στο σημείο επέκτασης launchConfigurationTabGroup, το οποίο επιτρέπει σε ομάδα καρτέλων που συνεισφέρεται να καθορίσει μια προεπιλεγμένη προοπτική για ένα είδος και μια κατάσταση λειτουργίας ρυθμίσεων εκκίνησης.

Από το περιβάλλον χρήστη του Eclipse, οι χρήστες μπορούν να τροποποιήσουν την προοπτική που συσχετίζεται με ένα είδος ρυθμίσεων εκκίνησης ανοίγοντας το πλαίσιο διαλόγου εκκίνησης και επιλέγοντας έναν κόμβο είδους ρυθμίσεων εκκίνησης στη διακλάδωση (παρά μεμονωμένες ρυθμίσεις). Εμφανίζεται μια καρτέλα η οποία επιτρέπει στο χρήστη να ορίσει μια προοπτική για κάθε κατάσταση λειτουργίας εκκίνησης που υποστηρίζεται.

[Μόνο για το JDT] IVMRunner (πακέτο org.eclipse.jdt.launching)

Προστέθηκαν δύο μέθοδοι στην κλάση VMRunnerConfiguration για την υποστήριξη της ρύθμισης και της ανάκτησης μεταβλητών περιβάλλοντος. Οι υλοποιητές της IVMRunner πρέπει να καλέσουν την VMRunnerConfiguration.getEnvironment() και να μεταβιβάσουν αυτό το περιβάλλον στο JVM που εκτελείται. Οι πελάτες που χρησιμοποιούν την DebugPlugin.exec(String[] cmdLine, File workingDirectory) μπορούν να το επιτύχουν αυτό καλώντας στη θέση της την DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp). Απλά αρκεί η μεταβίβαση του αποτελέσματος από την getEnvironment().

[Μόνο για το JDT] Κλάσεις VMRunnerConfiguration και Bootstrap (πακέτο org.eclipse.jdt.launching)

Σε προηγούμενες εκδόσεις η VMRunnerConfiguration είχε ένα γνώρισμα για την περιγραφή μιας διαδρομής εκκίνησης. Αυτό το γνώρισμα αποτελεί μια συλλογή των Strings που θα καθοριστούν στο όρισμα Xbootclasspath. Προστέθηκαν τρία νέα γνωρίσματα στη κλάση VMRunnerConfiguration για την υποστήριξη των JVM που επιτρέπουν την πρόταση και την προσάρτηση στη διαδρομή εκκίνησης. Οι νέες μέθοδοι/γνωρίσματα που προστέθηκαν είναι:

Το παλαιό γνώρισμα getBootClassPath() υπάρχει ακόμα και περιέχει μια πλήρη διαδρομή αντίστοιχη με αυτή των τριών νέων γνωρισμάτων. Ωστόσο, οι κλάσεις VMRunners, που υποστηρίζουν τις νέες επιλογές της διαδρομής εκκίνησης, πρέπει να εκμεταλλευτούν τα νέα γνωρίσματα.

[Μόνο για το JDT] Βελτιωμένη υποστήριξη για αντίγραφα εργασίας (πακέτο org.eclipse.jdt.core)

Έχει γίνει επανεπεξεργασία της λειτουργίας αντιγράφου εργασίας μοντέλου 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, προτείνουμε να ασχοληθείτε και με τις δύο ταυτόχρονα. Οι λεπτομέρειες των καταργημένων στοιχείων έχουν ως εξής:

Αναδιάρθρωση της πρόσθετης λειτουργίας org.eclipse.help

Η πρόσθετη λειτουργία org.eclipse.help, η οποία συνήθως περιείχε τα API και τα σημεία επέκτασης για συνεισφορά στο σύστημα βοήθειας και επέκτασή του, καθώς και για την εμφάνιση βοήθειας, πλέον περιέχει μόνο τα API και τα σημεία επέκτασης για τη συνεισφορά πόρων βοήθειας και την πρόσβαση σε αυτούς. Ένα τμήμα της προεπιλεγμένης υλοποίησης του περιβάλλοντος βοήθειας, το οποίο περιεχόταν σε αυτή την πρόσθετη λειτουργία, έχει μετακινηθεί σε μια νέα πρόσθετη λειτουργία org.eclipse.help.base μαζί με τα API για την επέκταση της υλοποίησης. Τα API και το σημείο επέκτασης για τη συνεισφορά περιβάλλοντος βοήθειας και την εμφάνιση βοήθειας έχουν μετακινηθεί στην πρόσθετη λειτουργία org.eclipse.ui. Αυτή η αναδιάρθρωση επιτρέπει στις εφαρμογές να έχουν μεγαλύτερη ευελιξία αναφορικά με το σύστημα βοήθειας. Η νέα δομή επιτρέπει στις εφαρμογές που βασίζονται στο γενικό πάγκο εργασίας να παρέχουν το δικό τους περιβάλλον βοήθειας και/ή υλοποίηση βοήθειας ή εξολοκλήρου παράλειψη του συστήματος βοήθειας.

Επειδή τα πακέτα σημείων επέκτασης και τα API που επηρεάζονται προορίζονται μόνο για χρήση από το σύστημα βοήθειας, είναι απίθανο να επηρεαστούν οι υπάρχουσες πρόσθετες λειτουργίες από αυτή την αλλαγή. Περιλαμβάνονται εδώ μόνο για να έχουμε μια πληρέστερη εικόνα:

Νέο 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.

Κενά μηνύματα στις MessageBox και DirectoryDialog (πακέτο org.eclipse.swt.widgets)

Πριν την εκδοχή 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++").

Η BreakpointManager μπορεί να απενεργοποιηθεί

Η IBreakpointManager πλέον ορίζει τις μεθόδους setEnabled(boolean) και isEnabled(). Όταν απενεργοποιείται η λειτουργία διαχείρισης σημείων διακοπής, οι λειτουργίες εντοπισμού και διόρθωσης σφαλμάτων πρέπει να αγνοούν όλα τα καταχωρημένα σημεία διακοπής. Η πλατφόρμα εντοπισμού και διόρθωσης σφαλμάτων παρέχει επίσης ένα νέο μηχανισμό λειτουργίας ακρόασης, την IBreakpointManagerListener, η οποία επιτρέπει στους πελάτες να καταχωρούνται με τη λειτουργία διαχείρισης σημείων διακοπής για να ειδοποιούνται όταν αλλάζει η ενεργοποίησή της. Η προβολή "Σημεία διακοπής" καλεί αυτό το API από μια νέα ενέργεια εναλλαγής, η οποία επιτρέπει στο χρήστη την επιλογή "Παράλειψη όλων των σημείων διακοπής." Οι λειτουργίες εντοπισμού και διόρθωσης σφαλμάτων, οι οποίες δεν λαμβάνουν υπόψη τους την ενεργοποίηση της λειτουργία διαχείρισης σημείων διακοπής, θα εμφανιστούν κατά συνέπεια κάπως κατεστραμμένες εάν ο χρήστης επιχειρήσει να χρησιμοποιήσει αυτή τη λειτουργία.

[Μόνο για το JDT] Τα συστατικά στοιχεία συμμετοχής για την αναζήτηση Java (πακέτο org.eclipse.jdt.core.search)

Οι γλώσσες που είναι παρόμοιες με την 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.