via secca di definire le dipendenze sia per pontile: corsa e distribuzione

Question

sto avvolgendo la costruzione di un progetto web che supporta due modalità di funzionamento:

• localmente utilizzando mvn jetty-run;
• distribuito su un server dell'applicazione.

Per il server delle applicazioni molte librerie sono contrassegnate come provided, poiché altrimenti si verificano conflitti del classpath. Allo stesso tempo, ho ridichiarato queste dipendenze come dipendenze compilate per lo jetty-maven-plugin, poiché altrimenti gli obiettivi non vengono eseguiti correttamente.

La build funziona in questo modo, ma ho un gran numero di librerie duplicate. C'è un modo più pulito per farlo?

Answer 1

Basta seguire questo JETTY-429 è stato unito in modo da poter aggiungere con cautela uno configuration parameter<useProvidedScope>true</useProvidedScope>. Ciò includerà le dipendenze fornite sul classpath del plugin jetty .

Vale la pena leggere JETTY-429 per i dettagli sui potenziali problemi che l'utilizzo di questa opzione può comportare.

Answer 2

Bene c'è sempre la soluzione wicket. (Non deve fare nulla con wicket, ma può essere trovato nel wicket maven archetype.)

Utilizzare una classe principale che avvia il molo a livello di codice con il progetto come contesto webapp. Questo dovrebbe raccogliere tutte le dipendenze di Maven anche in ambito previsto su tutti i principali IDE. Ecco un tale classe:

public class Start{ 

    private static final Logger LOG = Logger.getLogger(Start.class); 

    public static void main(final String[] args) throws Exception{ 
     LOG.addAppender(new ConsoleAppender(new SimpleLayout(), "system.out")); 
     final Server server = new Server(); 
     final SocketConnector connector = new SocketConnector(); 

     // Set some timeout options to make debugging easier. 
     connector.setMaxIdleTime(1000 * 60 * 60); 
     connector.setSoLingerTime(-1); 
     connector.setPort(9090); 
     server.setConnectors(new Connector[] { connector }); 

     final WebAppContext bb = new WebAppContext(); 
     bb.setServer(server); 
     bb.setContextPath("/"); 
     bb.setWar("src/main/webapp"); 
     server.addHandler(bb); 

     try{ 
      LOG.info(// 
      ">>> STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP" // 
      ); 
      server.start(); 
      System.in.read(); 
      LOG.info(">>> STOPPING EMBEDDED JETTY SERVER"); 
      server.stop(); 
      server.join(); 

     } catch(final Exception e){ 
      LOG.error("Something bad happened", e); 
      System.exit(100); 
     } 
    } 

    // CHECKSTYLE:ON 
} 

La parte bella: è possibile avviare questo come una configurazione di esecuzione eclissi standard, compreso facile il debugging. Il rovescio della medaglia: è necessario molo come un ulteriore provided dipendenza:

<!-- JETTY DEPENDENCIES FOR TESTING --> 
<dependency> 
    <groupId>org.mortbay.jetty</groupId> 
    <artifactId>jetty</artifactId> 
    <version>${jetty.version}</version> 
    <scope>provided</scope> 
</dependency> 
<dependency> 
    <groupId>org.mortbay.jetty</groupId> 
    <artifactId>jetty-util</artifactId> 
    <version>${jetty.version}</version> 
    <scope>provided</scope> 
</dependency> 

Answer 3

Non sto dicendo che questa è la soluzione migliore, ma come a fare questo:

1. le dipendenze predefinite elencare le dipendenze di cui come fornito". La configurazione di progetto predefinita dovrebbe produrre file WAR che verranno eseguiti su server non Jetty.
2. Definire un profilo "jetty" e redeclare le dipendenze fornite nell'ambito di compilazione. Quindi esegui mvn -Pjetty jetty: esegui

Potrebbe non essere la soluzione più pulita al mondo, in quanto costringe alcune ripetizioni, ma dovrebbe portare a termine il lavoro per te.

Answer 4

Vorrei anche qualche tipo di flag per poter includere le dipendenze con scope provided durante l'esecuzione di Jetty. In realtà, Jetty ha già un useTestClasspath che fa qualcosa di simile per le dipendenze con scope test (perché non include le dipendenze provided in quel caso) per evitare di dover duplicare le dipendenze in un profilo. Questo è tracciato da JETTY-429 che ha una patch per tale bandiera.