polyglot-scala: Support more valid XML element name chars in dynamic Config

[lefou]

The convenient dynamic apply of Config companion object has currently some technical limitations which result in mangled parameter names. When used without further processing (as it is currently the case), not all valid element names (in terms of XML element spec) can be specified, e.g. the minus ("-") is a valid character in XML element names, but not in Scala methods names.

To get the following model (config of bundle-maven-plugin, XML notation):

<configuration>
  <instructions>
    <Bundle-Name>Test bundle</Bundle-Name>
  </instructions>
</configuration>

I want to write:

configuration = Config(
  instructions = Config(
    `Bundle-Name` = "Test bundle"
  )
)

But this currently doesn't work. It results in:

<configuration>
  <instructions>
    <Bundle$minusName>Test bundle</Bundle$minusName>
  </instructions>
</configuration>

So, one has to fall back to the class constructor of the Config class.

configuration = Config(
  instructions = new Config(immutable.Seq(
    "Bundle-Name" -> Some("Test bundle")
  ))
)

This PR tries to fix that.

The list of possibly supportable characters is not complete yet, but it's a start for the most common cases. I added a TODO note linking the XML spec.

I need to figure out how to programmatically create test cases with specs2. Any hint is welcome.

EDIT: added better motivation

[huntc]

Thanks for the PR - I'm curious as to the reason for this additional element name check in the first place. Could you please elaborate on the PR's motivation in the description?

[huntc]

Ah, so I just read this from gitter (again, better to have the PR standup in isolation of other things in terms of its description):

For reference: current limitations are element names, e.g. a minus is allowed in XML and is needed when you generate (OSGi) JAR Manifest entries via XML (bundle plugin)
You can't currently generate these with the convenient dynamic apply of Config.
So, simplifying that part of the API would be of much help.

Just thinking out loud: might it be more performant then to have to expose sanitizeElementName into something like escapeElementName and have the programmer use it when required?

[lefou]

@huntc Do you meant by "performant" more speed or more developer efficiency? If you have a faster way to replace those occurrences, I'm open for improvements. If you want to give the pom developer more flexibility (to workaround some invalid element names), then I would say: he already has it as he/she can always fall back to the class constructor of Config.

[lefou]

Ping. A merge and a release would be really great.

[mosabua]

Sorry.. been on leave for a while... will try to get to it soon.

[lefou]

Bump

[mosabua]

Sorry for the delay.. I am working towards a release of this project asap now.

[lefou]

Great. Thank you!

[mosabua]

Does this fix #146 @lefou ?

[lefou]

@mosabua No, this does not fix #146.