Organizzazione di moduli maven e profili a molla

Question

Organizzazione di moduli maven e profili a molla

#1 da (1 voti)
#2 da (1 voti)

4

Sto affrontando un problema di progettazione con il profilo di Spring e il progetto multimodule Maven da cui sto costruendo un prodotto, come un web come applicazione che può essere personalizzata per i diversi clienti. Per questo ho bisogno di un po 'di organizzazione del mio codice, questo è il motivo per cui sto navigando su come organizzare i miei profili attorno al mio codice.

Al momento sto usando solo 2 profili: dev / prod per l'intera applicazione. Questi profili sono entrambi profili esperti e profili a molla. Il profilo Spring è nel web.xml del mio archivio web che proviene dal filtraggio di maven.

Avere solo questo è un po 'fastidioso quando voglio passare facilmente alcune classi da altri moduli che si basano su qualche hardware esterno. Naturalmente posso solo aggiungere un nuovo profilo dal nulla solo per risolvere questo problema.

Comunque sto cercando un modo più generico per gestirlo, non voglio finire nel brodo di un profilo che è stato appena creato perché "Ne ho bisogno in quel momento". Dovrei creare un profilo dev-xxx / prod-xxx per ogni modulo, o ci sono migliori best-practice su questo?

Ecco alcune informazioni su come il mio progetto è attualmente organizzato, questo ti darà un'idea di ciò che ho attualmente. Ma non è necessario tenerne conto nella risposta

Il mio stack completo per il server: PostgreSQL, Hibernate, JPA, Spring + Spring-Security, CXF (fornisce implementazione JAX-RS e molte funzionalità come motore di ricerca FIQL), WebSockets, Jackson (json serializer)

Ecco come sono attualmente organizzati i miei moduli, non sto cercando necessariamente una risposta che corrisponda precisamente a ciò che ho, ma ti dà un'idea:

Core: contiene al momento tutte le Entità, i servizi aziendali e la gestione dei diritti. Non uso oggetti DTO quindi tutte le annotazioni da JPA / Jackson sono sulle entità (36 tabelle nel database).
Rest-Common: contiene alcune configurazioni predefinite (jackson mapper, fornitore jackson jax-rs).
RestCore: espone tutti i servizi al mondo web, fornisce un servizio di ricerca che si affida al modulo di ricerca JAX-RS di CXF. Gli URL sono protetti con sicurezza di primavera in base ai diritti semplici, ulteriori verifiche vengono eseguite in Business Service.
RestReader: esporre un insieme di URL diversi per la sincronizzazione con un lettore mobile. Quelli non sono fatti per essere usati da un browser.
2 altri moduli indipendenti che implementano solo la loro parte tecnica.

Nota: so che posso avere un profilo intermedio di ambiente di integrazione e così via, sono pianificati, ma sto facendo una corsa di 2-3 settimane per ogni funzionalità che non sono realmente specificate o progettate prima mano , quindi ho pochissimo tempo per pulire il mio intero processo di compilazione, per un'analisi completa, per la progettazione e così via. Quindi potrei essere interessato ad alcune risposte per il futuro che non sarò in grado di implementare al momento.

design builds spring maven

posta Walfrat 03.06.2016 - 10:24

fonte

2 risposte

Leggi altre domande sui tag design builds spring maven

Qual è una struttura dati efficiente per fare molte domande tra genitori / figli? Caricamento / recupero rapido per soluzioni dati BLOB

score 1 · Answer 1

Se possibile, crea un profilo collegato tra entrambi, consentendoti di modificare / confrontare / controllare immediatamente i file sia su dev che su prod. Questo è il mio suggerimento, ma se qualcun altro ha un'esperienza migliore di me, lo prenderei da loro.

score 1 · Answer 2

Non consiglierei di inserire più target di build nel singolo progetto Maven ed eseguire la personalizzazione dell'app durante la compilazione tramite i profili Spring. Questa soluzione è difficile da supportare, perché ha una visibilità ridotta della funzionalità che appartiene al contesto specifico di applicazione / esecuzione.

L'architettura dei plugin sarebbe una scelta migliore qui, perché separa chiaramente il codice comune dalle specifiche del cliente. Come puoi farlo?

Struttura del progetto

  project
    core
      pom.xml
    feature1
      pom.xml
    feature2
      pom.xml
    app1
      pom.xml
    app2
      pom.xml

Qui hai funzionalità comuni nel modulo principale e due app per clienti diversi, che includono il core e alcune funzionalità come dipendenze. "mvn integration-test" del progetto root compila il core, le funzionalità e il codice sorgente delle app ed esegue test, ma non raggruppa le app. Puoi assemblare l'app specifica costruendo il suo modulo.

Architettura dell'applicazione

Il modulo principale è un'app che può essere eseguito autonomamente: contiene tutte le infrastrutture necessarie e le funzionalità minime. Fornisce interfacce opzionali per plug-in e API di configurazione, che consentono la personalizzazione per cliente.

Ogni modulo di funzionalità di cui sopra esempio è un plugin, estendendo alcune delle interfacce principali. È possibile utilizzare OSGi, ma la soluzione più semplice sarà utilizzare l'individuazione in fase di esecuzione delle configurazioni del contesto dell'applicazione Spring (è possibile utilizzare frammenti Web da Servlet 3.0 o lasciare che la configurazione predefinita includa tutti i file da classpath situati in, ad esempio '/ META-INF / )-plugins my-primavera. Lì puoi mettere tutta la configurazione aggiuntiva e definire i bean plugin. Diciamo che per alcuni clienti è necessaria una funzionalità A, accessibile tramite API REST come azione su qualche entità. È possibile definire un componente che raccoglierà un elenco di azioni da bean che implementano l'interfaccia IActionProvider. Nel plug-in funzionalità A implementa questa interfaccia e restituisci la definizione dell'azione per questa funzione.

Anche il modulo app è un plug-in: può estendere le interfacce che controllano il branding dell'applicazione, la configurazione del database, la configurazione di integrazione aziendale ecc.