So überprüfen Sie ein Upgrade vor der Installation

Question

Wir haben eine Eclipse-Funktion, die lizenziert ist und die Lizenz wird von unserem eigenen Code behandelt. Der Benutzer kann auf unsere Update-Seite gehen und seine Funktion aktualisieren. Das Problem besteht darin, dass die Benutzerlizenz aktualisiert werden muss, bevor er das neue Upgrade verwenden kann.

Ich möchte die Feature-Version anhand der Benutzerlizenz validieren und den Benutzer warnen, dass seine Lizenz aktualisiert werden muss, bevor er installiert wird.

Ich dachte, ich würde dies mit einer benutzerdefinierten Eclipse P2 TouchPoint Aktion validateLicense tun.

Beispiel:

Mein Code genannt wird, wo ich die Version gegen die Lizenz des Benutzers zu validieren. Wenn es fehlschlägt, warne ich den Benutzer und er kann dann die Installation abbrechen.

Also meine erste Frage lautet:

• Muss ich dieses Recht bekommen, oder ist es eine andere Möglichkeit, dies zu tun?

Meine zweite Frage ist ziemlich einfach:

• Wo ich Eclipse erzählen meinen Code ausführen? Ich habe here at eclipse help gesucht, wo sie erklären, was es ist. Aber ich verstehe nicht, wo ich die Informationen für meinen Code eingeben soll. Ist es in der feature.xml.

Schließlich:

• Gibt es ein Beispiel, wie und touchPonts Verwendung p2 schaffen?

Answer 1

Ich habe eine benutzerdefinierte Aktion wie gezeigt here implementiert und ich habe ein System, das zu funktionieren scheint. Ich habe die "Touchpoint" -Erweiterung weggelassen, da sie in meinem Fall unnötig ist, aber der Rest ist der gleiche.

Meine Aktion wird während der Installationsphase meiner Funktion (instructions.install) ausgeführt, aber vielleicht könnte die Konfigurationsphase auch funktionieren. Sammelphase hat nicht funktioniert.

Die Aktion wird während des Installationsprozesses ausgeführt, nachdem der Download bereits durchgeführt wurde. Im Idealfall wäre es vor dem Download, aber es ist kein großes Problem für mich. Wenn Sie einen Fehlerstatus von der Aktion zurückgeben, wird die Installation abgebrochen.Es lässt einige heruntergeladene Dateien herum, aber sie werden nicht aktiviert und werden wahrscheinlich später von p2 Garbage Collector entfernt.

Ich schaffte es auch, einige interessantere Dinge zu tun. Mein Aktions-Plugin hat eine Abhängigkeit (optional und nicht-gierig) auf meinem Haupt-Plugin. So die Installation funktioniert wie folgt:

• Aktionen Plugin heruntergeladen
• Benutzerdefinierte Aktion ausgeführt wird
• Die Aktion stellt fest, ob mein Haupt-Plugin bereits installiert ist und wenn ja, es hinein ruft Informationen abzurufen Lizenzierung. Das Hauptplugin muss eine API für die Aktion bereitstellen. Die Aktion überprüft auch die Version des Haupt-Plugins, um festzustellen, ob die API vorhanden ist oder nicht.
• Die Aktion kann jetzt entscheiden, ob die Installation fortgesetzt oder abgebrochen werden soll. Es kann sogar mit dem Benutzer interagieren mit Display # syncExec (das ist, was der Code in checkTrust-Phase tut, so dass ich denke, es ist sicher). Bei Bedarf kann die Aktion auch erkennen, ob die Installation kopflos ist.

Einige gotchas:

• Aktion selbst versioniert werden müssen. Es ist die Version, die Sie in den Dateien plugin.xml und p2.inf deklarieren und unterscheidet sich von der Version des Plugins. Ich ersetze nur 1.0.0 mit der gleichen Version meines Plugins. Auf diese Weise wird immer die neueste Version des Action-Plugins heruntergeladen, bevor es ausgeführt wird. Das ist großartig, weil jetzt jedes Problem mit den Lizenzierungsregeln im Aktions-Plugin implementiert werden kann.
• Die Aktions-API wurde zwischen Eclipse 3.5 und 3.6 geändert. Ich werde wahrscheinlich Unterstützung für 3.5 fallen lassen, da es sowieso ziemlich alt ist.
• Aktionen Plugin sollte wahrscheinlich unterzeichnet werden. In meinem Fall ist das der Fall. Das System scheint mir fast zu mächtig zu sein, da Eclipse nur auf eine Update-Site verweist, um heruntergeladenen Code auszuführen.

Ich muss noch testen, wie das mit verschiedenen Versionen von Eclipse und anderen IDEs funktioniert. Ich habe einen seltsamen (nicht blockierenden) Fehler mit 3.6 gesehen. Die Ergebnisse sind jedoch vielversprechend und es sieht so aus, als würde das System tatsächlich funktionieren.

Answer 2

Touchpoints werden zur Installationszeit ausgeführt, was bedeutet, dass die Auflösung (Validierung) bereits erfolgt ist. Ich bin mir nicht sicher, dass sie helfen würden. Was ist mit dem Erstellen einer Installable Unit (IU) (oder Eclipse Feature), die die Lizenz darstellt, die der Benutzer installiert hat? Dann würden Sie eine Abhängigkeit von Ihrem Produkt zu dieser Lizenz setzen.

Erstellen Sie beispielsweise eine IU mit dem Namen com.mycompany.license (1.0.0). Sie würden eine andere namens com.mycompany.license (2.0.0) erstellen. Wenn Sie eine Lizenz installiert haben, wird die entsprechende IE dem Profil hinzugefügt.

Jetzt, wenn Sie Ihr Produkt installieren, benötigt die neue Version des Produkts die Lizenzversion 2.0.0. Wenn diese Lizenz nicht installiert wurde, würde die Auflösung fehlschlagen.

Macht das Sinn? Denkst du, das würde helfen?