Return-Path: Delivered-To: apmail-maven-issues-archive@minotaur.apache.org Received: (qmail 36493 invoked from network); 26 May 2010 08:18:43 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 26 May 2010 08:18:43 -0000 Received: (qmail 74256 invoked by uid 500); 26 May 2010 08:18:43 -0000 Delivered-To: apmail-maven-issues-archive@maven.apache.org Received: (qmail 73979 invoked by uid 500); 26 May 2010 08:18:40 -0000 Mailing-List: contact issues-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@maven.apache.org Delivered-To: mailing list issues@maven.apache.org Received: (qmail 73971 invoked by uid 99); 26 May 2010 08:18:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 May 2010 08:18:39 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [63.246.2.115] (HELO codehaus01.managed.contegix.com) (63.246.2.115) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 May 2010 08:18:33 +0000 Received: from codehaus01.managed.contegix.com (localhost.localdomain [127.0.0.1]) by codehaus01.managed.contegix.com (Postfix) with ESMTP id AEFB915F0005 for ; Wed, 26 May 2010 03:18:12 -0500 (CDT) Date: Wed, 26 May 2010 03:18:12 -0500 (CDT) From: "Ivan (JIRA)" To: issues@maven.apache.org Message-ID: <30649970.32156.1274861892419.JavaMail.haus-jira@codehaus01.managed.contegix.com> In-Reply-To: <70870976.1161704019978.JavaMail.haus-jira@codehaus01.managed.contegix.com> Subject: [jira] Commented: (MWAR-81) Request enhancement to pattern matching for warSourceIncludes/warSourceExcludes functionality (regular expressions?) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 4e90ceb663894a42f12c0e28abbab431 X-Virus-Checked: Checked by ClamAV on apache.org [ http://jira.codehaus.org/browse/MWAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=222701#action_222701 ] Ivan commented on MWAR-81: -------------------------- We are also very interested in resolving this issue. We have some jars which should be of "system-provided" scope (1. have systemPath property, because these jars are legacy and out of any repository; 2. not be included into war, because we have several instances of this war and jars are using native code, so only one instance of jar can be loaded, which should be in container's lib directory). packagingExcludes seemed to be the solution we need, but we cannot force it to work properly. Actually even specifying full name doesn't work. > Request enhancement to pattern matching for warSourceIncludes/warSourceExcludes functionality (regular expressions?) > -------------------------------------------------------------------------------------------------------------------- > > Key: MWAR-81 > URL: http://jira.codehaus.org/browse/MWAR-81 > Project: Maven 2.x WAR Plugin > Issue Type: Wish > Environment: n/a > Reporter: Bryan Loofbourrow > Priority: Minor > > The Maven War Plugin currently permits choosing what files will wind up in the .war. It does this via two parameters, warSourceIncludes, and warSourceExcludes. The rule appears to be that the includes are computed, and a list of matches made, then that list is run against the excludes, and any matches taken out of the include list. > The only wildcards that appear to be supported are *, **, and ?. > That doesn't work well if you are packaging wars in ears, and therefore want to exclude all jars from the war, except for one or two that have to be in the war in order to run properly. "Exclude all but foo.jar and bar.jar" just doesn't translate well to "here's your simple include template, here's your simple exclude template" representation, at least with current wildcards. > So this is a wish specifically for something to address the "exclude all but x, y, and z" need for war source includes/excludes, and a suggestion that it might be best to deprecate the warSourceIncludes/warSourceExcludes approach in favor of a single parameter that supports regular expressions instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira