-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
[core] Language properties #2518
Comments
Thanks for writing this up! These are very good ideas. I've right now only one comment regarding file extensions/patterns: I think, the reason, why PMD actually looks at the file extension, is this: it was envisioned to have a ruleset that references rules of different languages and you would call PMD on a project directory which contains files of these different languages. Now PMD has to figure out, which rules should be applied to which files - since trying to parse a file with the wrong parser will result in many errors, which are not real errors. |
What's the assumption made about the rules file? Is PMD expecting separate rule config files for each language? This could be the norm but it's quite likely that a project would support multiple languages such as java, JSP, xml in the same project. Wouldn't it be better to have these language properties reside in a properties file unique to that project and have the ruleset file refer to these properties somewhat like Ant does? This lends itself to some extensibility and the language properties can be prefixed by the language identifier. This only becomes complex if you are supporting multiple versions of the same language i.e., jdk ; some naming convention can be arrived at to resolve this. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I don't think this necessarily holds. More importantly this issue is mostly about the lifecycle, and the cli extension is just the easiest way to close the loop. I suggest we start by implementing that, and then discuss better ergonomics if need be -> but somewhere else. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Done for PMD 7 via #4060 |
I think the most generic solution to the problems we have when it comes to configuring languages, is to configure Language instances directly via properties.
Example use cases:
The core of this proposal is to make LanguageRegistry non-static, and giving it a proper lifecycle. This makes it so, that analysis-global state (like the classloader) can be stored in the language instance, and shared with eg the parser and other processing stages, without having to jump through hoops to figure out if we have the same parameters as before.
Consider making the service that is loaded by ServiceLoader not Language directly, but a LanguageLoader. This object creates a Language instance with property descriptors. The initialization takes care of configuring the language with all those things mentioned above.
For example, a LanguageLoader interface could look like so:
newPropertyBundle
creates a PropertySource and defines the PropertyDescriptors accepted by the languagecreateLanguage
creates a language instance given a configurationEg the java implementation of this would be
Language properties can be set with this simple CLI extension:
-L<langId>:<propName> <value>
.For example
-Lxml:fileNamePatterns 'pom.xml,*.fxml'
, or-Ljava:auxclasspath 'some;cp'
.The initialization process of a language registry would look like so:
LanguageRegistry
uses ServiceLoader to load a bunch of LanguageLoader instances-L
options of the command line args are partitioned by language IDnewPropertyBundle
)createLanguage
with that property bundleLanguage and LanguageRegistry can implement AutoCloseable. This allows the language registry to be used in a try statement.
So, very high in the PMD call stack, we can have something like
I think this mechanism solves long-standing issues with our configuration model, namely
the horror that's PmdAsmClassLoader to share objects through an analysis. Such "tricks" make PMD harder to use in a concurrent setting. There's no cleanup of static state at all.
It gives us a simple and general extension mechanism to configure language-specific behavior,
without affecting other languages, and without needing changes to pmd-core. For example, we could use that to enable logging of detailed type-resolution-specific debug information (missing classes, type inference failures), which would fit well into the updated java module
The text was updated successfully, but these errors were encountered: