Maven WAR Plugin
  1. Maven WAR Plugin
  2. MWAR-192

Conflict with workspace resoutlion in m2eclipse

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1-alpha-2
    • Fix Version/s: 2.4
    • Component/s: None
    • Labels:
      None
    • Environment:
      windows vista

      Description

      While building my webapp in eclipse using a launch configuration (goals clean install) and having 'Resolve Workspace Artifacts' checked, the war plugin cant assemble the war file properly. Note that disabled 'Resolve Workspace Artifacts' and the war is assembled fine

      [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar
      [INFO] ------------------------------------------------------------------------
      [ERROR] BUILD ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] Failed to copy file for artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile]

      Embedded error: C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes (Access is denied)
      [INFO] ------------------------------------------------------------------------
      [DEBUG] Trace
      org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file for artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile]
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
      at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
      at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
      at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:585)
      at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
      at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
      at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
      at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
      Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to copy file for artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile]
      at org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125)
      at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183)
      at org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103)
      at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439)
      at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375)
      at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181)
      at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)
      at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
      ... 16 more
      Caused by: java.io.FileNotFoundException: C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes (Access is denied)
      at java.io.FileInputStream.open(Native Method)
      at java.io.FileInputStream.<init>(FileInputStream.java:106)
      at org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:78)
      at org.codehaus.plexus.util.FileUtils.copyStreamToFile(FileUtils.java:1057)
      at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:965)
      at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:293)
      at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask$1.registered(AbstractWarPackagingTask.java:150)
      at org.apache.maven.plugin.war.util.WebappStructure.registerFile(WebappStructure.java:176)
      at org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:145)
      at org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:100)
      ... 24 more

      1. maven-war-plugin.patch
        2 kB
        Eugene Kuleshov
      2. maven-war-plugin-2.1.1-patch.jar
        76 kB
        jurevert
      3. MWAR-192-maven-war-plugin.patch
        2 kB
        jurevert

        Issue Links

          Activity

          Hide
          Max Powers added a comment -

          note, using m2eclipse (probably handy info)

          Show
          Max Powers added a comment - note, using m2eclipse (probably handy info)
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          So is it really a war plugin issue ?
          Does it works when invoking maven with cli ?

          Show
          Olivier Lamy (*$^¨%`£) added a comment - So is it really a war plugin issue ? Does it works when invoking maven with cli ?
          Hide
          Corb Negru added a comment - - edited

          IMHO it's not a war-plugin bug, but a m2eclipse bug. I've experienced it using m2eclipse, but not using command-line mvn.
          As indicated, the real root bug is http://jira.codehaus.org/browse/MNGECLIPSE-1224

          Show
          Corb Negru added a comment - - edited IMHO it's not a war-plugin bug, but a m2eclipse bug. I've experienced it using m2eclipse, but not using command-line mvn. As indicated, the real root bug is http://jira.codehaus.org/browse/MNGECLIPSE-1224
          Hide
          Eugene Kuleshov added a comment - - edited

          Guys, you can call this an m2eclipse bug or feature, but it all boils down to the current Maven and maven-war-plugin limitations.

          What happen is that m2eclipse can resolve projects from the Eclipse workspace, so you can compile and run your code without deploying dependent projects to the Maven local repository. Normally, when Maven resolves artifacts it points to the file from the Maven local repository, but in order to make workspace dependency resolution work, m2eclipse replaces that link to a link pointing to a /target/classes folder for the corresponding project (you can see that in the exception stack trace above).

          All in all, there is no easy fix for this issue on m2eclipse side, however the maven-war-plugin could detect that it got a class folder and not the jar file for the given artifact and in that case it can simply jar that folder and include the result jar into the web-inf/lib instead of trying to blindly copy it there.

          Please also note that you can disable workspace resolution when launching Maven builds from m2eclipse, so Maven would resolve artifacts from the local repository.

          Show
          Eugene Kuleshov added a comment - - edited Guys, you can call this an m2eclipse bug or feature, but it all boils down to the current Maven and maven-war-plugin limitations. What happen is that m2eclipse can resolve projects from the Eclipse workspace, so you can compile and run your code without deploying dependent projects to the Maven local repository. Normally, when Maven resolves artifacts it points to the file from the Maven local repository, but in order to make workspace dependency resolution work, m2eclipse replaces that link to a link pointing to a /target/classes folder for the corresponding project (you can see that in the exception stack trace above). All in all, there is no easy fix for this issue on m2eclipse side, however the maven-war-plugin could detect that it got a class folder and not the jar file for the given artifact and in that case it can simply jar that folder and include the result jar into the web-inf/lib instead of trying to blindly copy it there. Please also note that you can disable workspace resolution when launching Maven builds from m2eclipse, so Maven would resolve artifacts from the local repository.
          Hide
          Eugene Kuleshov added a comment -

          A quick and dirty patch that fixes the issue in m2eclipse. Basically it just jars the classes folder substituted by m2eclipse instead of jar from the local Maven repo.

          Show
          Eugene Kuleshov added a comment - A quick and dirty patch that fixes the issue in m2eclipse. Basically it just jars the classes folder substituted by m2eclipse instead of jar from the local Maven repo.
          Hide
          Mark Diggory added a comment -

          Yes this is a problem that make using m2eclipse to build multimodule projects in eclipse very painful indeed. Please do fix this, its not a feature, its a bug... m2eclipse should do the following:

          1.) look at the project and make sure its build status is up to date

          2.) look for produced artifact jar in target directory

          3.) if not, look for classes directory and mount that.

          4.) otherwise, attempt to run mvn package within the project and create the artifacts.

          Show
          Mark Diggory added a comment - Yes this is a problem that make using m2eclipse to build multimodule projects in eclipse very painful indeed. Please do fix this, its not a feature, its a bug... m2eclipse should do the following: 1.) look at the project and make sure its build status is up to date 2.) look for produced artifact jar in target directory 3.) if not, look for classes directory and mount that. 4.) otherwise, attempt to run mvn package within the project and create the artifacts.
          Hide
          Eugene Kuleshov added a comment -

          Mark, I am not sure you understand the issue. The m2eclipse don't have much control on the build, so it isn't really option for it to go somewhere and do something when Maven build is requesting some arbitrary artifact. The present Maven API does not provide any context what requested artifact is needed for, so while workspace resolution is working fine for compile-time needs, other plugins, including the maven-war-plugin fail when they get reference to an exploded classpath folder instead of a jar.

          Show
          Eugene Kuleshov added a comment - Mark, I am not sure you understand the issue. The m2eclipse don't have much control on the build, so it isn't really option for it to go somewhere and do something when Maven build is requesting some arbitrary artifact. The present Maven API does not provide any context what requested artifact is needed for, so while workspace resolution is working fine for compile-time needs, other plugins, including the maven-war-plugin fail when they get reference to an exploded classpath folder instead of a jar.
          Hide
          Andras Gerlits added a comment -

          What I don't understand about this (and which I already wasted substantial time over) is why not even the following works:

          <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-dependency-plugin</artifactId>
          <executions>
          <execution>
          <id>copy-dependencies</id>
          <phase>validate</phase>
          <goals>
          <goal>copy-dependencies</goal>
          </goals>
          <configuration>
          <includeGroupIds>org.springframework</includeGroupIds>
          <excludeGroupIds>$

          {our.project.groupId}

          </excludeGroupIds>
          <excludeTransitive>true</excludeTransitive>
          <outputDirectory>$

          {gwt.output.directory}

          /WEB-INF/lib</outputDirectory>
          </configuration>
          </execution>
          </executions>
          </plugin>

          Even though I'm explicitly disallowing our project's groupIds to be copied over and declaring that I'm only interested in Spring, it insists on accessing the classes folder on a dependency I'm uninterested in. I'm also clearly stating that I'm uninterested in transitive dependencies.

          So, does this mean that there is no way to copy any dependency to an external folder with the "resolve workspace" checkbox enabled?

          What this means is that we have 2 choices here (due to our modular architecture):

          • rebuild and repackage the whole project every time want to reference it in the other one
          • abandon our m2eclipse-based environment and either build manually or migrate to ANT?

          Not copying dependencies over to the WEB-INF/lib folder is not an option (mainly due to a bug in the bootstrap classloader, but also because that's where they belong).

          Show
          Andras Gerlits added a comment - What I don't understand about this (and which I already wasted substantial time over) is why not even the following works: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>copy-dependencies</id> <phase>validate</phase> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <includeGroupIds>org.springframework</includeGroupIds> <excludeGroupIds>$ {our.project.groupId} </excludeGroupIds> <excludeTransitive>true</excludeTransitive> <outputDirectory>$ {gwt.output.directory} /WEB-INF/lib</outputDirectory> </configuration> </execution> </executions> </plugin> Even though I'm explicitly disallowing our project's groupIds to be copied over and declaring that I'm only interested in Spring, it insists on accessing the classes folder on a dependency I'm uninterested in. I'm also clearly stating that I'm uninterested in transitive dependencies. So, does this mean that there is no way to copy any dependency to an external folder with the "resolve workspace" checkbox enabled? What this means is that we have 2 choices here (due to our modular architecture): rebuild and repackage the whole project every time want to reference it in the other one abandon our m2eclipse-based environment and either build manually or migrate to ANT? Not copying dependencies over to the WEB-INF/lib folder is not an option (mainly due to a bug in the bootstrap classloader, but also because that's where they belong).
          Hide
          Eugene Kuleshov added a comment - - edited

          Andras, please see my explanation in comment from 07/May/09. Your third and fully supported option is to use the WTP integration while developing in the IDE (i.e. have WTP integration enabled and let WTP to package and copy required jars into WEB-INF/lib), in that case you won't need any additional configuration like maven-dependency-plugin, which also known as not compatible with m2e's workspace dependency resolution mode.

          Show
          Eugene Kuleshov added a comment - - edited Andras, please see my explanation in comment from 07/May/09. Your third and fully supported option is to use the WTP integration while developing in the IDE (i.e. have WTP integration enabled and let WTP to package and copy required jars into WEB-INF/lib), in that case you won't need any additional configuration like maven-dependency-plugin, which also known as not compatible with m2e's workspace dependency resolution mode.
          Hide
          Andreas Veithen added a comment -

          I think this should be considered a bug in maven-war-plugin and maven-dependency-plugin. MDEP-259 gives a clear explanation of the problem in the context of the maven-dependency-plugin and also shows how to trigger the error from the command line.

          Show
          Andreas Veithen added a comment - I think this should be considered a bug in maven-war-plugin and maven-dependency-plugin. MDEP-259 gives a clear explanation of the problem in the context of the maven-dependency-plugin and also shows how to trigger the error from the command line.
          Hide
          Joshua Bailey added a comment -

          I'm running Version: 2.7.1.RELEASE. What is the equivalent to disabling 'Resolve Workspace Artifacts'? Has this issue been fixed in any later releases?

          Show
          Joshua Bailey added a comment - I'm running Version: 2.7.1.RELEASE. What is the equivalent to disabling 'Resolve Workspace Artifacts'? Has this issue been fixed in any later releases?
          Hide
          jurevert added a comment - - edited

          I have merge patch information in 2.1.1 maven-war plugin release. If it could help...

          Show
          jurevert added a comment - - edited I have merge patch information in 2.1.1 maven-war plugin release. If it could help...
          Hide
          Richard Sand added a comment -

          Is this issue going to be addressed? Does the patch attached to the case work?

          Show
          Richard Sand added a comment - Is this issue going to be addressed? Does the patch attached to the case work?
          Hide
          jurevert added a comment -

          Yes, this bug still present un 2.3.
          The patch works.
          Here is an up to date patch create from svn trunk (revision 1478686).
          Does a contributor could integrate it for next maven-war-plugin release ?

          Show
          jurevert added a comment - Yes, this bug still present un 2.3. The patch works. Here is an up to date patch create from svn trunk ( revision 1478686 ). Does a contributor could integrate it for next maven-war-plugin release ?
          Hide
          Olivier Lamy (*$^¨%`£) added a comment -

          patch applied.
          Thanks!

          Show
          Olivier Lamy (*$^¨%`£) added a comment - patch applied. Thanks!

            People

            • Assignee:
              Olivier Lamy (*$^¨%`£)
              Reporter:
              Max Powers
            • Votes:
              33 Vote for this issue
              Watchers:
              21 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development