Il modo migliore per costruire un sistema di plugin con Java

Come implementeresti un sistema plug-in per la tua applicazione Java?

È possibile avere un sistema facile da usare (per lo sviluppatore) che ottenga i seguenti risultati:

• Gli utenti inseriscono i loro plugin in una sottodirectory dell'app
• Il plugin può fornire una schermata di configurazione
• Se si utilizza un framework, la licenza è compatibile con lo sviluppo commerciale?

Per prima cosa hai bisogno di un'interfaccia che tutti i plugin devono implementare, ad es

public interface Plugin {
    public void load(PluginConfiguration pluginConfiguration);
    public void run();
    public void unload();
    public JComponent getConfigurationPage();
}

Gli autori dei plugin dovrebbero quindi raggruppare i loro plugin in file JAR. Le applicazioni aprono il file JAR e potrebbero quindi utilizzare un attributo del manifest JAR o l'elenco di tutti i file nel file JAR per trovare la classe che implementa l'interfaccia del plug-in. Crea un'istanza per quella classe, il plugin è pronto per partire.

Ovviamente potresti anche voler implementare un qualche tipo di sandboxing in modo che il plugin sia limitato in ciò che può e non può fare. Ho creato una piccola applicazione di prova (e ho scritto sul suo blog ) composta da due plugin, uno dei quali non ha accesso alle risorse locali.

Usa OSGi .

È il fondamento del sistema di plug-in Eclipse. Equinox è l'implementazione di Eclipse (licenza EPL) e Felix è l'implementazione del progetto Apache (licenza pubblica Apache con licenza).

Eclipse fornisce un esempio concreto del fatto che OSGi può coprire i punti che hai citato (o potresti semplicemente compilare la tua applicazione sopra Eclipse RCP se vuoi uno stack completo Eclipse / SWT / JFace).

Dall'1.6 esiste java.util.ServiceLoader che può essere utilizzato se si desidera codificare il proprio sistema semplice.

Ma se vuoi qualcosa di più delle funzionalità di base, usa uno dei framework esistenti.

C'è anche JPF (Java Plugin Framework) .

Usa PF4J . Ha il supporto per Web, Spring e Wicket. Facile da usare e costruire le applicazioni

Ho lavorato su OSGi per una settimana - una settimana intensa, nient'altro che OSGi. Alla fine è stato come un brutto sogno, ma ho imparato molto.

Sono stato in grado di far funzionare OSGi (non facile, tutti gli esempi sono obsoleti, tutto in rete ha almeno tre anni se non cinque), ma ho avuto seri problemi a integrarlo in un progetto esistente a causa di problemi con il si manifesta il barattolo.

In breve, ci sono solo pochi strumenti oscuri utilizzati per la creazione di manifesti e non sono ben documentati (BND Tools è quasi oscuro, ma è progettato per un certo processo in Eclipse). Inoltre, la maggior parte delle informazioni disponibili su OSGi non è destinata agli sviluppatori di applicazioni che dispongono di un'applicazione desktop esistente.

Questo rende gran parte del contesto per l'informazione confusa o inappropriata. I post sul blog di Neil Bartlett sono stati di grande aiuto, ma anche quelli non sono riusciti a ottenere un sistema funzionante (ho preso un po 'di codice dal tutorial di Felix e l'ho messo insieme per far girare il framework incorporato). Ho trovato la bozza del suo libro che ha pubblicato gratuitamente anni fa, il che è eccellente, ma gli esempi in Eclipse non funzionano a causa dei cambiamenti nel supporto OSGi di Eclipse.

Ogni passo è un grosso ostacolo. Proverò a pubblicare qualche dettaglio in più qui.

Penso che raccomandare OSGi per risolvere il problema sopra menzionato sia un consiglio estremamente scarso. OSGi è "la scelta giusta", ma per uno scenario come quello sopra, penso che sia JPF o un quadro minimalista nostrano sia sufficiente.

Anni fa ho iniziato un progetto del genere e spero che presto sarà pronto. Mi sono ispirato a progetti come NetBeans ed Eclipse ma nel frattempo è cambiato in qualcosa di leggermente diverso. OSGi sembra una buona scelta ora, ma non ho avuto la possibilità di confrontarlo con il mio progetto.È simile a JPF sopra menzionato, ma allo stesso tempo diverso in molti modi.

L'idea di base che mi ha motivato è quella di essere il più semplice possibile per creare un'applicazione Java, senza alcuna separazione tra applicazioni web, applicazioni desktop o applet / applicazioni JWS (ovviamente questo non copre ancora l'interfaccia utente) come funzionalità principale.

Ho costruito il progetto con alcuni obiettivi in ​​mente:

• non importa se si crea un'applicazione Web o un'applicazione desktop, è necessario avviare l'applicazione allo stesso modo, un metodo principale semplice, nessuna dichiarazione web.xml di fantasia (non che io sia contrario ad avere un descrittore web standard, ma non va bene con un sistema plug-in, in cui aggiungi "servlet" - li chiamo RequestHandler (s) - dinamici a tuo piacimento).
• è facile collegare "estensioni" attorno a un "punto di estensione", qualcosa di Eclipse ma con un approccio diverso.
• auto-distribuibile, poiché tutti i plug-in sono registrati (file XML), l'applicazione deve essere auto-distribuibile indipendentemente dal sistema di compilazione - ovviamente c'è un'attività Ant e un Maven MOJO che sono i collegamenti con il nostro mondo, ma nel fine chiama l'applicazione e le indica di auto-distribuirsi in una posizione specifica.
• preso in prestito da Maven, può scaricare il codice dai repository (inclusi i repository Maven 1 e 2) in modo che la tua applicazione possa essere distribuita come un singolo barattolo a condizione che tu abbia accesso ai repository (utile qualche volta, e sostanzialmente questo fornisce supporto per l'auto- aggiornamenti - non ti piace l'idea di essere avvisato dalla tua applicazione web che esiste una versione più recente, è stata scaricata e ha solo bisogno del tuo permesso per installarla? So che lo adoro).
• monitoraggio delle applicazioni di base sullo stato del sistema, notifiche e-mail in caso di guasti