[
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)