zDev - M2E - OSS
  1. zDev - M2E - OSS
  2. MNGECLIPSE-714

dependency scope "provided" is ignored when working with WTP

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.4, 0.9.5, 0.9.6
    • Fix Version/s: 0.9.9 iteration 10/05
    • Component/s: WTP integration
    • Labels:
      None
    • Environment:
      Windows XP, eclipse Version: 3.3.1.1, Maven 2.0.9
    • Global Rank:
      12841

      Description

      After the migration of m2eclipse from 0.0.12 to 0.9.4 we have the problem, that dependencies with scope provided are packaged into the ear!
      So we can't deploy because this new behaviour results in classloader problems.

      The dependency section in our parent pom looks like this:

      <dependencies>
      	<dependency>
      		<groupId>javax.j2ee</groupId>
      		<artifactId>j2ee</artifactId>
      		<version>1.4</version>
      		<scope>provided</scope>
      	</dependency>
      	<dependency>
      		<groupId>log4j</groupId>
      		<artifactId>log4j</artifactId>
      		<version>1.2.9</version>
      		<scope>provided</scope>
      	</dependency>
      </dependencies>
      

      Both artifacts are packaged into the ear.

      1. Do not publish MAVEN2_CLASSPATH_CONTAINER.jpg
        81 kB
      2. Do not publish MAVEN2_CLASSPATH_CONTAINER.jpg
        81 kB
      3. j2ee_dependencies.png
        137 kB
      4. JEEdependencies.jpg
        72 kB
      5. maven_dependencies.png
        187 kB
      6. WTP-Server-deploy.jpg
        109 kB

        Issue Links

          Activity

          Hide
          Fred Bricon added a comment -

          By default, m2e doesn't set the Maven Library as exported for Ejb/Jar projects, but some users might have set it by mistake.

          You need to check the following :

          • right click on your Utility/EJB project > Properties > Java EE Module Dependencies. * You must make sure the Maven Library's not selected, otherwise, all your dependencies will be deployed in your containing Wars/Ears

          For these projects, the following warning may appear : "Classpath entry org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER will not be exported or published. Runtime ClassNotFoundExceptions may result.".
          Select the corresponding quick fix, make sure to select "Exclude the associated classpath ...". Unfortunately, until MNGECLIPSE-1587 is resolved, that setting will be lost with the next "Maven > Update Project Configuration"

          regards,

          Fred Bricon

          Show
          Fred Bricon added a comment - By default, m2e doesn't set the Maven Library as exported for Ejb/Jar projects, but some users might have set it by mistake. You need to check the following : right click on your Utility/EJB project > Properties > Java EE Module Dependencies. * You must make sure the Maven Library's not selected, otherwise, all your dependencies will be deployed in your containing Wars/Ears For these projects, the following warning may appear : "Classpath entry org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER will not be exported or published. Runtime ClassNotFoundExceptions may result.". Select the corresponding quick fix, make sure to select "Exclude the associated classpath ...". Unfortunately, until MNGECLIPSE-1587 is resolved, that setting will be lost with the next "Maven > Update Project Configuration" regards, Fred Bricon
          Hide
          Ulli Adrion added a comment -

          Hi Fred

          Thanks for providing that workaround. Indeed – it works. But the disadvantage of this workaround is that the developer (or integrator) has to define twice the same information (in the POM and in the JEE Module Dependencies of the corresponding module) whether a library has to be packaged (compile/runtime scope) or not (provided/test scope).

          I would recommend that the JEE Module Dependencies GUI should be commented with "Do not activate Maven Dependencies here – it's intended for later versions" or something similiar or just remove this option until this bug can be fixed.

          Kind regards, Ulrike

          Show
          Ulli Adrion added a comment - Hi Fred Thanks for providing that workaround. Indeed – it works. But the disadvantage of this workaround is that the developer (or integrator) has to define twice the same information (in the POM and in the JEE Module Dependencies of the corresponding module) whether a library has to be packaged (compile/runtime scope) or not (provided/test scope). I would recommend that the JEE Module Dependencies GUI should be commented with "Do not activate Maven Dependencies here – it's intended for later versions" or something similiar or just remove this option until this bug can be fixed. Kind regards, Ulrike
          Hide
          Fred Bricon added a comment -

          The fix for MNGECLIPSE-855 should be enough to close this issue : the Maven Library being flagged as non deployable on EJB and Utility projects, you shouldn't see any more provided dependencies being deployed.

          Ulli, I suggest you file an enhancement request if you want to disable the Maven Library in the JavEE Module dependencies page.

          regards,

          Fred Bricon

          Show
          Fred Bricon added a comment - The fix for MNGECLIPSE-855 should be enough to close this issue : the Maven Library being flagged as non deployable on EJB and Utility projects, you shouldn't see any more provided dependencies being deployed. Ulli, I suggest you file an enhancement request if you want to disable the Maven Library in the JavEE Module dependencies page. regards, Fred Bricon
          Hide
          Ulli Adrion added a comment -

          Would it be possible to test the fix before the release of 0.9.9 iteration 10/05?
          Thanks and kind regards,
          Ulli

          Show
          Ulli Adrion added a comment - Would it be possible to test the fix before the release of 0.9.9 iteration 10/05? Thanks and kind regards, Ulli
          Hide
          Rich Seddon added a comment -

          verified in 0.9.9.200912221003 with attached sample projects.

          dependencies of scope "provided" are now handled properly.

          Show
          Rich Seddon added a comment - verified in 0.9.9.200912221003 with attached sample projects. dependencies of scope "provided" are now handled properly.

            People

            • Assignee:
              Unassigned
              Reporter:
              Ulli Adrion
            • Votes:
              11 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Date of First Response: