Added advanced data formatting and sorting

[Master-Code-Programmer]

Hi, I made a bigger update because I was missing some clarity and readability in the license reports. With big projects and an enormous amount of (transitive) dependencies I got lost, so I added these settings.
Feel free to comment on whatever changes you need, to accept this pull-request.

The essential changes are:

• I added a DataFormatting option to AbstractDownloadLicensesMojo to format the data. The specific settings are:
  • orderBy, to order / sort the output by 4 possible values:
    • Dependency Name
    • Plugin ID
    • License Match (OK license, Problematic license, Forbidden license, Unknown license)
    • License Name
      I marked the option sortByGroupIdAndArtifactId in AbstractDownloadLicensesMojo therefore as deprecated.
  • problematicLicenses, to list problematic licenses, which get highlighted in a special color in the XML or ODS report. As also a different sort order when using orderBy License-Match
  • okLicenses, to list licenses which are explicitly allowed. They get highlighted in a special color in the XML or ODS report. As also a different sort order when using orderBy License-Match
  • Forbidden licenses just reuse the already existing excludedLicenses.
  • matchedLicensesHaveBorder. If licenses found in excludedLicenses, problematicLicenses, okLicenses or where highlightUnknownLicenses is used, have a visible border. The border makes license types better visible at a glance, but when quickly scrolling through a long list, it makes licenses look as if they were the only ones belonging to a dependency if it has multiple licenses.
  • highlightUnknownLicenses. If all unknown licenses should be highlighted. Unknown means: There is no entry for a license in excludedLicenses, problematicLicenses, okLicenses.
  • skipDevelopers just skip the mentioning of developers in the license reports. They are most likely irrelevant for the license report, but are the main reason one dependency entry can get far to many lines. Which makes the report just much harder to read and grasp.
  • Tests for all 4 sortings are in aggregate-download-licenses-sort-by-dependencyName, aggregate-download-licenses-sort-by-licenseMatch, aggregate-download-licenses-sort-by-licenseName and aggregate-download-licenses-sort-by-pluginId.
    Example pom.xml:

  <dataFormatting>
       <orderBy>licenseMatch</orderBy>
       <problematicLicenses>
          <problematicLicense>EPL 2.0</problematicLicense>
          <problematicLicense>MIT License</problematicLicense>
        </problematicLicenses>
        <okLicenses>
          <okLicense>Apache License, Version 2.0</okLicense>
        </okLicenses>
        <matchedLicensesHaveBorder>true</matchedLicensesHaveBorder>
        <highlightUnknownLicenses>true</highlightUnknownLicenses>
        <skipDevelopers>true</skipDevelopers>
  </dataFormatting>

• LicenseDownloader now sends a User-Agent, so license downloads from gnu.org can become possible. Otherwise it sends an irritating and misleading error: "429 Too many requests". And "gnu.org" is an extremely often used license hoster.
• Bug-Fix: Not all dependencies must be JARs. This should be rarely the case, but it happens. So that is taken into account when extracting extended dependency info, and Non-JARs are skipped and therefore don't throw an exception.
• I added the blank-space-filtering I use for license name merges also to AbstractAddThirdPartyMojos includedLicenses and excludedLicenses, by adding it to StringToList. So you can not only write (the old way):
  <includedLicenses>licenseA|licenseB</includedLicenses>, but also:

  <includedLicenses>licenseA
    |licenseB
    |licenseC
  </includedLicenses>

  I did this not only for readability, but also since some aggressive XML-Formatters enforce the latter format if the lines get too long anyway, and expect the parsers to handle this.
• I added, as JavaDoc, to AbstractDownloadLicensesMojos licenseMerges all mainly used license-name variations. This is always a huge waste of time, if you set up a new project from scratch and need to find out again all standard name-variations of licenses. I don't want to add that as a default, since I consider that to be maybe too much "magic", and it should be very transparent and intentionally decided which license names mean really the same. So this works as an extremely convenient time-saving suggestion.

[Master-Code-Programmer]

@slawekjaranowski I would've donated, like a "beer", to you, but w/o a credit-card I found no way. You could add a Patreon account.

[slawekjaranowski]

only used in readme ....

[Master-Code-Programmer]

First: Sorry for the delay, I hope I got now much more time to get this PR ready.

The script is there to make the XML files easily readable, otherwise it's not obvious how the XSLT could be used to get a clear view of the sorting in the template XML files.

I needed some time to find it out, and found it also hard to read the raw XML files, to check if the generated XML files were actually correct. I don't want to test against incorrect data.
Here is an example for the Plugin-ID sorting, when transformed by the XSLT and hosted by the python mini-webserver:

If xsltproc is installed, it's used to generate HTML websites, where the JavaScript works, so a quick Column sorting can be done. It's also an alternative if the python mini-webserver doesn't work.

And every time the sorting gets updated, new test-files to check against must be generated. So, this makes it much easier to make that correct.

[slawekjaranowski]

why so such complicated method ....
why not use groovy xmlslurper - https://groovy-lang.org/processing-xml.html

[Master-Code-Programmer]

Thanks, that is an interesting solution, the code is now much more compact. I pushed that.
Although: I researched the topic and found out that for my task I should use the "XML Parser", since I need to read always the whole XML document anyway.