Details
-
Improvement
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
Description
The current implementation of XmlFile.java emits an XML 1.0 header, which breaks things like Move/Copy/Promote if the user has included any characters that are illegal in XML 1.0 (such as Control-XX, etc) in their jobs.
XStream, which is used for serialization/deserialization, deals with XML fragments, and doesn't have an issue reading/writing this non well-formed XML. Changing XmlFile.java so that it creates xml 1.1 here will allow jenkins config files to support these special characters. This also requires updating the underlying XML Pull Parser being used by XStream to something that support XML v1.1
Attachments
Issue Links
- relates to
-
JENKINS-54146 Job History Plugin 2.18.2 - XML view not working
-
- Resolved
-
-
-
- Resolved
-
- links to
Activity
Aaron Jensen
added a comment - Here's our use-case: Developers have certain golden paths for creating specific types of applications. We have templates in Jenkins for each type. Developers run a build to create a new application. We grab the config.xml from the template, update it to use values specific to the new job, then post that config.xml to Jenkins to create the job.
Switching to the two plug-ins mentioned is a big under-taking. We have to learn Groovy and/or export our entire Jenkins configuration as YAML and write automation to apply it. Given enough warning, we could do it. This feature should be rolled back, then announced that it's coming with instructions on how to migrate to some way of managing job configurations without touching config.xml files. Then the config.xml file format can become internal and you can change to 1.1 if you want and this could get refiled as "allow job configuration to include control characters".
Aaron Jensen
added a comment - Here's our use-case: Developers have certain golden paths for creating specific types of applications. We have templates in Jenkins for each type. Developers run a build to create a new application. We grab the config.xml from the template, update it to use values specific to the new job, then post that config.xml to Jenkins to create the job.
Switching to the two plug-ins mentioned is a big under-taking. We have to learn Groovy and/or export our entire Jenkins configuration as YAML and write automation to apply it. Given enough warning, we could do it. This feature should be rolled back, then announced that it's coming with instructions on how to migrate to some way of managing job configurations without touching config.xml files. Then the config.xml file format can become internal and you can change to 1.1 if you want and this could get refiled as "allow job configuration to include control characters". 
Andrew Lamonica
added a comment - splatteredbits, here is what we ended up doing. https://paste.ofcode.org/3aPEN9YyVDEcCGM2JmX8zw
Andrew Lamonica
added a comment - splatteredbits , here is what we ended up doing. https://paste.ofcode.org/3aPEN9YyVDEcCGM2JmX8zw You must note that most editors that work fine with XML 1.0 can't parse XML 1.1. After more than a decade successfully using the free MS utility XML Notepad for all XML tasks I may have to look for another editor. How much of a demand there was for this change?
Just to add, as far as I can tell you only need 1.1 if you've got control characters in names (i.e. of tags and attributes).
Surely if people are putting them in their configuration it's in text content, where 1.0 works just fine with standard escapes.
Not only does .NET not support xml 1.1 but neither does Firefox, nor any of my editors.
If the config.xml file format is considered internal, Jenkins shouldn't have APIs that expose it. That's not internal.