tags:

views:

30

answers:

3

I'm wrapping up the build for a web project which supports two ways of running:

  • locally using mvn jetty-run;
  • deployed on an application sever.

For the application server many libraries are marked as provided, since otherwise classpath conflicts occur. At the same time, I have redeclared these dependencies as compile dependencies for the jetty-maven-plugin, since otherwise the goals does not run properly.

The build works like this, but I have a large number of duplicated libraries. Is there a cleaner way of doing this?

+2  A: 

Well there's always the wicket solution. (It doesn't have to do anything with wicket, but it can be found in the wicket maven archetype.)

Use a main class that starts jetty programmatically with the project as webapp context. This should pick up all maven dependencies even in provided scope on all major IDEs. Here is such a class:

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
}

The nice part: you can launch this as a standard eclipse run configuration, including easy debugging. The downside: you need jetty as an additional provided dependency:

<!-- 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>
seanizer
Interesting, I'll take a look.
Robert Munteanu
Indeed, interesting "work around". +1
Pascal Thivent
+2  A: 

I'm not saying this is the best solution, but how about doing this:

  1. Your default dependencies list the provided dependencies as "provided". The default project configuration should produce WAR files which are going to run on non-Jetty servers.
  2. Define a profile "jetty" and redeclare the provided dependencies in the compile scope. Then just run mvn -Pjetty jetty:run

It might not be the cleanest solution in the world, as it forces some repetition, but it should get the job done for you.

tobrien
+1 because this works, not for the DRYness :) But somehow, I wonder why `provided` dependencies are not added when using the [`useTestClasspath`](http://jetty.codehaus.org/jetty/maven-plugin/run-mojo.html#useTestClasspath) flag. This wouldn't sound wrong IMHO.
Pascal Thivent
What Pascal said :-) . It contains more or less the same duplication as my current solution so I'm not very inclined to change it.
Robert Munteanu
+2  A: 

I'd also like some kind of flag to be able to include provided scoped dependencies when running Jetty. Actually, Jetty already has a useTestClasspath doing something similar for test scoped dependencies (why not including provided dependencies in that case) in order to avoid having to duplicate dependencies in a profile. This is tracked by JETTY-429 which has a patch for such a flag.

Pascal Thivent
Interesting, thanks.
Robert Munteanu
class path references are a nice idea (+1)
seanizer