[core] Language properties CLI surface syntax

[oowekyala]

This is about the part of #2518 that could be targeted to master (6.31.0) to accompany #2864

This ticket is just about to add this form of argument to the cli: -L<langId>:<propName> <value>, or some form of this depending on what JCommander supports well

I don't think we should aim to implement the data flow from the command-line arg parsing to the language instance in this ticket. It's probably difficult to do on master, easier on the 7.0 branch, and will stay alive longer on that branch. So this part is still in #2518

Instead, what #2864, and #2830 do is to add attributes to the ParserOptions, as this is what parsers get as their input. Linking the CLI to the ParserOptions can be done with a system property as a swap, which is mostly already implemented in #2864 I think

TODO

• Find out a satisfying syntax with JCommander and implement it (based on [vf] Provide expression type information to Visualforce rules to avoid false positives #2864)
• Document
  • on the website CLI reference
  • we probably need some new page that explains language by language what sets them apart (which language versions, which properties, other details or useful info for people writing rules maybe, and stuff like links to javadoc)
  • in the release notes
  • in the CLI --help?

This should probably be prominently marked experimental everywhere it is mentioned for at least a few releases, maybe even until PMD 7. But the api surface is I think quite small since it's just one form of arguments.

I think this task could shave a big chunk off #2518, because the user documentation will probably not need to change too much

See also:

pmd/pmd-core/src/main/java/net/sourceforge/pmd/lang/LanguageProcessorRegistry.java

Lines 152 to 156 in 642716f

	// TODO this should be reused when implementing the CLI
	public static Map<Language, LanguagePropertyBundle> derivePropertiesFromStrings(
	Map<Language, Properties> stringProperties,
	PmdReporter reporter
	) {

pmd/pmd-core/src/main/java/net/sourceforge/pmd/PmdAnalysis.java

Lines 213 to 218 in 642716f

	// TODO replace those with actual language properties when the
	// CLI syntax is implemented.
	props.setProperty(LanguagePropertyBundle.SUPPRESS_MARKER, config.getSuppressMarker());
	if (props instanceof JvmLanguagePropertyBundle) {
	((JvmLanguagePropertyBundle) props).setClassLoader(config.getClassLoader());
	}

[jsotuyod]

I think beyond exposing this within the CLI (which is somewhat easy in PMD 7 with PicoCli, very similar to what was already done to expose and document renderer properties), we should probably think about having a pmd.properties file we pick up automatically from the current working directory if present (similar to what Gradle does with gradle.properties), where we allow both language and renderer properties to be set statically, and shared within a repository by a whole team if needed.

HEAPSIZE and PMD_JAVA_OPTS (currently taken from env vars by shell scripts) should probably be able to take these values from the properties file if present, while allowing env vars to override them.

[adangel]

@jsotuyod to give you a bit of context - in the last meeting we discussed whether this needs to be done before pmd7 and the conclusion was, it is not necessary. So, we removed it from the pmd6 milestone.