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
API: make api not depend on antlr by splitting DetailAST between implementation and interface #3417
Comments
@romani I think this can have the checkstyle 8 label. |
@MEZk @romani Right now issue is you don't want to include ANTLR in API packages.
However, I noticed that this issue doesn't affect |
@rnveach |
yes, It is better to use interface, in general I agree, BUT:
================= But probably we could make it into 2 steps: convert to interface and resolve API dependency to ANTRL ; migrate to new AST that is immutable. |
We had the discussion that we could use fully immutable collections. Collections are easier to use, but
Thus, I'm for arrays.
We can make our inner implementation immutable.
Should this AST class be our inner immutable implementation of the DetailAST interface which we will expose to API clients? |
I don't know if this has been considered already, but AFAICT Checkstyle depends on Guava in some way, so one potential way of achieving |
unfortunately dependency to guava is just another pain for applications/plugins that embed checkstyle. |
@romani Okay. IIUC, you think my idea wouldn't work not because you think my idea is to have an API like |
Api signature should not depend on guava, implementation could return runtime-immutable type. Right now, DetailAST is implementation in api area . So any update to use guava will result of api dependency to guava that we try to avoid |
unfortunate fact, just a reminder that API already depends on guava (8 years in play already):
|
This comment has been minimized.
This comment has been minimized.
Fix was merged. |
@romani I assume you are ok with misc label? |
I put |
@rnveach , We did very big compatibility damage - https://travis-ci.org/sevntu-checkstyle/checkstyle-samples/jobs/537427424#L522 , please recheck why it was not detected during testing. What we can do to prevent this in future ? execute samples in checkstyle's CI over snapshot ?
|
@romani I can only assume it is because when we test with sevntu we re-compile the classes and that is why we missed it. For our own sevntu run in the pom, we still use an old version of checkstyle since sevntu is still connected to it. |
this issue is for major version bump release.
api should be clean and do not depend on any thirdparty libraries.
antlr dependency was beneficial for quick development , but now it cause a problems during embedding checkstyle in other systems. Antlr classes could conflict with another dependencies of application.
Dependencies to any other third party is also not desirable.
from discussion with eclipse-cs author:
"
Checkstyle itself gains little to nothing from restricting packages. However in OSGI context a bundle (e.g. checkstyle-core) needs declare which of it's packages are visible to extensions.
Today this includes all of Checkstyle's packages and Checkstyle's own dependenceis (antlr, guava, commons-*).
The downside of this in OSGI realm is that those packages are now visible not just to Checkstyle extensions but also do unrelated plugins, which potentially import one of the 3rd-party packages.
This can lead to nasty class version conflicts in unexpected places, e.g. the Checkstyle plugin can potentially break a different plugin.
The main problem is in fact that 3rd-party dependencies today need to be exported in order for (some) checkstyle extensions to work.
"
MIGRATION NOTES: all extensions of Checkstyle has to be recompiled with 8.21 version of checkstyle . Example of failure - #3417 (comment)
The text was updated successfully, but these errors were encountered: