-
Notifications
You must be signed in to change notification settings - Fork 34
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
Support commons-io 2.7 #168
Comments
Thanks for the hint! I will check it for changes by API difference. For now I would recommend to use signatures of version 2.6. Uwe |
I doesn't work with commons-io-unsafe-2.6 |
Why should it not work? There is no requirement to use the latest signatures file. Please give more details! |
[ERROR] Failed to execute goal �[32mde.thetaphi:forbiddenapis:3.0:check�[m �[1m(check)�[m on project �[36mmac-bc360-custom�[m: �[1;31mParsing signatures failed: Method not found while parsing signature: org.apache.commons.io.output.ByteArrayOutputStream#toString()�[m -> �[1m[Help 1]�[m |
I think that the method toString() has been deleted in commons-io 2.7 |
With the stack trace: |
Hi @Dichotomia thanks, this looks like the issue. What confuses me: I did not find any mentions about this in the release notes of 2.7. Was this metjod deprecated, otherwise it looks like a backwards-incompatible change in commons-io, breaking user updating. Of course they should have never used that method, as it does not use correct charset. I'd suggest as a workaround to disable that it fails un unresolvable signatures. |
Ok. I try to warn commons-io about it, because the version is marked as binary compatible. Sorry, i didn't understand what the workaround is. |
To get past the error in forbiddenapis, you can switch off this flag (set it to |
Ok thanks. Issue in commons-io : https://issues.apache.org/jira/browse/IO-671 |
I found the issue: There is no binary incompatibility, the problem is that the method was moved to an abstract superclass in forbiddenapis. It's no longer directly inside ByteArrayOutputStream(). To fix this, I need to release a new signatures file for 2.7 (as proposed here), but on the other hand think about ways how to handle that in signatures files. Currently all signatures must resolve directly, there's no virtual method resolving introduced. |
…as there was an incompatible change; This also adds signatures for version 2.7. TODO: Scan for other API differences (new methods) in 2.7 vs. 2.6
#169 is a quick fix for the issue, but I don't like it yet - as it has to enable ignoreUnresolvable for the very first commons-io-1.0 version signatures file. |
I improved the situation a bit. It just adds |
I scanned the API differences: https://commons.apache.org/proper/commons-io/japicmp.html I found no other new methods taking default charsets, so PR #169 is the only change needed. My plan is to merge the PR tomorrow and target a bugfix 3.0.1 release, as this is an issue affecting all people who upgrade common-io, as not even older versions of signatures work. For version 3.1, I will think about a better way to handle such issues. For deprecated signatures in the JDK it always uses I tend to think about ignoring failures for all commons-io signatures at runtime only, but during "testing" of forbiddenapis, the check against the base version are "hard", so typos in signatures would fail forbiddenapis build and packaging. |
Hi, |
3.0.1 works. Thank you ! |
Released 28 May 2020: http://commons.apache.org/proper/commons-io/changes-report.html#a2.7
The text was updated successfully, but these errors were encountered: