You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For every Open Source Software (OSS) we use, our customer wants an extensive license report.
This plugin is almost perfect for that, except:
The aggregate-third-party goal writes (although formatable) just text-files
The aggregate-download-licenses write a nice xml, but with even less information - the project/plugin name is missing.
But the more important thing: Our customer needs, also with copyleft licensed OSS, the copyright notices for each software. Plus the plugin vendor and similar stuff. Many of these information aren't provided or updated in the plugins pom.xml's while their JARs MANIFEST.MF files are clean, informative and maintained. The JARs can contain:
** The MANIFEST.MF with Bundle vendor, implementer, bundle license
** Multiple license text files for each license, directly in the JAR, no need to download that. So I'm looking for a LICENSE.txt file and all text files having a SPDX license name.
** Also NOTICE.txt files which contain often all relevant copyright information.
So I forked an extension which tries to fetch as much information as it can get from the JAR file and writes that with some pom.xml information, which was previously ignored, to the license.xml file.
This is of course optional, obviously the previous solution was good enough for most people so it's "off" by default (parameter is "extendedInfo", goal is "license:aggregate-download-licenses").
Since the next task would be: "And now write an excessive amount of XSLT declarations to create a CSV report to import that into Excel, were you would have to pay extra attention so Excel doesn't convert all version numbers to dates, fit all columns, freeze header columns and rows, group them, etc.".
I skipped that part and added an option to write the result into a properly formatted Excel file (parameter is "writeExcelFile").
And I still need the XML, since I need to parse it periodically and persist it into a database.
My question
Before I do a pull request and clean up the code, plus writing integration and unit tests, I would like to know if people are OK with that? Or are my needs to special? Or just some minor problems I could fix before submitting?
For every Open Source Software (OSS) we use, our customer wants an extensive license report.
This plugin is almost perfect for that, except:
** The MANIFEST.MF with Bundle vendor, implementer, bundle license
** Multiple license text files for each license, directly in the JAR, no need to download that. So I'm looking for a LICENSE.txt file and all text files having a SPDX license name.
** Also NOTICE.txt files which contain often all relevant copyright information.
So I forked an extension which tries to fetch as much information as it can get from the JAR file and writes that with some pom.xml information, which was previously ignored, to the license.xml file.
This is of course optional, obviously the previous solution was good enough for most people so it's "off" by default (parameter is "extendedInfo", goal is "license:aggregate-download-licenses").
Since the next task would be:
"And now write an excessive amount of XSLT declarations to create a CSV report to import that into Excel, were you would have to pay extra attention so Excel doesn't convert all version numbers to dates, fit all columns, freeze header columns and rows, group them, etc.".
I skipped that part and added an option to write the result into a properly formatted Excel file (parameter is "writeExcelFile").
And I still need the XML, since I need to parse it periodically and persist it into a database.
My question
Before I do a pull request and clean up the code, plus writing integration and unit tests, I would like to know if people are OK with that? Or are my needs to special? Or just some minor problems I could fix before submitting?
The Fork
https://github.com/Master-Code-Programmer/license-maven-plugin
The text was updated successfully, but these errors were encountered: