Closes #13275 : export footer only for commands that support --output

[070jhz]

Closes #13275
the --output option is more indicative of export behavior than --output-format while checking among the option names.

Steps to test

Commands that export

./gradlew :jabkit:run --args="convert --help"
./gradlew :jabkit:run --args="search --help"

Commands that don't

./gradlew :jabkit:run --args="check-consistency --help"
./gradlew :jabkit:run --args="pdf --help"
./gradlew :jabkit:run --args="generate-bib-from-aux --help"
./gradlew :jabkit:run --args="generate-citation-keys --help"
./gradlew :jabkit:run --args="pseudonymize --help"
./gradlew :jabkit:run --args="preferences --help"

Mandatory checks

• I own the copyright of the code submitted and I license it under the MIT license
• Change in CHANGELOG.md described in a way that is understandable for the average user (if change is visible to the user)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (if change is visible to the user)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[koppor]

Commands that export

Err. No.

[070jhz]

Am I misunderstanding something ?

[koppor]

Am I misunderstanding something ?

Yes.

Proposal: Write documentation for each CLI command to our user-documentation repository.

Moreover, think of tests. As simple as expected --help output. Check for the strip after the "header".

If you are not able to do the former, the latter is required. Otherwise, we cannot check without running all the commands for ourselves and thinking if this is right what you claim

[070jhz]

Moreover, think of tests. As simple as expected --help output. Check for the strip after the "header".

Fair enough, I'm not familiar with JUnit or the project's testing conventions though so I don't know if I approached it correctly in my last commit

[calixtus]

Moreover, think of tests. As simple as expected --help output. Check for the strip after the "header".

Be aware: We don't need to test if PicoCli works. I am sure that PicoCli has an extensive test suite.

Test logic, not strings.

[koppor]

Test logic, not strings.

In this case, some "grep"ing would make sense. Checking if the help output does not contain the export formats. (We do this in fetcher tests when we remove abstracts)

Alterantively, full help output string checking. If we update the CLI, all tests need to be updated. We do this at fetcher tests (because we compare the complete result)

I'm not sure, which way to go. Maybe "grep"ping is fine.

[trag-bot]

Assert the contents of objects (assertEquals), not checking for some Boolean conditions (assertTrue/assertFalse) to improve readability and maintainability.

[trag-bot]

Assert the contents of objects (assertEquals), not checking for some Boolean conditions (assertTrue/assertFalse) to improve readability and maintainability.

[070jhz]

Thank you both for your insights. It now accesses the raw data model in picocli where applyUsageFooters places the footer string. It's still grepping but no longer calls for picocli to format the help text.

[koppor]

Minor comment. Someone really needs to think through this.

[koppor]

Add @VisibleForTesting

[koppor]

no test prefix at naming (Openrewrite should tell)

[trag-bot]

@trag-bot didn't find any issues in the code! ✅✨

[koppor]

the --output option is more indicative of export behavior than --output-format while checking among the option names.

Unfortunately, not.

--output specifies the output file. In our case BibTeX, which is the native format of JabRef - thus no export. (Think of "Save" in Word, there is no conversion made)

--output-format is an extra conversion step. Think of "Save as" in Microsoft Word.

[jabref-machine]

Your code currently does not meet JabRef's code guidelines. We use OpenRewrite to ensure "modern" Java coding practices. You can see which checks are failing by locating the box "Some checks were not successful" on the pull request page. To see the test output, locate "Tests / OpenRewrite (pull_request)" and click on it.

The issues found can be automatically fixed. Please execute the gradle task rewriteRun from the rewrite group of the Gradle Tool window in IntelliJ, then check the results, commit, and push.

[070jhz]

In that case, if we look at commands with --input-format and --output-format options, it works except for the search command, which can convert the query results if an output format is specified.

I suggest I change the logic to check for those two options (only the convert command checks out for the moment) and handle the search edge case

[koppor]

In that case, if we look at commands with --input-format and --output-format options, it works except for the search command, which can convert the query results if an output format is specified.

I don't get this. Screenshot of the code:

It has --output-format for the format - and --output for the filename.

[070jhz]

I meant matching on both --input-format and --output-format would yield the correct commands to apply the help footer to, except for search which doesn't have an --input-format option but can convert.