I have long used the Apache maven-changes-plugin as part of my Maven project site builds, in order to generate a simple HTML report of the tickets included in my release.
This plugin provides mechanisms for retrieving issues from a local XML file, or from a few popular remote ticket management software, one of which is JIRA.
The integration with JIRA supports JQL queries into JIRA, authenticating using credentials provided by inline Maven pom.xml configuration fields 'webUser' and 'webPassword'.
Whereas other, similar Maven plugins utilize a 'username' and 'password' configuration, and typically provide a way to externalize it to a separate environment-specific settings.xml file (where it can be encrypted), the maven-changes-plugin jira-report appears not to provide such a capability, at least so far as I can see from the documentation.
I tried similar configuration that is present in related plugins, including settingsKey/usernameProperty/passwordProperty to try to make the plugin look in the settings.xml.
It doesn't seem to respect any of those kinds of properties. The only way I was able to get the plugin to properly authenticate and retrieve the JIRA details was to put the username and password inside the pom.xml file itself, hard-coded and clear-text.
The testing we've done has been exclusively with the webUser/webPassword configuration, not the jiraUser/jiraPassword configuration, using a JIRA Cloud token that was generated from a read-only user. The username and token work fine when configured properly inline in the pom.xml, but I just cannot seem to find a way to externalize them to settings.xml, where they could be locked down to machines that need them and not stored in source control and developer machines.
The plugin appears to have last been updated in 2016 or earlier, so perhaps I should just let it go. But I wanted to ask the question in case anyone has a surprise answer, and so others can learn from it.
EDITED TO ADD: I did not do any testing to try to inject the credentials using ${env.FOO} or ${settings.fieldName} approaches. I have concerns about when that replacement occurs and whether the clear text values would end up in the effective POM that gets logged or included in build artifacts, etc.
