Yes, this is implemented in analysis-core due to JENKINS-17309. I think this change was to aggressive and should be applied only to parsers of non-XML files. I think each tool that produces XML files should already escape correctly.

Code changed in jenkins
User: Ulli Hafner
Path:
src/test/java/hudson/plugins/checkstyle/parser/CheckStyleParserTest.java
src/test/resources/hudson/plugins/checkstyle/parser/issue25511.xml
http://jenkins-ci.org/commit/checkstyle-plugin/15d6527b3e1f7bfaeba16cbe3ac18e693522b64d
Log:
JENKINS-25511 Added testcase.

Compare: https://github.com/jenkinsci/checkstyle-plugin/compare/9b6bd2b36baf...15d6527b3e1f

After adding the test case I'm not sure if I still understand the problem What exactly is the problem and your expectation? In the test case the escaped text is still the same. Where exactly is the double-escaping visible?

Here is how to reproduce:

1. create a job called "jobName" (name doesn't matter)
2. from within a job publish checkstyle report (the "phpcs_checkstyle.xml" file)
3. open /var/lib/jenkins/jobs/jobName/1/checkstyle.xml file (the "1" is build number)
4. that file should contain double escaped xml already
5. go to http://your.jenkins.instance.com/jobs/jobName/1/checkStyleResult/api/json?pretty=true&tree=warnings[*]
6. the "message" key at least of some messages will have content escaped by XML rules twice (the

' and "

)

I guess the XML file is source for /checkStyleResult/api/json page, so if new generated checkstyle.xml is escaped properly, then the JSON output from it will be as well.

I understand. You are not referring to the UI, you are referring to the persisted values and the API. Seems that Jenkins serialization process also escapes the values.

As you can see Jenkins already does double escaping when job publishes it's Checkstyle.xml report (the <message> node in jenkins_checkstyle.xml). If that will be fixed, then I guess all should be ok.

However if API xml request doesn't escape content considering that published checkstyle xml file already was escaped then this might be problematic.

Code changed in jenkins
User: Ulli Hafner
Path:
.idea/libraries/Maven__org_jvnet_hudson_plugins_analysis_core_1_66.xml
analysis-collector
checkstyle
compile.sh
warnings
http://jenkins-ci.org/commit/analysis-suite-plugin/479368313b7a76b448f13dcf4cc9dce8fcd51a9d
Log:
[FIXED JENKINS-25511] JENKINS-17309 Reverted XML escaping of message.

Revert of fix for JENKINS-17309. Previous solution was too aggressive, it makes sense to escape only messages from parsers that parse non-XML files. XML parsers should not escape entities at all.
AbstractAnnotation never escapes entities now, only GCC parser escapes and invokes constructor with escaped message.

Compare: https://github.com/jenkinsci/analysis-suite-plugin/compare/db92e5d8fbfa...479368313b7a

Code changed in jenkins
User: Ulli Hafner
Path:
checkstyle.iml
pom.xml
src/test/java/hudson/plugins/checkstyle/parser/CheckStyleParserTest.java
http://jenkins-ci.org/commit/checkstyle-plugin/067654f75120c548ba24ddf20b574e00e1c5056b
Log:
[FIXED JENKINS-25511] JENKINS-17309 Reverted XML escaping of message.

Revert of fix for JENKINS-17309. Previous solution was too aggressive, it makes sense to escape only messages from parsers that parse non-XML files. XML parsers should not escape entities at all.
AbstractAnnotation never escapes entities now, only GCC parser escapes and invokes constructor with escaped message.

Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/analysis/util/AbstractPackageDetector.java
src/main/java/hudson/plugins/analysis/util/EncodingValidator.java
src/main/java/hudson/plugins/analysis/util/JavaPackageDetector.java
src/main/java/hudson/plugins/analysis/util/model/AbstractAnnotation.java
src/test/java/hudson/plugins/analysis/util/model/AbstractAnnotationTest.java
http://jenkins-ci.org/commit/analysis-core-plugin/e001040655c1b7018019a3179ed346b9f855c438
Log:
[FIXED JENKINS-25511] JENKINS-17309 Reverted XML escaping of message.

Revert of fix for JENKINS-17309. Previous solution was too aggressive, it makes sense to escape only messages from parsers that parse non-XML files. XML parsers should not escape entities at all.
AbstractAnnotation never escapes entities now, only GCC parser escapes and invokes constructor with escaped message.

Compare: https://github.com/jenkinsci/analysis-core-plugin/compare/4b695e192cc2...e001040655c1

Code changed in jenkins
User: Ulli Hafner
Path:
pom.xml
src/main/java/hudson/plugins/warnings/parser/AbstractWarningsParser.java
src/main/java/hudson/plugins/warnings/parser/GccParser.java
src/test/java/hudson/plugins/warnings/parser/GccParserTest.java
src/test/java/hudson/plugins/warnings/parser/ParserTester.java
src/test/resources/hudson/plugins/warnings/parser/issue17309.txt
warnings.iml
http://jenkins-ci.org/commit/warnings-plugin/7af227eb669868a09d1fe09e19c8a025118983dc
Log:
[FIXED JENKINS-25511] JENKINS-17309 Reverted XML escaping of message.

Revert of fix for JENKINS-17309. Previous solution was too aggressive, it makes sense to escape only messages from parsers that parse non-XML files. XML parsers should not escape entities at all.
AbstractAnnotation never escapes entities now, only GCC parser escapes and invokes constructor with escaped message.

Compare: https://github.com/jenkinsci/warnings-plugin/compare/a811a92cfee0...7af227eb6698