2

I hope I'm explaining this as accurately as possible, and I want to know if I set up the maven dependencies correctly, or if there's a better way to do it.

Most of my development team's projects rely on a home-grown jar that is deployed at server class loader. The reason for this jar to reside at this level is to the ease of updating the jar at one place without repackaging each project that's using it, assuming changes made to it are backward-compatible.

I develop my web apps against Jetty in my local development. So, in order for the web apps to work locally, I set up the dependencies this way:-

<dependencies>
    <!-- Configuring external jar dependency -->
    <dependency>
        <groupId>com.test.app</groupId>
        <artifactId>app-jar</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${env.EXTERNAL_JAR}</systemPath>
    </dependency>

    ...
</dependencies>

<build>
    <plugins>
        <!-- Configuring Jetty -->
        <plugin>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>maven-jetty-plugin</artifactId>
            <version>6.1.26</version>
            <configuration>
                <contextPath>/${project.parent.artifactId}</contextPath>
                <jettyEnvXml>${env.JETTY_ENV_XML}</jettyEnvXml>
                <scanIntervalSeconds>1</scanIntervalSeconds>
                <connectors>
                    <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                        <port>7777</port>
                    </connector>
                </connectors>
                <webAppConfig>
                    <extraClasspath>${env.EXTERNAL_JAR}</extraClasspath>
                </webAppConfig>
            </configuration>
        </plugin>

        ...
    </plugins>
</build>

In this approach, I set up an environment variable that points to the external jar path, and reference it in my pom.xml as ${env.EXTERNAL_JAR}.

After doing some reading, it seems like using "system" scope is considered a bad practice. So, I installed this external jar in Nexus and change the scope to "provided":-

<dependency>
    <groupId>com.test.app</groupId>
    <artifactId>app-jar</artifactId>
    <version>1.0</version>
    <scope>provided</scope>
</dependency>

This allows me to compile my project properly, but I'm not sure if it is even possible for me to get rid of the "EXTERNAL_JAR" environment variable completely because it's still needed by Jetty for the runtime to work properly. My take is using "provided" scope is a little tedious and more work, because I now need to remember to update the jar in Nexus when it is modified AND I still need to update the jar located at the path pointed by the environment variable.

Is there a way for me to expose the external jar to Jetty through maven dependencies, yet not being packaged into the project when the war file is built?

What are you advice on this? Should I just stick with "system" scope so that I just need to update the jar at one place, or should I use "provided" scope? Or if there's even a better way to do this?

Thanks much.

limc
  • 39,366
  • 20
  • 100
  • 145
  • Using provided scope and the `${env.EXTERNAL_JAR}` seems perfectly ok to me. If you wanted to address the jar in your local repository, you could use `${settings.localRepository}/com/test/app/app-jar/1.0/app-jar-1.0.jar` instead. – Paul Grime Feb 17 '12 at 18:56
  • @Paul, I like your approach whole lot more. Your way allows me to use the provided scope without the need to set up any environment variable pointing to the external jar. I didn't know the existence of `${settings.localRepository}` to begin with. If you could post your copy and paste your response below, I'll upvote it and perhaps, accept your solution if there are no other better responses. Thanks. – limc Feb 17 '12 at 19:44

3 Answers3

3

You should be able to add dependencies to the jetty plugin. And then I have the provided scope for the project itself.

http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin

as in

<project>
... 
      <plugin> 
        <groupId>org.mortbay.jetty</groupId> 
        <artifactId>maven-jetty-plugin</artifactId> 
        <configuration> 
          <systemProperties> 
            <systemProperty> 
              <name>logback.configurationFile</name> 
              <value>./src/etc/logback.xml</value> 
            </systemProperty> 
          </systemProperties> 
        </configuration> 
        <dependencies>
          <dependency> 
            <groupId>ch.qos.logback</groupId> 
            <artifactId>logback-classic</artifactId> 
            <version>0.9.15</version> 
          </dependency> 
        </dependencies> 
      </plugin>
...
<project>
Eric Winter
  • 960
  • 1
  • 8
  • 17
1

The best thing to do is setup an external repository with your dependency, and add it to your pom.

<repositories>
    <repository>
        <id>my-repo</id>
        <name>my-repo</name>
        <url>http://your.repo.url</url>
    </repository>
</repositories>

and then you can add your dependency as

<dependency>
    <groupId>com.test.app</groupId>
    <artifactId>app-jar</artifactId>
    <version>1.0</version>
</dependency>
MattRS
  • 428
  • 5
  • 8
  • The problem with this approach is the jar will be packaged into the project when I generate the war file, which is what I'm trying to prevent here... otherwise, I'll end up with one jar in the project, and another jar at the server classloader. – limc Feb 17 '12 at 18:53
0

I approve of provided. Provided means - download the dependency for compile-time, but I expect to see it on classpath on the application server.

I did not realize you care only for your local development, so the following would be useful if you were running Jetty on an external server:

Maven will let you deploy a file to a server using the Wagon plugin. So a part of your build process could be pushing the proper .jar into your Jetty server. That way you would not have to do it manually. I would prefer this solution to running a local Maven repository on the Jetty server as suggested by @Paul.

If you wanted to be super-clever (usually a bad idea), you might try to set up a repository directly on the machine with Jetty, that would serve the jar directly from your Jetty install. That way you would not have to modify Nexus, the jars would be only at one place. You can even set up Nexus to mirror another repository, so it could pick things up automatically.

It is a bad practice to modify .jar contents and keep the same Maven coordinates. So this "clever" approach would not work that great anyway.

Roman Zenka
  • 3,514
  • 3
  • 31
  • 36