jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2.x WAR Plugin
  • MWAR-5

warSourceExcludes not working properly

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0
  • Component/s: None
  • Labels:
    None
  • Environment:
    Win2k, Java 1.4.2_04, m2 beta1

Description

Note: I posted a message on Maven users list (http://www.mail-archive.com/users%40maven.apache.org/msg24088.html), but I got no answer so I post this issue, which in turn may or not be a bug... (sorry if it's not)

I experienced a strange behaviour with the 'warSourceExcludes' property. When I grab some Web projects from the CVS of my company, I usually get all the WEB-INF/lib Jars that the developers put in the CVS:

  • With Maven 1, I use the 'maven.war.src.excludes' property to exclude those Jars ('maven.war.src.excludes=*/lib/.*'), and it works well: the Jars packaged in the War are only the ones defined in the pom.
  • With m2, I tried to use the 'warSourceExcludes' property, which seemed to me to be the equivalent property. However, when the War is generated, there is no jar in the WEB-INF/lib folder. This works as if the plugin is excluding files after having copied the needed dependencies in the WEB-INF/lib folder (whereas in the Maven 1 version, it was excluding them before).

Looking at the code of the m2 plugin, the value of 'warSourceExcludes' is used in method #getExcludes which is actually called in #performPackaging method. If this property is to work the same way as in m1, its value should be used in #copyResources method, before copying the Jar dependencies in WEB-INF/lib.

What do you guys think of that? Am I right or am I missing something?

  • Options
    • Sort By Name
    • Sort By Date
    • Ascending
    • Descending
    • Download All

Attachments

  1. Text File
    MNG-1038-maven-war-plugin.patch
    18/Oct/05 4:35 AM
    0.6 kB
    Edwin Punzalan
  2. Text File
    MNG-1038-maven-war-plugin.patch
    12/Oct/05 8:21 PM
    0.8 kB
    Edwin Punzalan

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MWAR-39 Excludes configuration parameter not working for WEB-INF/lib

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Edwin Punzalan added a comment - 12/Oct/05 8:21 PM

I checked the code for the WAR plugin and found that this is already fixed.

However, when I tested it, I found a bug in plexus.getDefaultExcludes bec it was returning a fixed-sized List so adding objects into it is causing an exception.

The plexus patch would fix the plexus bug.
The war-plugin patch is a work-around for the plexus bug.

If the plexus patch is applied, the second patch is not needed anymore.

Show
Edwin Punzalan added a comment - 12/Oct/05 8:21 PM I checked the code for the WAR plugin and found that this is already fixed. However, when I tested it, I found a bug in plexus.getDefaultExcludes bec it was returning a fixed-sized List so adding objects into it is causing an exception. The plexus patch would fix the plexus bug. The war-plugin patch is a work-around for the plexus bug. If the plexus patch is applied, the second patch is not needed anymore.
Hide
Permalink
Fabrice Bellingard added a comment - 17/Oct/05 4:49 AM

Well, I'm not sure this bug is fixed... I've just tested the following configuration (2.0-beta-2 has just been released, and which seems to have your patch):

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0-beta-2</version>
<configuration>
<warSourceExcludes>*/lib/.jar</warSourceExcludes>
</configuration>
</plugin>

and all the JARs are still excluded from the packaging.

Looking at the code, #getExcludes (which uses the 'warSourceExcludes' property) is indeed called in AbstractWarMojo#copyResources, but it is also called in WarMojo#performPackaging, which results in excluding all the JARs from the WAR - even the JARs that come from the pom dependencies.

Show
Fabrice Bellingard added a comment - 17/Oct/05 4:49 AM Well, I'm not sure this bug is fixed... I've just tested the following configuration (2.0-beta-2 has just been released, and which seems to have your patch): <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.0-beta-2</version> <configuration> <warSourceExcludes>*/lib/.jar</warSourceExcludes> </configuration> </plugin> and all the JARs are still excluded from the packaging. Looking at the code, #getExcludes (which uses the 'warSourceExcludes' property) is indeed called in AbstractWarMojo#copyResources, but it is also called in WarMojo#performPackaging, which results in excluding all the JARs from the WAR - even the JARs that come from the pom dependencies.
Hide
Permalink
Fabrice Bellingard added a comment - 17/Oct/05 4:53 AM

See my last comment - #getExcludes is used both in #copyResources and #performPackaging.

Show
Fabrice Bellingard added a comment - 17/Oct/05 4:53 AM See my last comment - #getExcludes is used both in #copyResources and #performPackaging.
Hide
Permalink
Edwin Punzalan added a comment - 17/Oct/05 8:19 PM

Fabrice,

I tested if the bug exists first before I go and look at the source. And when I did test the bug (after the submitted fix), warSourceExcludes is working properly for the */lib/.* value. That's when I said the bug seemed fixed already.

Anyway, looking at the source, i see that you are correct that #getExcludes is inside copyResources. But please note that #copyResources is done only on the webapp directory... and lib is not in it. This is the reason why during my tests does not fail.

Also, looking at the m1 source, m1 is also applying the war.src.excludes both to the war file and the resources. So the port from m1 to m2 is still correct.

Btw, I tested again the configuration on 2.0-beta-2 and its working... the archive does not have anything inside lib but the WEB-INF/lib directory outside the archive has them all.

Show
Edwin Punzalan added a comment - 17/Oct/05 8:19 PM Fabrice, I tested if the bug exists first before I go and look at the source. And when I did test the bug (after the submitted fix), warSourceExcludes is working properly for the */lib/.* value. That's when I said the bug seemed fixed already. Anyway, looking at the source, i see that you are correct that #getExcludes is inside copyResources. But please note that #copyResources is done only on the webapp directory... and lib is not in it. This is the reason why during my tests does not fail. Also, looking at the m1 source, m1 is also applying the war.src.excludes both to the war file and the resources. So the port from m1 to m2 is still correct. Btw, I tested again the configuration on 2.0-beta-2 and its working... the archive does not have anything inside lib but the WEB-INF/lib directory outside the archive has them all.
Hide
Permalink
Fabrice Bellingard added a comment - 18/Oct/05 3:39 AM

Hi Edwin,

I'm getting confused for it seems that we don't understand each other: the actual problem is that the final War archive has no JARs in its WEB-INF/lib folder, which is definitely not correct because a WAR must contain the libs it depends on (if not, the web application can't be run, right?).

My use case is the following:
1- I check out a project from CVS: this project has JARs in its WEB-INF/lib folder because developers put them in the SCM. But some of those JARs may be unused (even if not removed from CVS). Only the POM can tell which JARs the project really depends on.
2- I want to build the WAR with "m2 package". In the final WAR archive, I don't want to have the unused JARs, but only the ones referenced in the POM.

  • With m1, when I build my project, the "war.src.excludes" property excludes the JARs that where checked out from CVS, and does not exclude the JARs that are copied from the local repo to be included in the War. And that's exactly what I expect this property to do!
  • But in m2, because #getExcludes is used in #performPackaging, the JARs previously copied from the local repo to be put in the WAR are also excluded from the War! Which I don't want, of course (a WAR archive needs its libs to be able to work properly!). So 'warSourceExcludes' should normally be used only in #copyResources (because it is meant to exclude files from the WAR source), but not in #performPackaging (because at that stage, the MOJO has copied from local repo the JARs corresponding to the dependencies defined in the POM, and I don't want the MOJO to exclude such files which are not sources).
Show
Fabrice Bellingard added a comment - 18/Oct/05 3:39 AM Hi Edwin, I'm getting confused for it seems that we don't understand each other: the actual problem is that the final War archive has no JARs in its WEB-INF/lib folder, which is definitely not correct because a WAR must contain the libs it depends on (if not, the web application can't be run, right?). My use case is the following: 1- I check out a project from CVS: this project has JARs in its WEB-INF/lib folder because developers put them in the SCM. But some of those JARs may be unused (even if not removed from CVS). Only the POM can tell which JARs the project really depends on. 2- I want to build the WAR with "m2 package". In the final WAR archive, I don't want to have the unused JARs, but only the ones referenced in the POM.
  • With m1, when I build my project, the "war.src.excludes" property excludes the JARs that where checked out from CVS, and does not exclude the JARs that are copied from the local repo to be included in the War. And that's exactly what I expect this property to do!
  • But in m2, because #getExcludes is used in #performPackaging, the JARs previously copied from the local repo to be put in the WAR are also excluded from the War! Which I don't want, of course (a WAR archive needs its libs to be able to work properly!). So 'warSourceExcludes' should normally be used only in #copyResources (because it is meant to exclude files from the WAR source), but not in #performPackaging (because at that stage, the MOJO has copied from local repo the JARs corresponding to the dependencies defined in the POM, and I don't want the MOJO to exclude such files which are not sources).
Hide
Permalink
Edwin Punzalan added a comment - 18/Oct/05 4:35 AM

Ok. I get your point and I totally misunderstood you there.

The attached patch will remove the includes/excludes in #performPackaging.

Show
Edwin Punzalan added a comment - 18/Oct/05 4:35 AM Ok. I get your point and I totally misunderstood you there. The attached patch will remove the includes/excludes in #performPackaging.
Hide
Permalink
Fabrice Bellingard added a comment - 08/Nov/05 10:20 AM

It seems that the patch hasn't been applied yet... When will the war plugin be released with these bug fixes? It is still in beta version while most other plugins have been finalised with Maven 2.0.

Show
Fabrice Bellingard added a comment - 08/Nov/05 10:20 AM It seems that the patch hasn't been applied yet... When will the war plugin be released with these bug fixes? It is still in beta version while most other plugins have been finalised with Maven 2.0.
Hide
Permalink
Niklas Ekman added a comment - 11/Nov/05 8:59 AM

I read the documentation on the war plugin (http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html) and it should be possible to send in a comma separated list of excludes. I looked into the source but couldn't find anything that can make this work, so I think this is bug. The code below depends on the commons StringUtils helper class.

protected String[] getExcludes()
{
List excludeList = new ArrayList( FileUtils.getDefaultExcludesAsList() );
if ( warSourceExcludes != null && !"".equals( warSourceExcludes ) )
{
String[] excludes = StringUtils.split(warSourceExcludes, ",");
for (int i = 0; i < excludes.length; i++)

{ String exclude = excludes[i]; excludeList.add( exclude ); }

}

// if webXML is specified, omit the one in the source directory
if ( getWebXml() != null && !"".equals( getWebXml() ) )

{ excludeList.add( "**/" + WEB_INF + "/web.xml" ); }

return (String[]) excludeList.toArray( EMPTY_STRING_ARRAY );
}

I haven't written a testcase or even tested the code, but I want to verify if I've understood the function right.

Show
Niklas Ekman added a comment - 11/Nov/05 8:59 AM I read the documentation on the war plugin (http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html) and it should be possible to send in a comma separated list of excludes. I looked into the source but couldn't find anything that can make this work, so I think this is bug. The code below depends on the commons StringUtils helper class. protected String[] getExcludes() { List excludeList = new ArrayList( FileUtils.getDefaultExcludesAsList() ); if ( warSourceExcludes != null && !"".equals( warSourceExcludes ) ) { String[] excludes = StringUtils.split(warSourceExcludes, ","); for (int i = 0; i < excludes.length; i++) { String exclude = excludes[i]; excludeList.add( exclude ); } } // if webXML is specified, omit the one in the source directory if ( getWebXml() != null && !"".equals( getWebXml() ) ) { excludeList.add( "**/" + WEB_INF + "/web.xml" ); } return (String[]) excludeList.toArray( EMPTY_STRING_ARRAY ); } I haven't written a testcase or even tested the code, but I want to verify if I've understood the function right.
Hide
Permalink
Edwin Punzalan added a comment - 20/Nov/05 7:39 PM

Patch applied.

Niklas Ekman: more info about the plugin can be found here: http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html

Show
Edwin Punzalan added a comment - 20/Nov/05 7:39 PM Patch applied. Niklas Ekman: more info about the plugin can be found here: http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html
Hide
Permalink
Dimitry Voytenko added a comment - 09/May/06 6:31 PM

Has this been released yet? Which version?

Show
Dimitry Voytenko added a comment - 09/May/06 6:31 PM Has this been released yet? Which version?
Hide
Permalink
Edwin Punzalan added a comment - 09/May/06 10:10 PM

Unfortunately, not yet. There are efforts in testing the war plugin prior to release. And I think the release will be soon.

Show
Edwin Punzalan added a comment - 09/May/06 10:10 PM Unfortunately, not yet. There are efforts in testing the war plugin prior to release. And I think the release will be soon.
Hide
Permalink
Daniel Uribe added a comment - 27/Mar/08 4:38 PM

I see that there seem to be some changes in the trunk that could be related to this issue, is it planned for the next release of the plugin? It seems that the 2.1 alpha 1 doesn't have this fix yet, but since it's in the trunk, the next alpha or beta might. Is there any timeframe for that release?

Show
Daniel Uribe added a comment - 27/Mar/08 4:38 PM I see that there seem to be some changes in the trunk that could be related to this issue, is it planned for the next release of the plugin? It seems that the 2.1 alpha 1 doesn't have this fix yet, but since it's in the trunk, the next alpha or beta might. Is there any timeframe for that release?

People

  • Assignee:
    Edwin Punzalan
    Reporter:
    Fabrice Bellingard
Vote (0)
Watch (2)

Dates

  • Created:
    28/Sep/05 7:22 AM
    Updated:
    27/Mar/08 4:38 PM
    Resolved:
    23/Dec/05 10:15 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.