Come posso gestire le dipendenze della build OSGi?

Question

Abbiamo incorporato un runtime OSGi (Equinox) nella nostra applicazione client-server personalizzata per facilitare lo sviluppo dei plugin e finora le cose stanno andando alla grande.Abbiamo utilizzato Eclipse per creare plug-in grazie all'editor manifest integrato, alla gestione delle dipendenze e alla procedura guidata di esportazione.L'utilizzo di Eclipse per gestire le build non è molto favorevole all'integrazione continua tramite Hudson.

Abbiamo bundle OSGi che dipendono da altri bundle OSGi.Odierei davvero codificare l'ordine di build in una build ANT personalizzata.L'abbiamo fatto, questo è il passato ed è piuttosto orribile.Esiste uno strumento di creazione in grado di gestire FACILMENTE le dipendenze OSGi, se non risolverle automaticamente?Ci sono esempi DECENTI di come farlo?

UNA PRECISAZIONE:

Gli script di build generati sono utilizzabili solo tramite Eclipse.Richiedono l'esecuzione manuale di parti di Eclipse.Abbiamo anche alcuni target standard che la build di Eclipse non avrà e non voglio modificare il file generato poiché potrei rigenerarlo (so che posso fare include, ma voglio evitare tutto il file gen di Eclipse insieme)

Ecco il layout del mio progetto:

/
-PluginA
-PluginB
-PluginC
.
.
.

Utilizzando Eclipse PDE, ogni plugin ha un Manifest, ma nessun build.xml poiché il PDE lo fa per me.Difficile automatizzare un processo basato sulla GUI con Hudson.Mi piacerebbe impostare il mio build.xml per crearli ciascuno, MA ci sono dipendenze e problemi con l'ordine di creazione.Questi problemi sono causati dai file Manifest (che descrivono le importazioni OSGi).Ad esempio, PluginC dipende da PluginB che a sua volta dipende da PluginA.Devono essere costruiti nell'ordine corretto.Mi rendo conto che posso controllare manualmente l'ordine di costruzione, sto cercando uno strumento che mi aiuti ad automatizzare la gestione delle dipendenze dell'ordine di costruzione.

Answer 1

Chiudo alcune vecchie domande...

La nostra configurazione non era favorevole a Maven a causa della mancanza di connettività di rete e tempistica.So che ci sono configurazioni offline per esperti, ma era troppo dato il tempo.Speriamo di riuscire a utilizzare una configurazione adeguata quando avremo il tempo di riorganizzare il processo di creazione.

La soluzione prevedeva Ant, BND e alcune attività formiche personalizzate.Le varie dipendenze del bundle vengono gestite manualmente.Stavamo già utilizzando Ant;BND e attività personalizzate hanno legato tutto insieme.Le attività personalizzate si limitavano a garantire che i nostri progetti bnd/eclipse fossero sincronizzati.

Answer 2

Maven2 fino in fondo;ha un plugin Eclipse chiamato m2eclipse per aiutare a gestirlo, risolve esattamente il problema delle dipendenze e altro ancora.Ha un libro online gratuito come documentazione.

Guarda specificatamente progetti multimodulo per raggruppare insieme molti componenti e fare in modo che Maven elabori l'ordine di compilazione e le dipendenze.

C'è anche un capitolo sull'integrazione di Eclipse.

E questo è solo Eclipse e Maven, poi riceverai alcuni fantastici gadget per OSGi:

• IL Plug-in Apache Felix BND Maven genererà automaticamente i tuoi manifest o almeno ti aiuterà
• IL Progetto PAX OPS4J e i loro plugin Maven possono essere di grande aiuto per avviare progetti, fornire launcher, ecc

E fondamentalmente, il modello del modulo Maven si adatta perfettamente al modello bundle di OSGi.Costruiamo e gestiamo più prodotti con centinaia di bundle utilizzando Maven da più di 3 anni ed è fantastico.

Answer 3

Assecondare Maven2.Esamina i plug-in Tycho per la creazione: utilizzano il compilatore JDT di Eclipse in modo che implementi tutte le regole OSGi in fase di compilazione, allo stesso modo di Eclipse in fase di runtime.

In alternativa sembrano popolari anche i plugin Apache Felix BND.Preferisco Tycho perché sembra unificare più da vicino gli ambienti di sviluppo Maven ed Eclipse.

Answer 4

Noi usiamo Buckminster.È un framework di build e assembly, che si occupa della risoluzione delle dipendenze, del recupero da vari repository, della costruzione e del confezionamento del prodotto.

È un progetto Eclipse Tools.Si integra bene con PDE.

Ciò significa che tutti i metadati che utilizziamo per costruire l’RCP sono utili a Buckminster per risolverli e costruirli.Ad esempio, feature.xml e l'intestazione Require-Bundle in Manifest.MF, .product.

Al momento non abbiamo script di compilazione in ciascun pacchetto;ora abbiamo una singola build per prodotto.Buckminster si prende cura di percorrere il grafico delle dipendenze.

Ci è voluto un po' di impegno per far funzionare il nostro attuale sistema di controllo della velocità/formica, anche se loro (il team di Buckminster) hanno iniziato a utilizzare Hudson per ospitare il progetto stesso.Credo che la loro configurazione di build sia disponibile anche per il download.

Ne siamo davvero impressionati, nonostante sia relativamente infantile.

Abbiamo anche esaminato Pax-Costruito ma non volevamo usare Maven.

Stiamo anche esaminando Framework di test DM di primavera per aumentare lo sforzo di test unitario.

Answer 5

PDE Costruzione senza testa.È ben documentato da Eclipse.Se stai creando plugin Eclipse e vuoi farlo tramite riga di comando, la build headless di Eclipse PDE è LA strada da percorrere.

Answer 6

Potete per favore spiegare dove si verifica il problema?Hai menzionato le dipendenze del bundle OSGi.Questo avviene durante il runtime?O durante la compilazione?Nel primo caso dovresti considerare i servizi dichiarativi (vedi OSGi Spec).

Answer 7

Usiamo Hudson combinato con PluginBuilder per creare i nostri bundle/plugin OSGi basati su Eclipse.Questo si basa sul processo PDE standard di Eclipse per la creazione di plug-in.Ciò significa utilizzare Eclipse come compilatore.

Answer 8

Maven non richiede la connettività Internet!Usa l'opzione -o, per l'amor di Dio.

Answer 9

Utilizzo Maven 3.0.2

mvn genera: archetipo

select 252 - osgi-archetype
mvn idea:idea

Vedere http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html

per aggiungere le tue dipendenze al bundle usa questo breve esempio nel pom.xml

<Export-Package>org.foo.myproject.api</Export-Package>

O

<Import-Package>org.foo.myproject.api</Import-Package>