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/24 17:48:20 UTC

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

     [ https://issues.apache.org/jira/browse/MWAR-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

JDM updated MWAR-395:
---------------------
    Attachment: MWAR-395.zip

Eclipse projects demonstrating issue.

> 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
>         Attachments: MWAR-395.zip
>
>
> 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)