Maven WAR Plugin
  1. Maven WAR Plugin
  2. MWAR-81

Request enhancement to pattern matching for packagingIncludes/packagingExcludes functionality (regular expressions?)

    Details

    • Type: Wish Wish
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2
    • Component/s: None
    • Labels:
      None
    • Environment:
      n/a
    • Number of attachments :
      2

      Description

      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.

        Issue Links

          Activity

          Hide
          Dennis Lundberg added a comment -

          Since the warSourceIncludes/warSourceExcludes parameters no longer works on jars - only on source files, this issue is now about packagingIncludes/packagingExcludes.

          Show
          Dennis Lundberg added a comment - Since the warSourceIncludes/warSourceExcludes parameters no longer works on jars - only on source files, this issue is now about packagingIncludes/packagingExcludes.
          Hide
          Ivan Bondarenko added a comment -

          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.

          Show
          Ivan Bondarenko added a comment - 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.
          Hide
          Vincent Massol added a comment -

          I need this too. My use case:

          I want to exclude log4j-<version>.jar but keep the log4j-over-slf4j-<version>.jar...

          Show
          Vincent Massol added a comment - I need this too. My use case: I want to exclude log4j-<version>.jar but keep the log4j-over-slf4j-<version>.jar...
          Hide
          Nicolas Marcotte added a comment - - edited

          I have attached a patch named maven-war-plugin-2.1.1-NM that adds the following feature to this plugin:
          the mutually exclusive (only if set to true) tags:
          <regexInPackagingSelectionAllowed>true</regexInPackagingSelectionAllowed>
          <negationInPackgingAllowed>true</negationInPackgingAllowed>
          that modify the way the values of packagingIncludes and packagingExcludes are handled.

          The tag regexInPackagingSelectionAllowed can be viewed as replacing SelectorUtils.match(pattern,testedString) by Pattern.compile(pattern).matcher(testedString).matches() for the interpretation of packagingIncludes/Excludes

          the tag <negationInPackgingAllowed> permit the usage of the ! operator in the packagingIncludes/Excludes. Let me give you an example to illustrate how it works;

          The jar in WEB-INF/lib before filetering:
          cumulostratus-1.1.jar (declared as optional pulled by stratus)
          stratus-1.1.CITRUS.jar (pulled stratus as it is a dependancies)

          <artifactId>maven-war-plugin</artifactId>
          <version>2.1.1-NM</version>
          <configuration >                    
            <negationInPackagingSelectionAllowed>true</negationInPackagingSelectionAllowed>
            <packagingExcludes>**/*.jar,!**/*.CITRUS.jar</packagingExcludes>
          </configuration>
          

          The jar in WEB-INF/lib after filtering:
          stratus-1.1.CITRUS.jar

          this patched version is actually running my integration build code, I would like feedback upon it

          the patch file name is maven-war-plugin-2.1.1-NM.patch

          Please tell me how to proceed to have it reviewed and integrated into your trunk if it solved others people needs.

          Ideally that patch would be somewhere in plexus but i only needed it in the war with taglibs that must be present in WEB-INF/lib and I am a partisan of the minimal impacted dependencies approach to patch outside of major version.

          Show
          Nicolas Marcotte added a comment - - edited I have attached a patch named maven-war-plugin-2.1.1-NM that adds the following feature to this plugin: the mutually exclusive (only if set to true) tags: <regexInPackagingSelectionAllowed>true</regexInPackagingSelectionAllowed> <negationInPackgingAllowed>true</negationInPackgingAllowed> that modify the way the values of packagingIncludes and packagingExcludes are handled. The tag regexInPackagingSelectionAllowed can be viewed as replacing SelectorUtils.match(pattern,testedString) by Pattern.compile(pattern).matcher(testedString).matches() for the interpretation of packagingIncludes/Excludes the tag <negationInPackgingAllowed> permit the usage of the ! operator in the packagingIncludes/Excludes. Let me give you an example to illustrate how it works; The jar in WEB-INF/lib before filetering: cumulostratus-1.1.jar (declared as optional pulled by stratus) stratus-1.1.CITRUS.jar (pulled stratus as it is a dependancies) <artifactId> maven-war-plugin </artifactId> <version> 2.1.1-NM </version> <configuration > <negationInPackagingSelectionAllowed> true </negationInPackagingSelectionAllowed> <packagingExcludes> **/*.jar,!**/*.CITRUS.jar </packagingExcludes> </configuration> The jar in WEB-INF/lib after filtering: stratus-1.1.CITRUS.jar this patched version is actually running my integration build code, I would like feedback upon it the patch file name is maven-war-plugin-2.1.1-NM.patch Please tell me how to proceed to have it reviewed and integrated into your trunk if it solved others people needs. Ideally that patch would be somewhere in plexus but i only needed it in the war with taglibs that must be present in WEB-INF/lib and I am a partisan of the minimal impacted dependencies approach to patch outside of major version.
          Hide
          Nicolas Marcotte added a comment - - edited

          @Vincent Massol I don't know if will it help but with my patch you are supposed to be able to express it that way :

          <artifactId>maven-war-plugin</artifactId>
          <version>2.1.1-NM</version>
          <configuration >                    
            <negationInPackagingSelectionAllowed>true</negationInPackagingSelectionAllowed>
            <packagingExcludes>!**/log4j-*.jar,**/log4j-over-slf4j-*.jar</packagingExcludes>
          </configuration>
          

          If you still need it and you want have try it let's me know, and if you need help I will probably be available tomorrow around 18:00UTC.

          edit: I read it back ward sorry about the multiple post

          Show
          Nicolas Marcotte added a comment - - edited @Vincent Massol I don't know if will it help but with my patch you are supposed to be able to express it that way : <artifactId> maven-war-plugin </artifactId> <version> 2.1.1-NM </version> <configuration > <negationInPackagingSelectionAllowed> true </negationInPackagingSelectionAllowed> <packagingExcludes> !**/log4j-*.jar,**/log4j-over-slf4j-*.jar </packagingExcludes> </configuration> If you still need it and you want have try it let's me know, and if you need help I will probably be available tomorrow around 18:00UTC. edit: I read it back ward sorry about the multiple post
          Hide
          Vincent Massol added a comment -

          Thanks Nicolas.

          I had found a very bad workaround (but working):

                    </webResources>
                    <!-- - Make sure we exclude JCL and LOGJ4 since we want all logging to go through SLF4J
                         - Exclude xwiki-platform-olcore because it's included in xwiki-platform-legacy-oldcore
                         - Excluded to prevent conflict in the patched version of Rhino used by yuicompressor used for JSX.
                           See http://jira.xwiki.org/jira/browse/XWIKI-6151 for more details.
          
                         Note: We use ?????? because we need to exclude log4j-1.2.16 but keep log4j-over-slf4j-1.6.1.jar
                               See http://jira.codehaus.org/browse/MWAR-81
                    -->
                    <packagingExcludes>
                      WEB-INF/lib/xwiki-platform-oldcore-*.jar,WEB-INF/lib/batik-js-*.jar,WEB-INF/lib/commons-logging-*.jar,WEB-INF/lib/log4j-??????.jar
                    </packagingExcludes>
          
          Show
          Vincent Massol added a comment - Thanks Nicolas. I had found a very bad workaround (but working): </webResources> <!-- - Make sure we exclude JCL and LOGJ4 since we want all logging to go through SLF4J - Exclude xwiki-platform-olcore because it's included in xwiki-platform-legacy-oldcore - Excluded to prevent conflict in the patched version of Rhino used by yuicompressor used for JSX. See http: //jira.xwiki.org/jira/browse/XWIKI-6151 for more details. Note: We use ?????? because we need to exclude log4j-1.2.16 but keep log4j-over-slf4j-1.6.1.jar See http: //jira.codehaus.org/browse/MWAR-81 --> <packagingExcludes> WEB-INF/lib/xwiki-platform-oldcore-*.jar,WEB-INF/lib/batik-js-*.jar,WEB-INF/lib/commons-logging-*.jar,WEB-INF/lib/log4j-??????.jar </packagingExcludes>
          Hide
          Nicolas Marcotte added a comment -

          That the workaround that motivating myself to write that patch since I moved from atrocities like that:

          
          <packagingExcludes combine.self="override">
          **/A*.jar,**/B*.jar,**/C*.jar,**/M*.jar,**/O*.jar,
          **/*P*.jar,**/R*.jar,**/a*.jar,**/b*.jar,**/c*.jar,
          **/d*.jar,**/f*.jar,**/k*.jar,**/i*.jar,**/j*.jar,
          **/l*.jar,**/m*.jar,**/r*.jar,**/sa*.jar,**/se*.jar,
          **/v*.jar,**/x*.jar,
          <!--  to exclude struts patched for RAD but not the lib's patched for our prod environment that's ends with .SIRUS-->
          **/Struts-Layout.jar,**/struts-menu.jar,**/struts.jar 
          </packagingExcludes>
          

          to

          <packagingExcludes>**/*.jar,!**/*.SIRUS.jar</packagingExcludes>        
          
          Show
          Nicolas Marcotte added a comment - That the workaround that motivating myself to write that patch since I moved from atrocities like that: <packagingExcludes combine.self= "override" > **/A*.jar,**/B*.jar,**/C*.jar,**/M*.jar,**/O*.jar, **/*P*.jar,**/R*.jar,**/a*.jar,**/b*.jar,**/c*.jar, **/d*.jar,**/f*.jar,**/k*.jar,**/i*.jar,**/j*.jar, **/l*.jar,**/m*.jar,**/r*.jar,**/sa*.jar,**/se*.jar, **/v*.jar,**/x*.jar, <!-- to exclude struts patched for RAD but not the lib's patched for our prod environment that's ends with .SIRUS--> **/Struts-Layout.jar,**/struts-menu.jar,**/struts.jar </packagingExcludes> to <packagingExcludes> **/*.jar,!**/*.SIRUS.jar </packagingExcludes>
          Hide
          Dennis Lundberg added a comment -

          I like this feature, but I think that the configuration should be done differently.

          The approach in the patch isn't open to extension by other potential implementations of matchers. May I suggest a single String parameter containing the name for the matching strategy implementation. We could have packagingMatchingStrategy=standard or packagingMatchingStrategy=normal for the current behavior, then packagingMatchingStrategy=regexp and packagingMatchingStrategy=negatableRegexp for the new features.

          Show
          Dennis Lundberg added a comment - I like this feature, but I think that the configuration should be done differently. The approach in the patch isn't open to extension by other potential implementations of matchers. May I suggest a single String parameter containing the name for the matching strategy implementation. We could have packagingMatchingStrategy=standard or packagingMatchingStrategy=normal for the current behavior, then packagingMatchingStrategy=regexp and packagingMatchingStrategy=negatableRegexp for the new features.
          Hide
          Nicolas Marcotte added a comment - - edited

          I will implements your suggestion later this week, or in the beginning the next week, thank you for the feedback !!!

          By the way the negation is not currently applicable on the regex so the options will be standard,negatableStandard and regex

          I did not submit negatable RegExes as it introduce a lot's of edges cases, and I do not want to figure them all .... Example: how do you handle that an exclusion expression like that :

           <packagingMatchingStrategy>negatableRegexp</packagingMatchingStrategy>
           <packagingExclude>!(?sm)(?!struts)(\w[0-9\-])+.*\.jar,.*\.jar</packagingExclude>
          
          Show
          Nicolas Marcotte added a comment - - edited I will implements your suggestion later this week, or in the beginning the next week, thank you for the feedback !!! By the way the negation is not currently applicable on the regex so the options will be standard,negatableStandard and regex I did not submit negatable RegExes as it introduce a lot's of edges cases, and I do not want to figure them all .... Example: how do you handle that an exclusion expression like that : <packagingMatchingStrategy> negatableRegexp </packagingMatchingStrategy> <packagingExclude> !(?sm)(?!struts)(\w[0-9\-])+.*\.jar,.*\.jar </packagingExclude>
          Hide
          Jörg Schaible added a comment -

          Have a look at:
          http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html

          IIRC, this include/exclude stuff is provided by a plexus component and it might already work

          Show
          Jörg Schaible added a comment - Have a look at: http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html IIRC, this include/exclude stuff is provided by a plexus component and it might already work
          Hide
          Nicolas Marcotte added a comment -

          @Joerg Schaible, I will use the plexus component under the hood, and document it in my next patch version. Thank you

          Show
          Nicolas Marcotte added a comment - @Joerg Schaible, I will use the plexus component under the hood, and document it in my next patch version. Thank you
          Hide
          Jörg Schaible added a comment - - edited

          This is what I mean: You don't have to patch anything, it already works (at least tested with 2.1.1)! I can use this without any problems to exclude files with log4j in their names:

          <packagingExcludes>%regex[.*log4j.*]</packagingExcludes>
          
          Show
          Jörg Schaible added a comment - - edited This is what I mean: You don't have to patch anything, it already works (at least tested with 2.1.1)! I can use this without any problems to exclude files with log4j in their names: <packagingExcludes>%regex[.*log4j.*]</packagingExcludes>
          Hide
          Nicolas Marcotte added a comment -

          I was about to comment that my patch is useless and I should update the documentation only !

          Show
          Nicolas Marcotte added a comment - I was about to comment that my patch is useless and I should update the documentation only !
          Hide
          Vincent Massol added a comment -

          Thanks a lot Joerg! That was very useful. I was able to write:

                    <!-- - Exclude JCL and LOG4J since we want all logging to go through SLF4J. Note that we're excluding
                           log4j-<version>.jar but keeping log4j-over-slf4j-<version>.jar
                         - Exclude xwiki-platform-olcore because it's already included in xwiki-platform-legacy-oldcore
                         - Exclude batik-js to prevent conflict with the patched version of Rhino used by yuicompressor used for
                           JSX. See http://jira.xwiki.org/jira/browse/XWIKI-6151 for more details.
                    -->
                    <packagingExcludes>
                      WEB-INF/lib/xwiki-platform-oldcore-*.jar,
                      WEB-INF/lib/batik-js-*.jar,
                      WEB-INF/lib/commons-logging-*.jar,
                      %regex[WEB-INF/lib/log4j-(?!over-slf4j).*.jar]
                    </packagingExcludes>
          

          Which is much nicer than what I had before

          Show
          Vincent Massol added a comment - Thanks a lot Joerg! That was very useful. I was able to write: <!-- - Exclude JCL and LOG4J since we want all logging to go through SLF4J. Note that we're excluding log4j-<version>.jar but keeping log4j-over-slf4j-<version>.jar - Exclude xwiki-platform-olcore because it's already included in xwiki-platform-legacy-oldcore - Exclude batik-js to prevent conflict with the patched version of Rhino used by yuicompressor used for JSX. See http://jira.xwiki.org/jira/browse/XWIKI-6151 for more details. --> <packagingExcludes> WEB-INF/lib/xwiki-platform-oldcore-*.jar, WEB-INF/lib/batik-js-*.jar, WEB-INF/lib/commons-logging-*.jar, %regex[WEB-INF/lib/log4j-(?!over-slf4j).*.jar] </packagingExcludes> Which is much nicer than what I had before
          Hide
          Nicolas Marcotte added a comment -

          documentations changes and a new Junit test named testSimpleWarPackagingExcludeWithIncludesRegEx

          Show
          Nicolas Marcotte added a comment - documentations changes and a new Junit test named testSimpleWarPackagingExcludeWithIncludesRegEx
          Hide
          Nicolas Marcotte added a comment -

          I have added a Junit test to reflect this capability and updated the documentation, I hope that this will make it in the next release, as this is too much of an useful feature to remain undocumented and untested! Thank you again Joerg Schaible

          Show
          Nicolas Marcotte added a comment - I have added a Junit test to reflect this capability and updated the documentation, I hope that this will make it in the next release, as this is too much of an useful feature to remain undocumented and untested! Thank you again Joerg Schaible
          Hide
          Dennis Lundberg added a comment -

          Documentation patch added in r1203638, thanks!

          Show
          Dennis Lundberg added a comment - Documentation patch added in r1203638, thanks!
          Hide
          Dennis Lundberg added a comment -

          Added documentation about an undocumented feature that solves the problem.

          Show
          Dennis Lundberg added a comment - Added documentation about an undocumented feature that solves the problem.

            People

            • Assignee:
              Dennis Lundberg
              Reporter:
              Bryan Loofbourrow
            • Votes:
              15 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: