2012-07-10 12 views
6

Abbiamo una soluzione in cui i nostri progetti di interfaccia utente includono una serie di servizi aziendali utilizzando le dipendenze del client EJB. Il problema con questo su Maven è che anche se il client .jar di solito contiene circa 1-2 classi, portano con sé lo stack di dipendenze completo dell'intera applicazione di servizio. Questo può diventare un po 'brutto, quando i file .ear cominciano a crescere fino a 50-100Mb un pop e ci sono di volta in volta errori fastidiosi dovuti a dipendenze irrilevanti che si introducono furtivamente nell'applicazione dell'interfaccia utente.Esclusione dipendenza generazione ejb-client Maven

Ovviamente, possiamo sempre escludere le dipendenze dal client, ma poi dobbiamo scrivere lo stesso gruppo di linee per ogni progetto client usando quei servizi e questa è una grande ripetizione inutile. Inoltre, le persone arrivano con i messaggi di errore più strani e impiegano un sacco di tempo a rintracciarli prima di ricordare di menzionare che hanno incluso alcuni jar client e non hanno verificato quali dipendenze aggiuntive ha portato nell'equazione.

Esempio:

 <dependency> 
      <groupId>fi.path.to.service</groupId> 
      <artifactId>customermanagement-common</artifactId> 
      <version>2.6</version> 
     </dependency> 
     <dependency> 
      <groupId>fi.path.to.service</groupId> 
      <artifactId>customermanagement-service</artifactId> 
      <classifier>client</classifier> 
      <exclusions> 
       <exclusion> 
        <groupId>fi.path.to.dependency</groupId> 
        <artifactId>internal-dependency-#1</artifactId> 
       </exclusion> 
       <exclusion> 
        <groupId>org.codehaus.castor</groupId> 
        <artifactId>castor</artifactId> 
       </exclusion> 
       <exclusion> 
        <groupId>fi.path.to.dependency</groupId> 
        <artifactId>internal-dependency-#2</artifactId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#3</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#4</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#5</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>castor-xml</artifactId> 
        <groupId>org.codehaus.castor</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>castor-codegen</artifactId> 
        <groupId>org.codehaus.castor</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>castor-xml-schema</artifactId> 
        <groupId>org.codehaus.castor</groupId> 
       </exclusion> 
       <exclusion> 
        <artifactId>internal-dependency-#6</artifactId> 
        <groupId>fi.path.to.dependency</groupId> 
       </exclusion> 
      </exclusions> 
      <version>2.6</version> 
     </dependency> 

Questo è solo un client di servizi viene incluso, immaginate di avere molti di questi in diverse applicazioni e si ottiene l'immagine, la scrittura su tutti i esclude ogni volta che è abbastanza fastidioso e il progetto Le POM iniziano ad essere abbastanza lunghe.

Contrassegnerei la dipendenza come previsto, ma ci sono un paio di dipendenze che si bloccano in runtime, se non esistono. Diciamo quelli che includono un'altra chiamata di servizio a un'altra app con una classe Exception esterna, che non è per un motivo o l'altro racchiuso all'interno del progetto di servizio e causerà una ClassNotFoundException in fase di runtime, se non presente.

Pertanto, so che è possibile escludere/includere classi da un client ejb durante la sua generazione attraverso l'uso delle specifiche pom.xml sul plugin maven-ejb, ma esiste un modo per escludere anche le dipendenze?

risposta

1

Sembra che Maven non supporti molto semplicemente la costruzione di più jar da un modulo.

Quindi l'unico modo ragionevole per risolvere questo è quello di creare un altro modulo (interrompere il servizio xxx in xxx-service e xxx-service-client) e configurare il modulo xxx-service-client per avere solo il EJB client/delegato classe & dipendenze minime. In questo modo il progetto può essere realizzato con un'unica esecuzione.

0

Ho lo stesso problema qui. Io penso Una soluzione potrebbe essere l'utilizzo di profili, dal momento che in ogni profilo è possibile specificare le dipendenze (vedi http://blog.sonatype.com/people/2010/01/how-to-create-two-jars-from-one-project-and-why-you-shouldnt/)

Nel mio caso, questo non funziona, perché ho bisogno di generare sia JAR (EJB e ejb- client) in un'unica esecuzione di Maven. :)

+0

Affrontare un problema simile, iniziare a cambiare il modo in cui i progetti vengono creati tramite la soluzione CI è probabile che sarà un grosso problema e diventa un problema con la manutenzione, quando funzionano in modo diverso rispetto a tutte le altre app dell'azienda. – t0mppa