Entwickeln Sie eine gemeinsame JAR-Bibliothek für verschiedene LIVERAY-Portlets

Question

Entwickeln Sie eine gemeinsame JAR-Bibliothek für verschiedene LIVERAY-Portlets

8

Ich brauche einige Utility-Klassen, die für drei verschiedene Liferay-Portlets üblich sind, sodass ich sie in einem Projekt entwickeln werde, das für meine Portlets freigegeben werden sollte.

Ich benutze Eclipse mit Liferay IDE-Plugin und meine Frage ist, welche Art von Projekt ist das, das ich brauche?

Ich meine, ist es ein einfaches Java-Projekt oder irgendeine Art von Liferay-Projekt?

jar portlet liferay

oggie0563 18.01.2013, 05:41

quelle

1 Antwort

Tags und Links jar portlet liferay

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Ist "x = new (Foo)" dasselbe wie "x = new Foo" für ein beliebiges Foo?

score 15 · Answer 1

Es gibt Möglichkeiten, wie Sie das tun können:

Erstellen Sie ein einfaches Java-Projekt. Packen Sie es als JAR-Datei. Setzen Sie die JAR-Datei in den globalen Klassenpfad. Im Fall von tomcat wäre der globale Klassenpfad ../tomcat-7.0.27/lib/ext/ .
Erstellen Sie ein einfaches Java-Projekt. Packen Sie es als JAR-Datei. Fügen Sie die JAR-Datei in den Klassenpfad jedes Portlets ein.
Erstellen Sie ein Liferay-Plugin-Portlet mit Hilfe von service-builder, fügen Sie die Utility-Klassen in das service -Paket ein, so dass die Utility-Klassen in [name-of-your-project]-service.jar gehen. Und dann in den Portlets which would need these classes specify the property required-deployment-contexts = [Name Ihres Projekts] in liveray-plugin-package.properties 'jedes Portlets.
Erstellen Sie ein Liferay-Plugin-Portlet mit service-builder, fügen Sie die Utility-Klassen in das service -Paket, so dass die Utility-Klassen in die [name-of-your-project]-service.jar und dann die [name-of-your-project]-service.jar in den globalen Klassenpfad und entfernen es aus dem WEB-INF/lib Ihres Portlet-Projekts, so dass es keinen Konflikt gibt.

Fazit

Verwenden Sie die 1. Methode , wenn der Code in den Dienstprogrammklassen nicht von der Liferay API abhängig ist. Dies würde jedoch einen Serverneustart erfordern, wenn die Dienstprogrammklassen geändert werden. Auch die Utility-Klassen könnten von Hooks verwendet werden, da sie im globalen Klassenpfad
Verwenden Sie die 2nd-Methode , wenn der Code in den Dienstprogrammklassen nicht von der Liferay-API abhängt. Dies würde keinen Neustart des Servers erfordern. Aber jede Änderung in den Utility-Klassen würde erfordern, dass Sie & amp; stelle alle Plugin-Portlets bereit, die dieses jar verwenden.
3rd-Methode: Dies hat die gleichen Einschränkungen oder Funktionen wie die 2nd-Methode, nur dass Sie Liferay API & amp; Ihre benutzerdefinierte Service-API in den Dienstprogrammklassen.
4. Methode: Dies hat dieselben Einschränkungen oder Funktionen wie die 1st-Methode, nur dass Sie Liferay API & amp; Ihre benutzerdefinierte Service-API in den Dienstprogrammklassen.

Also hier habe ich Pros & amp; Nachteile für Sie selbst zu entscheiden. Ich würde gerne wissen, ob es mehr Möglichkeiten (und viel sauberer) gibt, dies im Leben von Experten zu tun.