-
-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
license policy enforcement with maven project implementation. #207
license policy enforcement with maven project implementation. #207
Conversation
Wow! Thanks a lot! |
Hey @mathieucarbou , let me know if I can ease your review in any way. Happy to schedule a hangout if you want a walkthrough. |
Hello, Thanks but not necessary at the moment: the delay is caused because after 20 yeas in Canada we are relocating in France with the whole family and the months of May, June and July are crazy because of everything an international move implies during Covid. Sadly I don't have any good solution to propose to speed up because I am the only one actively working on the project (and who could review). If you need something in Maven central fast tough, what could be done is a feature branch from where we release a beta, like |
No need for a release (but thanks for the offer!), I just didn't want to forget about this... context switching after a month+ is a little harder. I hope your move goes smoothly and you can enjoy a nice bottle of the local vintage before jumping back into this project ;) |
Ahah!! Thanks a lot! |
@rremer : I have merged - would it be possible for you to add a little doc section in the |
Thanks @mathieucarbou ! Two PRs for you: |
FYI @mathieucarbou I've been using 4.2.rc1 at my company since the day after you released it, and have found no regressions in our previous enforcement. A few things have come up regarding the new license enforcement feature, which I'd like to document here for posterity. Maybe some of this is relevant for a FAQ or elsewhere.
Actually no. I have a test for this specific case, and double checked the maven model reference which confirms that multiple licenses declared in your pom is supposed to imply a choice as to which license you would like to use. This seems to be reflected in the wild as well, where I've seen jars released under multiple licenses with a combinatory name, like "CDDL + GPLv2 with classpath exception" for javax.annotation-api
This is true, and it's actually somewhat worse than that due to inconsistencies in poms declaring url or not. As an aggregious example, the following all refer to the same license but is required on my team to allow Apache 2.0: <dependencyPolicy>
<type>LICENSE_NAME</type>
<rule>APPROVE</rule>
<value>Apache Software License - Version 2.0</value>
</dependencyPolicy>
<dependencyPolicy>
<type>LICENSE_NAME</type>
<rule>APPROVE</rule>
<value>Apache License, Version 2.0</value>
</dependencyPolicy>
<dependencyPolicy>
<type>LICENSE_URL</type>
<rule>APPROVE</rule>
<value>http://www.apache.org/licenses/LICENSE-2.0.html</value>
</dependencyPolicy>
<dependencyPolicy>
<type>LICENSE_URL</type>
<rule>APPROVE</rule>
<value>http://www.apache.org/licenses/LICENSE-2.0.txt</value>
</dependencyPolicy>
<dependencyPolicy>
<type>LICENSE_NAME</type>
<rule>APPROVE</rule>
<value>The Apache Software License, Version 2.0</value>
</dependencyPolicy>
<dependencyPolicy>
<type>LICENSE_URL</type>
<rule>APPROVE</rule>
<value>https://www.apache.org/licenses/LICENSE-2.0.txt</value>
</dependencyPolicy> I'll muse on this. I don't think I want to add regex capability, that could weaken enforcement due to bad regex. That said, loosening the URL specifically on protocol I'd be cool with (these are literal URL objects, so stripping protocol is free and wouldn't weaken enforcement imo). The other thought I had is more robust, but more complicated, which is to:
|
Thanks! This is all good news! I was waiting some weeks before doing a final release so I think I'll be able to do that in November. Feel free to add a section in the readme or an isolated mardown faq file perhaps, I will merge. The doc is now generated directly from main automatically with a GitHub action. |
Sorry for the massive PR, the complexity of #203 eluded me and I just kept coding, should have circled back a few times with you first @mathieucarbou .
Some overview:
check
goal, however I've setup my integration tests and primary classes to support areport
goal which we can do in a separate revieworg.apache.maven.it.Verifier
within junit to execute integration tests against projects insrc/test/resources/config
, hope that makes sense. Happy to refactor the existing integration tests if you like this method.MavenProjectLicenses
, as I was thinking about future cases where we may invoke this maven plugin to performe license enforcement on other languages/frameworks (gradle+java, python, whatever). I haven't implemented a config-driven factory for this, as it seemed a little premature and obtuse, but that was my thinking down-the-lineAnd one question for you:
Would you like me to put some documentation in
src/site
? Or we maintain a wiki? The parameters I've added are javadoc, but some common configuration examples would likely be helpful to others who don't know to go digging in this projects test resources