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] Support default CLI options and document usage examples with @-files and default files #2087
Comments
It's already possible though not documented. It's a feature of JCommander:
Eg write a file |
This looks promising. My concern is that this is parameter expansion as read from the file and may not allow overriding of switches /options. Does it, i.e., can I use the same parameters on the command line? I haven't got around to testing JCommander if it does support overriding. The documentation does not make any mention of it. I'm unable to find any CLI component that supports properties files. Would it be worthwhile to put in a request to JCommander to support properties files? |
I did a simple test: This is the content of file
So, you specify each parameter in a extra line (also the options to a parameter are in a separate lines). Then you can run pmd like this:
However, overriding is not possible - additional parameters are possible, but they are added additionally. Which makes sense, you specify it once via the file and once directly, so in sum - twice:
(from cbeust/jcommander#330) The question is: Do you need overriding? If you know, that one parameter (say e.g. the format) will vary, then just don't put it in the parameters file... Btw.: CLI only supports specifying one format - the Ant task allows you to specify multiple formats (e.g. to create with one run a html and xml report). This is basically a lack of the CLI interface that PMD provides: e.g. format is not a List, so can be specified only once. But providing multiple format requires that we know for each format, where to save the report to. This means, that -reportfile must be a List as well. However, then we should maybe do something else, like specifying the format like Btw.: your example doesn't make sense: I'd suggest to improve the documentation to show, how If you have a concrete use case for overriding a specific parameter, then we should do this in a separate issue. It's better to solve a concrete problem than trying to fix unnecessary theoretical problems. |
The example was illustrative. I could have made it more relevant to PMD, I
guess.
I don't have a specific use case in mind but precedent exists.
The best programs allow 'defaults' to be read from a properties or rc file
(such as PerlCritic) permitting parameter-overriding from the command line.
The @ defeats the purpose of being able to specify defaults and forgetting
about them until you need to update or override them. You will have to
specify the @ on the command line every time unless you hard-code a default
in the run.sh script and document it as such.
You have a point about PMD not really needing that ability, at least not
yet. It helps that PMD doesn't have a Swiss-army knife utility-feel to it.
Functionality such as CPD is separated out into a different java class.
I'd still like to be able to specify defaults in a file and then override
them with only the overriding visible.
Then, there could be a switch that allows the user to specify a different
properties file, if needed.
It would be best if this were part of its codebase, rather than PMD's.
|
https://github.com/cbeust/jcommander/blob/master/src/main/java/com/beust/jcommander/JCommander.java I finally found the time to look at JCommander. It appears that there is support for providing default values via a properties file. The relevant sources are listed above. However, it doesn't appear to support overriding. Does someone want to test this, though? It's the end of day for me here. The documentation at jcommander.org makes no mention of property files, though. This invalidates my comment above. Strikethrough? I've raised an issue on JCommander : |
I tested the above for properties. And the property values are not being used. https://github.com/Fernal73/LearnJava/tree/master/JCommander I still think this should be part of JCommander's code base, not PMD's. Code can always be contributed to JCommander. |
As far as I can see, there have been no commits on JCommander for the last three months. Has the project been abandoned? |
Another option would be to check out picocli that Checkstyle uses. https://picocli.info/#_default_provider https://picocli.info/#_overwriting_single_options Is it superior? While it's still my opinion that Picocli and JCommander provide support for properties files fully, PMD might need to implement some of that functionality if it's not provided out-of-the-box. |
There is nothing preventing us from using an alternative for JCommander - it's just an implementation detail and opaque to the user. But I'm still missing the use case... Why do we need that? Would it make PMD more complicated to use? E.g. if we allow overriding options, how easy/difficult is it to know, which options are now really used? Wouldn't that lead to other bugs, like "this option is not used", then we dig into it, and see, it is not used, because it is overridden later on... |
The initial usecase was to allow default properties to be set via profile
files.
As argued, this could be met via @files as well as long as single-valued
parameters are not respecified via the command line.
This would break JCommander.
My usecase is that sometimes I might wish to override these especially if
I'm using a script that calls the java command (let's just say to test
something different from my usual use).
I don't wish to create another script that simply accepts "$@" which is
simply a wrapper for the java command line class.
Why should I need two or more scripts when I could simply have multiple configurations?
|
IMO PicoCLI looks in general a bit more mature/feature-complete than JCommander. IIRC a really nice feature that JCommander does not do is generate autocompletion files for (at least) Bash. It's been a while since I looked into it though
This isn't clear to me. Is your script calling PMD directly using the java command, eg Why don't you just copy the command-line and manually change options? It looks like you don't need to do this often, and that would work.
PMD's distribution already includes such scripts
I think you're right that overridable options can be abused... but I would also think this is not directly PMD's concern, so does not really warrant emitting warnings. Though I'm pretty sure someone will cut themselves on it one day and feature-request that... One other "problem" with overridable options is also that every switch should be negatable. For now we have default behaviour, and switches that enable the opposite of the default. There's no switch to go back to default behaviour. Eg if your default profile includes It looks like allowing overriding CLI options would require a significant effort to implement, and especially to test. I'm not sure the effort is proportionate to the current use-case. |
I'm not using the PMD wrapper script. So, yes. Since PMD is not the only
static analysis tool I use, I have my own script. I use static analysis as a learning tool to write better code. In practice, if you're using multiple ones, you'd be careful to run a rule only once in your project for efficiency. Projects test static analysis tools as a side effect. They're not written specifically for that.
Picocli has something called negatable options. That's neither here
nor there.
Picocli has some elaborate stuff such as above built-in. I don't see why
overridable options can't become standard for CLI APIs. It's quite common
to have profiles for programs these days.
Different use cases would have to be captured. It can be argued that it then leaves very little for application
developers to do themselves.
I'm not keen on implementing overridable options within PMD as well i.e., coding the thing. If you follow the picocli thread, though, there's a code sample how to do that provided by its creator.
Are you saying the users won't want them if you support profile files? They will when they're accustomed to using them elsewhere.
|
Hello all, picocli has built-in support for a PropertiesDefaultProvider that I believe meets @Fernal73's requirements. This is different from the If the properties file does not exist, then the default values defined in the applications are applied. This gives end users a way to configure their own default values for the application's options. Users are free to use this or ignore this; this is simply a nice extra feature that mature CLI apps can provide to their users.
I believe this is a side-effect of using I hope this is useful. |
The decision to use picocli or not rests with the repo maintainers. I think it's a good idea and can be migrated to in release 7.0.0. Ps: I can't recall why I didn't like negatable options. Perhaps, it had to do with PMD only having two such options. Otherwise, they're pretty good to have. |
Just FYI - the java command line supports this as well: https://docs.oracle.com/en/java/javase/14/docs/specs/man/java.html#java-command-line-argument-files |
@adangel, regarding support for Specifically, this supports overriding default values on the command line out of the box. |
Since PMD 7.0.0 uses now picocli, the externalization of the parameters in a file should be possible: https://picocli.info/#AtFiles All that is missing is an example in the documentation. Update: we should also use https://picocli.info/#_propertiesdefaultprovider and also provide an example. |
Affects PMD Version:
All.
Rule:
Not rule specific.
Description:
#2006 (comment)
PMD needs a properties file to configure itself so that it can be run without specifying multiple switches on the command line. These switches should be configurable via the properties file and CLI with CLI overriding the files' values.
Running PMD through:
All.
The text was updated successfully, but these errors were encountered: