[jira] [Commented] (MSHADE-443) Fix problems with shadeSourcesContent

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MSHADE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717954#comment-17717954 ] 

ASF GitHub Bot commented on MSHADE-443:
---------------------------------------

kriegaex opened a new pull request, #185:
URL: https://github.com/apache/maven-shade-plugin/pull/185

   Due to MSHADE-396, some cases which were made to work in MSHADE-252, started breaking. This change fixes them. See [MSHADE-443](https://issues.apache.org/jira/browse/MSHADE-443) for more details.
   
   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
    - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MSHADE) filed 
          for the change (usually before you start working on it).  Trivial changes like typos do not 
          require a JIRA issue.  Your pull request should address just this issue, without 
          pulling in other changes.
    - [x] Each commit in the pull request should have a meaningful subject line and body.
    - [x] Format the pull request title like `[MSHADE-XXX] - Fixes bug in ApproximateQuantiles`,
          where you replace `MSHADE-XXX` with the appropriate JIRA issue. Best practice
          is to use the JIRA issue title in the pull request title and in the first line of the 
          commit message.
    - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
    - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will 
          be performed on your pull request automatically.
    - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`).
   
   If your pull request is about ~20 lines of code you don't need to sign an
   [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
   please ask on the developers list.
   
   To make clear that you license your contribution under 
   the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   you have to acknowledge this by using the following check-box.
   
    - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
   
    - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
   




> Fix problems with shadeSourcesContent
> -------------------------------------
>
>                 Key: MSHADE-443
>                 URL: https://issues.apache.org/jira/browse/MSHADE-443
>             Project: Maven Shade Plugin
>          Issue Type: Bug
>    Affects Versions: 3.3.0, 3.4.1
>            Reporter: Alexander Kriegisch
>            Priority: Major
>
> *History:* Initially, I improved {{shadeSourcesContent}} in MSHADE-252. In MSHADE-396, [~Reamer] suggested some improvements, which I picked up and improved. Alas, I did not improve his PR enough, but it went unnoticed, because my other project was until today still using a private release of Maven Shade, which contained some of my other fixes which I was at the time waiting to be merged. Now they have been merged, so I switched to 3.4.1, only to notice that now some code which was shaded correctly with MSHADE-252, broke due to MSHADE-396.
> Source code shading being an imperfect, heuristic search & replace process, there will never be a perfect solution, unless we create full parsers for different JVM languages, Java being but one of them. Anyway, for one of my Java projects which creates Javadoc for relocated sources, I noticed several shortcomings and improved source shading for them.
> Fully qualified names are now matched correctly 
> * after keywords {{extends}}, {{implements}} and {{throws}}, in addition to the keywords already matched previously,
> * after any of opening curly brace, opening parenthesis, comma, equals, semicolon, closing curly brace, closing multi-line comment, if whitespace follows (without whitespace there was no problem).
> All of the above were problems I met in real life when shading and relocating packages from Eclipse JDT Core for use in AspectJ.
> I also adjusted the existing {{SimpleRelocatorTest}} in order to test some of these cases at least in smoke test fashion. All other tests are still green, so I can reasonably hope not to have broken anything in a serious way. Like I said, souce relocation is a best-effort thing anyway, nobody should rely on it 100%.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)