Maven Eclipse Plugin
  1. Maven Eclipse Plugin
  2. MECLIPSE-184

Ear utility-jar are put in WEB-INF/lib of the wtp ear

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.3
    • Fix Version/s: None
    • Component/s: WTP support
    • Labels:
      None
    • Environment:
      Tested on Windows XP and Linux Ubuntu Dapper Drake
    • Number of attachments :
      0

      Description

      It seems that the maven eclipse plugin add ear jar dependencies in the
      WEB-INF/lib directory.

      I've used the following command : mvn eclipse:clean
      eclipse:eclipse -Dwtpversion=1.0 (I've also tried 1.5 with the snapshot
      version)

      And when deploy the ear project through WTP in a J2EE Server I see the
      following structure :

      my-ear
        |---- my-ejb.jar
        |---- my-webapp.war
        |---- META-INF/
                      |---- application.xml
                      |---- MANIFEST.MF
        |
        |----- WEB-INF/
                      |---- lib
                              |---- dependency-1.jar
                              |---- dependency-2.jar

      But I don't expect these dependencies to be here, I expect something like
      this :

      my-ear
        |---- my-ejb.jar
        |---- my-webapp.war
        |---- META-INF/
                      |---- application.xml
                      |---- MANIFEST.MF
        |
        |----- dependency-1.jar
        |----- dependency-2.jar

      So I've checked quickly the SVN repository and it seems that the directory in
      which we put "ear utility jar" is hard coded as "WEB-INF/lib" (->
      AbstractWtpResourceWritter.addDependency() which is the same for the war and the ear ... )

      Are you OK with this packaging ? It can be a good thing if we could configure where wtp will
      put these ear utility-jars and by default it would be in "/" or "lib".

      Thanks In Advance

      Elid OR

        Issue Links

          Activity

          Hide
          Arnaud Heritier added a comment -

          Can we consider that it is related to MECLIPSE-167 (that is to say, how to put libraries directly in the ear and not in each war)

          Show
          Arnaud Heritier added a comment - Can we consider that it is related to MECLIPSE-167 (that is to say, how to put libraries directly in the ear and not in each war)
          Hide
          Thierry Levieux added a comment -

          ... In my opinion MECLIPSE-167 is another issue (cross-plugin issue)

          I agree with Elid.

          The problem is caused by the chain:

          EclipseWtpComponentWriter::writeModuleTypeComponent() -> writeWarOrEarResources() -> addDependency() - > "deploy-path"="/WEB-INF/lib"

          • To solve this issue I suggest to replace any call to writeWarOrEarResources()
            by two dedicated methods:
            writeWarResources()
            writeEarResources()
          • Change the AbstractWtpResourceWriter::addDependency() signature by adding a 'deployPath' parameter

          writeWarResources -> addDependency(..., "/WEB-INF/lib")
          writeEarResources -> addDependency(..., "/")

          • then modify addDependency()'s body
            writer.addAttribute( ATTR_DEPLOY_PATH, "/WEB-INF/lib") => writer.addAttribute( ATTR_DEPLOY_PATH, deployPath)

          Thierry

          Show
          Thierry Levieux added a comment - ... In my opinion MECLIPSE-167 is another issue (cross-plugin issue) I agree with Elid. The problem is caused by the chain: EclipseWtpComponentWriter::writeModuleTypeComponent() -> writeWarOrEarResources() -> addDependency() - > "deploy-path"="/WEB-INF/lib" To solve this issue I suggest to replace any call to writeWarOrEarResources() by two dedicated methods: writeWarResources() writeEarResources() Change the AbstractWtpResourceWriter::addDependency() signature by adding a 'deployPath' parameter writeWarResources -> addDependency(..., "/WEB-INF/lib") writeEarResources -> addDependency(..., "/") then modify addDependency()'s body writer.addAttribute( ATTR_DEPLOY_PATH, "/WEB-INF/lib") => writer.addAttribute( ATTR_DEPLOY_PATH, deployPath) Thierry
          Hide
          Arnaud Heritier added a comment -

          is related to ?

          Show
          Arnaud Heritier added a comment - is related to ?
          Hide
          Siarhei Dudzin added a comment -

          Arnaud, I don't think this issue is valid anymore. I configure location of utility jar's by specifying <defaultLibBundleDir>lib</defaultLibBundleDir>
          in the config of ear plugin and it deploys correctly by WTP+JBoss Tools combination (it does exploded deployment which works very well).

          So by using this setting I get the /lib in my ear where all the utility jar's are stored...

          Show
          Siarhei Dudzin added a comment - Arnaud, I don't think this issue is valid anymore. I configure location of utility jar's by specifying <defaultLibBundleDir>lib</defaultLibBundleDir> in the config of ear plugin and it deploys correctly by WTP+JBoss Tools combination (it does exploded deployment which works very well). So by using this setting I get the /lib in my ear where all the utility jar's are stored...
          Hide
          Gabor Willner added a comment -

          Siarhei, could you tell me where do I find that file with that

          <defaultLibBundleDir>lib</defaultLibBundleDir>

          tag?

          I use Eclipse 3.3, Maven Integration for Eclipse 0.0.12 and Maven Integration for Mylyn 0.0.12 and I experience the same problem with missing WebApp libs (but other resources are synchronised ok).

          Thanks,

          Gabor

          Show
          Gabor Willner added a comment - Siarhei, could you tell me where do I find that file with that <defaultLibBundleDir>lib</defaultLibBundleDir> tag? I use Eclipse 3.3, Maven Integration for Eclipse 0.0.12 and Maven Integration for Mylyn 0.0.12 and I experience the same problem with missing WebApp libs (but other resources are synchronised ok). Thanks, Gabor
          Hide
          Siarhei Dudzin added a comment -

          Here: http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html

          You can find an example in one of bug report attachments I've ever created: http://jira.jboss.org/jira/secure/attachment/12316955/test-project-JBIDE-1322.zip

          And btw I had to drop usage of m2eclipse because it didn't support all configuration features I had in my pom's (I guess one of the reasons may be that it in fact uses maven 2.1 instead of user-installed maven 2.0.x).

          Show
          Siarhei Dudzin added a comment - Here: http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html You can find an example in one of bug report attachments I've ever created: http://jira.jboss.org/jira/secure/attachment/12316955/test-project-JBIDE-1322.zip And btw I had to drop usage of m2eclipse because it didn't support all configuration features I had in my pom's (I guess one of the reasons may be that it in fact uses maven 2.1 instead of user-installed maven 2.0.x).
          Hide
          Arnaud Heritier added a comment -

          m2eclipse doesn't use maven 2.1, but Q4E do it.
          Support for WTP in Q4E and m2eclipse is very very far from what you have with the eclipse:eclipse mojo

          Show
          Arnaud Heritier added a comment - m2eclipse doesn't use maven 2.1, but Q4E do it. Support for WTP in Q4E and m2eclipse is very very far from what you have with the eclipse:eclipse mojo
          Hide
          Siarhei Dudzin added a comment -

          Well I thought it does because I saw this (and in more places): http://docs.codehaus.org/display/M2ECLIPSE/Project+FAQ#ProjectFAQ-WhatMavenversionisusedbyplugin

          it says:

          "Plugin is not actually using Maven itself. It is using component that is part of Maven called Maven Embedder. This component is not available for Maven 2.0.x. Embedder is used by the Maven command line interface (CLI) starting from version 2.1, so the current version of Embedder correspond to the Maven 2.1 code line that include number of improvements to allow to actually embed Maven."

          I agree with you, Arnaud, on both those plugins - they are pretty far from full wtp interop yet.

          Show
          Siarhei Dudzin added a comment - Well I thought it does because I saw this (and in more places): http://docs.codehaus.org/display/M2ECLIPSE/Project+FAQ#ProjectFAQ-WhatMavenversionisusedbyplugin it says: "Plugin is not actually using Maven itself. It is using component that is part of Maven called Maven Embedder. This component is not available for Maven 2.0.x . Embedder is used by the Maven command line interface (CLI) starting from version 2.1, so the current version of Embedder correspond to the Maven 2.1 code line that include number of improvements to allow to actually embed Maven." I agree with you, Arnaud, on both those plugins - they are pretty far from full wtp interop yet.
          Hide
          Arnaud Heritier added a comment -

          thanks for this info. I didn't know. I known that it was the case for Q4E but not for m2eclipse. It's certainly new. I didn't used and had a look at this plugin for several monthes.
          thx

          Show
          Arnaud Heritier added a comment - thanks for this info. I didn't know. I known that it was the case for Q4E but not for m2eclipse. It's certainly new. I didn't used and had a look at this plugin for several monthes. thx
          Hide
          Siarhei Dudzin added a comment -

          I had to drop it because it didn't support all the features of the pom I used for maven 2.0.x. And there was no major (if at all) release since... Which is unfortunate because now I have to use this: http://maven.apache.org/guides/mini/guide-ide-eclipse.html#Maven%20as%20an%20external%20tool

          Show
          Siarhei Dudzin added a comment - I had to drop it because it didn't support all the features of the pom I used for maven 2.0.x. And there was no major (if at all) release since... Which is unfortunate because now I have to use this: http://maven.apache.org/guides/mini/guide-ide-eclipse.html#Maven%20as%20an%20external%20tool
          Hide
          Jos van der Heiden added a comment -

          Adding <defaultLibBundleDir>lib</defaultLibBundleDir> might put the jars in that folder when packaging an ear with maven.
          However, the org.eclipse.wst.common.component file generated by maven-eclipse-plugin still uses /WEB-INF/lib as deploy-path for these utility jars.

          Now when another project (in my case a simple java project with some utility classes) needs one of these jars on it's classpath, the wtp wizard 'J2EE modules dependencies' in the properties of that project in eclipse allows you to add the jars available in the ear to the classpath in the manifest of that project.
          This wizard doesn't recognize the /WEB-INF/lib deploy-path in the ear settings (perhaps a bug in wtp, but still...), so I end up with a 'broken' class path.

          And anyway it just doesn't feel right to generate an .ear file with a WEB-INF/lib folder in it's root for the utility jars.

          So I would agree that writeWarOrEarResources() should be replace with two dedicated methods writeWarResources() and writeEarResources()

          Show
          Jos van der Heiden added a comment - Adding <defaultLibBundleDir>lib</defaultLibBundleDir> might put the jars in that folder when packaging an ear with maven. However, the org.eclipse.wst.common.component file generated by maven-eclipse-plugin still uses /WEB-INF/lib as deploy-path for these utility jars. Now when another project (in my case a simple java project with some utility classes) needs one of these jars on it's classpath, the wtp wizard 'J2EE modules dependencies' in the properties of that project in eclipse allows you to add the jars available in the ear to the classpath in the manifest of that project. This wizard doesn't recognize the /WEB-INF/lib deploy-path in the ear settings (perhaps a bug in wtp, but still...), so I end up with a 'broken' class path. And anyway it just doesn't feel right to generate an .ear file with a WEB-INF/lib folder in it's root for the utility jars. So I would agree that writeWarOrEarResources() should be replace with two dedicated methods writeWarResources() and writeEarResources()
          Hide
          Siarhei Dudzin added a comment -

          Jos, it appears you mean slightly different (but quite related) problem. The original issue is about having the directory layout. The problem with EAR module having libs in WEB-INF/lib does not exist anymore (the issue is dated Nov. 2006).

          Your problem is that org.eclipse.wst.common.component still has the wrong setting.

          Arnaud, does it make sense to create a separate issue for that and close this one (if everyone agrees of course)? This issue is 1.5 years old...

          I am getting lost now... Is this in fact a different issue?

          Show
          Siarhei Dudzin added a comment - Jos, it appears you mean slightly different (but quite related) problem. The original issue is about having the directory layout. The problem with EAR module having libs in WEB-INF/lib does not exist anymore (the issue is dated Nov. 2006). Your problem is that org.eclipse.wst.common.component still has the wrong setting. Arnaud, does it make sense to create a separate issue for that and close this one (if everyone agrees of course)? This issue is 1.5 years old... I am getting lost now... Is this in fact a different issue?
          Hide
          Arnaud Heritier added a comment -

          Completely agree.

          Show
          Arnaud Heritier added a comment - Completely agree.
          Hide
          Rob Stryker added a comment -

          This bug should be fixed once the patch at eclipse bugzilla makes it in.

          https://bugs.eclipse.org/bugs/show_bug.cgi?id=247090

          Show
          Rob Stryker added a comment - This bug should be fixed once the patch at eclipse bugzilla makes it in. https://bugs.eclipse.org/bugs/show_bug.cgi?id=247090
          Hide
          Rob Stryker added a comment -

          For those too lazy to click on the link, the class in charge of WTP's ear module and how it should be published is J2EEFlexProjDeployable. This is the class that, if there are children modules, the EAR will add the child module's dependencies in to the ear.

          The bug was some internal voo-doo, but basically it was adding all such child-module classpath jars rather than just those specifically designated as going in the ear.

          Show
          Rob Stryker added a comment - For those too lazy to click on the link, the class in charge of WTP's ear module and how it should be published is J2EEFlexProjDeployable. This is the class that, if there are children modules, the EAR will add the child module's dependencies in to the ear. The bug was some internal voo-doo, but basically it was adding all such child-module classpath jars rather than just those specifically designated as going in the ear.

            People

            • Assignee:
              Unassigned
              Reporter:
              Elid OR
            • Votes:
              10 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated: