|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
Disclaimer before you waste time reading below just to discover that I'm clueless: I have no idea what CloudFoundry is, or what this plugin does. I just monitor/triage incoming issue reports, saw this one, and wanted to point to the built-in proxy configuration.
Regarding the help: I don't see in the core code that it sets the system properties anywhere. My guess is that information is obsolete.
Proxy configuration is stored in hudson.ProxyConfiguration and used or accessed by various components directly. It's what's used for auto-installation of tools in hudson.FilePath, Gravatar plugin, Scriptler catalog access, and various plugins implementing integration with online services. (see for yourself using https://wiki.jenkins-ci.org/display/JENKINS/Grepping+all+sources for e.g ProxyConfiguration\.open)
I'd go with ProxyConfiguration if there's no way that this behavior would surprise users (e.g. if CloudFoundry is always beyond the proxy servers), and maybe a plugin-specific proxy configuration otherwise. Settings via system properties have the problem that they're difficult to change (for regular users) without restarting the application, and it requires passing extra arguments to Jenkins when often it's just run as java -jar jenkins.war. If this were a much more specialized option, System properties were a reasonable "UI" (like https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties), but proxies should be common enough to warrant something better.