JDM created MWAR-395:
------------------------
Summary: 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.6, 2.5, 2.4
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)
