You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "JDM (JIRA)" <ji...@apache.org> on 2016/08/23 19:40:20 UTC

[jira] [Commented] (MWAR-395) REGRESSION: Conflict with Workspace Resolution in Eclipse

    [ https://issues.apache.org/jira/browse/MWAR-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15433460#comment-15433460 ] 

JDM commented on MWAR-395:
--------------------------

I'm unsure how to fix this myself. My initial response is that {{copyFile}} is too overloaded at this point. The context of the copy has been lost at this point (resource, dependency, etc) and is no longer able to make the correct decisions. It seems like having two separate paths, perhaps {{copyResourceFile}} and {{copyDependencyFile}} would allow resolution by maintaining the context of the copy. Resources could then simply create the directory at the new target, while dependencies could package the directory as a JAR.

> REGRESSION: Conflict with Workspace Resolution in Eclipse
> ---------------------------------------------------------
>
>                 Key: MWAR-395
>                 URL: https://issues.apache.org/jira/browse/MWAR-395
>             Project: Maven WAR Plugin
>          Issue Type: Bug
>    Affects Versions: 2.4, 2.5, 2.6
>         Environment: Eclipse Mars (4.5.2)
> Eclipse m2e 1.6.2
>            Reporter: JDM
>
> MWAR-192 first introduced this issue. When executing a Maven WAR build through Eclipse, it allows resolution of other projects within the workspace via "Resolve Workspace artifacts" in the run configuration. This replaces the project dependencies that would normally be JARs with the {{target/classes}} directories for the projects.
> Here's a sample verbose output from the compiler plugin which shows this replacement, where "WarProject" is the WAR project and "JarProject" is a JAR project:
> {code}
> [DEBUG] Classpath: [~/WarProject/target/classes
>  ~/JarProject/target/classes
>  ~/.m2/repository/javax/servlet/javax.servlet-api/3.0.1/javax.servlet-api-3.0.1.jar]
> {code}
> This was corrected with a patch merged in revision [1492158|https://fisheye6.atlassian.com/changelog/maven?cs=1492158]. Unfortunately, this fix was then regressed 18 days later by revision [1498124|https://fisheye6.atlassian.com/changelog/maven?cs=1498124] for issue MWAR-128.
> Previous to the second commit, the {{target/classes}} directory would be passed to {{AbstractWarPackagingTask.copyFile}} by {{ArtifactsPackagingTask.performPackaging}}. It would then be registered and passed to the second overload of {{AbstractWarPackagingTask.copyFile}}, where the directory would then be bundled into a JAR.
> After the second commit, any directory passed to that first {{copyFile}} will simply result in an empty directory with the target name being created. This is exactly the result I see after packaging the WAR:
> {code}
> WarProject-1.0.0.war
> |> WEB-INF/
>    |> lib/
>       |> JarProject-1.0.0.jar/
>       |> javax.servlet-api-3.0.1.jar
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)