Come modulare una (grande) app Java?

Question

Ho a disposizione un'applicazione piuttosto ampia (diverse MLOC) che mi piacerebbe suddividere in più parti separate manutenibili. Attualmente il prodotto è composto da circa 40 progetti Eclipse, molti dei quali hanno interdipendenze. Questo da solo rende un sistema di generazione continua non fattibile, perché dovrebbe ricostruire molto con ogni controllo.

C'è un modo "best practice" di come

• identificare le parti che possono immediatamente essere separati
• documento interdipendenze visivamente
• districare il codice esistente
• maniglia "patch" dobbiamo applicare alle librerie (attualmente gestite inserendole nel classpath prima della libreria effettiva)

Se ci sono strumenti (gratuiti/aperti) per supportarlo, apprezzerei i puntatori.

Anche se non ho alcuna esperienza con Maven sembra che costringa un design molto modulare. Mi chiedo ora se si tratta di qualcosa che può essere adattato in modo iterativo o se un progetto che doveva usarlo avrebbe dovuto essere strutturato con la modularità in mente sin dall'inizio.

Modifica 2009-07-10

Siamo nel processo di scissione alcuni moduli di base utilizzando Apache Ant/Ivy. Strumento davvero utile e ben progettato, che non impone tanto a te come fa Maven.

ho scritto alcuni dettagli più generali e personale opinione sul perché lo stiamo facendo sul mio blog - troppo tempo per postare qui e forse non interessante a tutti, in modo da seguire a propria discrezione: www.danielschneller.com

Answer 1

Utilizzare OSGi potrebbe essere una buona misura per voi. Permetterebbe di creare moduli fuori dall'applicazione. Puoi anche organizzare le dipendenze in un modo migliore. Se si definiscono correttamente le interfacce tra i diversi moduli, è possibile utilizzare l'integrazione continua poiché è necessario ricostruire il modulo interessato al momento del check-in.

I meccanismi forniti da OSGi ti aiuteranno a districare il codice esistente. A causa del modo in cui funziona il caricamento delle classi, ti aiuta anche a gestire le patch in un modo più semplice.

Some concepts of OSGi that seem to be a good match for you, as shown from wikipedia:

Il quadro è concettualmente suddiviso nelle seguenti aree:

• Bundles - Bundle sono normali componenti vaso con intestazioni supplementari manifesto.
• Servizi - Il livello di servizi collega i pacchetti in modo dinamico offrendo un modello di rilegatura di pubblicazione per semplici oggetti Java vecchi (POJO).
• Registro servizi - L'API per i servizi di gestione (ServiceRegistration, ServiceTracker e ServiceReference).
• Life-Cycle - L'API per la gestione del ciclo di vita (installazione, avvio, arresto, aggiornamento e disinstallazione dei pacchetti).
• Moduli: il livello che definisce l'incapsulamento e la dichiarazione delle dipendenze (come un pacchetto può importare ed esportare il codice).
• Sicurezza: il livello che gestisce gli aspetti di sicurezza limitando le funzionalità del pacchetto a capacità predefinite.

Answer 2

I wouldn raccomandiamo Maven per una base di codice sorgente legacy. Potrebbe darti mal di testa solo cercando di adattare tutto per lavorare con esso.

Suppongo che quello che ti serve sia fare un layout architettonico del tuo progetto. Uno strumento può essere d'aiuto, ma la parte più importante è organizzare una vista logica dei moduli.

Answer 3

Primo: buona fortuna & buon caffè. Avrai bisogno di entrambi.

Una volta ho avuto un problema simile. Codice legacy con dipendenze circolari terribili, anche tra classi di pacchetti diversi come org.example.pkg1.A dipende da org.example.pk2.B e viceversa.

Ho iniziato con maven2 e nuovi progetti di eclissi. Per prima cosa ho cercato di identificare le funzionalità più comuni (livello di registrazione, interfacce comuni, servizi comuni) e ho creato progetti maven. Ogni volta che ero contento di una parte, ho distribuito la libreria nel repository centrale del nexus in modo che fosse quasi immediatamente disponibile per altri progetti.

Quindi ho elaborato lentamente gli strati. maven2 ha gestito le dipendenze e il plugin m2eclipse ha fornito una vista di dipendenza utile. BTW - di solito non è troppo difficile convertire un progetto di eclipse in un progetto di maven. m2eclipse può farlo per te e devi solo creare alcune nuove cartelle (come src/main/java) e aggiustare il percorso di costruzione per le cartelle di origine. Prende solo un minuto o due. Ma aspettatevi più difficoltà, se il vostro progetto è un plug-in di eclissi o un'applicazione rcp e volete che Maven non solo gestisca le risorse ma anche per creare e distribuire l'applicazione.

Per parere, eclipse, maven e nexus (o qualsiasi altro gestore di repository maven) sono una buona base per iniziare. Sei fortunato, se hai una buona documentazione dell'architettura di sistema e questa architettura è veramente implementata;)

Answer 4

Ho avuto un'esperienza simile in un piccolo codice di base (40 kloc).Non ci sono regole ° ":

• compilato con e senza un 'modulo' per vedere che è l'utilizzo
• ho iniziato da 'moduli foglia', i moduli senza altre dipendenze
• Ho gestito ciclica dipendenze (si tratta di un compito molto soggetto a errori)
• con Maven c'è una grande quantità di documentazione (rapporti) che possono essere implementate nel processo cI
• con Maven si può sempre vedere quello che utilizza ciò che sia in sito entrambi in NetBeans (con una
  molto bello grafo orientato)
• con Maven è possibile importare codice della libreria nella vostra base di codice, applicare le patch di origine e compilare con i vostri prodotti (a volte questo è molto facile a volte è molto difficile)

controllare anche Dipendenza Analyzer: http://www.javalobby.org/servlet/JiveServlet/download/17-96956-92153685-7907/screenshot.jpg

Netbeans:

http://dm.zimmer428.net/wp-content/uploads/2009/02/67pre-dependency-graph.jpg

Answer 5

Maven è doloroso per la migrazione a per un sistema esistente. Tuttavia, può gestire oltre 100 progetti di moduli senza troppe difficoltà.

Answer 6

La prima cosa che devi decidere è quale infrastruttura ti indirizzerai. Dovrebbe essere un sacco di moduli mantenuti autonomamente (che si traducono in singoli progetti Eclipse) o lo considererete un singolo pezzo di codice che è versionato e distribuito nel suo complesso. Il primo è adatto per la migrazione in un ambiente di build come Maven - il secondo per avere tutto il codice sorgente in una sola volta.

In ogni caso è necessario un sistema di integrazione continua in esecuzione. Il primo compito è quello di creare automaticamente la base di codice, in modo che il sistema CI possa sorvegliare il repository di origine e ricostruirlo quando si cambiano le cose. Ho deciso di adottare un approccio non Maven e ci concentriamo sull'avere un ambiente Eclipse semplice, quindi ho creato un ambiente di costruzione utilizzando i file ant4eclipse e Team ProjectSet (che utilizziamo comunque).

Il prossimo passo sarebbe sbarazzarsi delle dipendenze circolari - questo renderà la vostra costruzione più semplice, sbarazzarsi di avvertimenti Eclipse, e alla fine vi permetterà di arrivare alla fase "checkout, compilare una volta, eseguire". Questo potrebbe richiedere un po 'di tempo :-(Quando migri metodi e classi, non spostarli, ma estrarli o delegarli e lasciare il loro vecchio nome in giro e contrassegnarli deprecati. Questo separerà il tuo districare con il tuo refactoring e consentire il codice " al di fuori" il progetto di lavorare ancora con il codice all'interno del vostro progetto.

si potranno beneficiare di un repository di origine che consente di spostare i file, e mantenere la storia. CVS è molto debole in questo senso.

Answer 7

non è gratuito ma lo Structure101 ti darà il massimo in termini di supporto degli strumenti per colpire tutti i tuoi punti elenco. Ma per la cronaca sono prevenuto, quindi potresti voler controllare anche SonarJ e Lattix ;-)