Jetty
  1. Jetty
  2. JETTY-429

Allow provided scope dependencies on classpath

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.1.5
    • Fix Version/s: 7.5.2
    • Component/s: Maven
    • Labels:
      None
    • Patch Submitted:
      Yes
    • Number of attachments :
      1

      Description

      There is a parameter which allows "test" scope dependencies to be added to the Jetty classpath. "Provided" scope dependencies are always ignored. This is an annoyance if you wish to exlcude dependencies from the projects WAR but still have them on the classpath when testing with Jetty.

      I have attached a patch which adds a parameter <useProvidedClasspath> to allow this. This was made against the current trunk, but tested with Jetty 6.1.5 as the parent POM as I am unable to compile 6.1-SNAPSHOT of Jetty due to the Glassfish CVS being down (which a checkout of seems to be required at some stage).

        Activity

        Hide
        Pavel Volkovitskiy added a comment -

        also, according maven docs:
        provided - .. This scope is only available on the compilation and test classpath, and is not transitive

        so, maven put such deps into test classpath, so why jetty-maven-plugin doesn't uses them with useTestClasspath ?

        but if you don't want to change current behavior then adding new flag with default to false will work too

        Show
        Pavel Volkovitskiy added a comment - also, according maven docs: provided - .. This scope is only available on the compilation and test classpath, and is not transitive so, maven put such deps into test classpath, so why jetty-maven-plugin doesn't uses them with useTestClasspath ? but if you don't want to change current behavior then adding new flag with default to false will work too
        Hide
        Tim Meighen added a comment -

        I ran into this again today. I am building an app that ships with embedded jetty and uses slf4j. The bootstrap class that handles startup/shutdown of jetty also uses slf4j, so I want it in the system classpath and not the webapp. I marked slf4j-api as provided and slf4j-simple as test. When the jetty plugin runs the app dies because it can't find slf4j-api. I ended up having to mark slf4j-simple as "provided" (which is wrong) and duplicate the slf4j-api and slf4j-simple declarations in the plugin configuration.

        In my mind, using a profile is a sub-optimal solution. I have done it in the past but it means having to pass this knowledge around the dev team which often doesn't happen. People also tend to forget what custom flag they're supposed to use and then they get frustrated and blame Maven.

        Show
        Tim Meighen added a comment - I ran into this again today. I am building an app that ships with embedded jetty and uses slf4j. The bootstrap class that handles startup/shutdown of jetty also uses slf4j, so I want it in the system classpath and not the webapp. I marked slf4j-api as provided and slf4j-simple as test. When the jetty plugin runs the app dies because it can't find slf4j-api. I ended up having to mark slf4j-simple as "provided" (which is wrong) and duplicate the slf4j-api and slf4j-simple declarations in the plugin configuration. In my mind, using a profile is a sub-optimal solution. I have done it in the past but it means having to pass this knowledge around the dev team which often doesn't happen. People also tend to forget what custom flag they're supposed to use and then they get frustrated and blame Maven.
        Hide
        jasseri added a comment - - edited

        I was also battling this issue, but using profiles solved the problem just fine. I also have an EAR app, and I want to test a webapp that will be included in the ear with Jetty. In my webapp's pom I defined the following profiles:

        <profiles>

        <profile>
        <id>default</id>
        <activation>
        <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
        <shared_dependency_scope>provided</shared_dependency_scope>
        </properties>
        </profile>

        <profile>
        <id>jetty</id>
        <properties>
        <shared_dependency_scope>compile</shared_dependency_scope>
        </properties>
        </profile>

        </profiles>

        Then I changed the dependency scope for the dependency in question:

        <dependency>

        <groupId>myapp</groupId>
        <artifactId>myapp_shared</artifactId>
        <scope>$

        {shared_dependency_scope}

        </scope>

        </dependency>

        Now, when I run a typical mvn clean install, the scope will be 'provided' (activeByDefault set to true for profile 'default'). And when I want to test my webapp with Jetty, I run it like this: 'mvn -P jetty jetty:run'. Works like a charm. The problem for me was that I didn't know profiles too well before running into this issue...

        Show
        jasseri added a comment - - edited I was also battling this issue, but using profiles solved the problem just fine. I also have an EAR app, and I want to test a webapp that will be included in the ear with Jetty. In my webapp's pom I defined the following profiles: <profiles> <profile> <id>default</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <shared_dependency_scope>provided</shared_dependency_scope> </properties> </profile> <profile> <id>jetty</id> <properties> <shared_dependency_scope>compile</shared_dependency_scope> </properties> </profile> </profiles> Then I changed the dependency scope for the dependency in question: <dependency> <groupId>myapp</groupId> <artifactId>myapp_shared</artifactId> <scope>$ {shared_dependency_scope} </scope> </dependency> Now, when I run a typical mvn clean install, the scope will be 'provided' (activeByDefault set to true for profile 'default'). And when I want to test my webapp with Jetty, I run it like this: 'mvn -P jetty jetty:run'. Works like a charm. The problem for me was that I didn't know profiles too well before running into this issue...
        Hide
        Steve Ardis added a comment - - edited

        Thanks for the "profile" solution (wasn't very aware of this feature) and I'm using it for the time being.

        I'm hoping for a more elegant solution than using profiles though, as I'd rather for developers to be able to pull directly out of source control and run without having to know to pass a "-P" argument to Maven. I envision a solution using something like a <includeProvidedScope> (default to false) element in the <configuration> section of the maven-jetty-plugin; i.e

        <groupId>org.mortbay.jetty</groupId>
        <artifactId>maven-jetty-plugin</artifactId>
        <version>...</version>
        <configuration>
        <jettyEnvXml>$

        {basedir}

        /jetty-env.xml</jettyEnvXml>
        <includeProvidedScope>true</includeProvidedScope>
        </configuration>

        This way I can provide sensible defaults for my application.

        Steve Ardis

        Show
        Steve Ardis added a comment - - edited Thanks for the "profile" solution (wasn't very aware of this feature) and I'm using it for the time being. I'm hoping for a more elegant solution than using profiles though, as I'd rather for developers to be able to pull directly out of source control and run without having to know to pass a "-P" argument to Maven. I envision a solution using something like a <includeProvidedScope> (default to false) element in the <configuration> section of the maven-jetty-plugin; i.e <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <version>...</version> <configuration> <jettyEnvXml>$ {basedir} /jetty-env.xml</jettyEnvXml> <includeProvidedScope>true</includeProvidedScope> </configuration> This way I can provide sensible defaults for my application. Steve Ardis
        Hide
        Jan Bartel added a comment -

        Ok, I have added a new <configuration> parameter <useProvided>. When true, it will add the dependencies with <scope>provided</scope> onto the plugin's classpath (NOT the webapp's classpath, which is different).

        I have tried to eliminate jars that are duplicates between the existing plugin classpath and the provided scope dependencies, however it is still possible to get duplicate classes onto the runtime classpath if the provided scope dependency has a different name. So, please use this flag very carefully. And if you're using it, and the classpath gets all screwed up, please consider "I told you so" before raising a jira for it

        Jan

        Show
        Jan Bartel added a comment - Ok, I have added a new <configuration> parameter <useProvided>. When true, it will add the dependencies with <scope>provided</scope> onto the plugin's classpath (NOT the webapp's classpath, which is different). I have tried to eliminate jars that are duplicates between the existing plugin classpath and the provided scope dependencies, however it is still possible to get duplicate classes onto the runtime classpath if the provided scope dependency has a different name. So, please use this flag very carefully . And if you're using it, and the classpath gets all screwed up, please consider "I told you so" before raising a jira for it Jan

          People

          • Assignee:
            Jan Bartel
            Reporter:
            Martin Gilday
          • Votes:
            17 Vote for this issue
            Watchers:
            18 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: