Embed coverage-04.dtd into binary

[Galarius]

• Embed coverage-04.dtd into binary

  The main purpose of embedding the coverage-04.dtd into xcc
  is to allow xcc to work in certain deployment environments where there may be restrictions on Internet access.

• Fix swift build warning

  warning: '--build-path' option is deprecated; use '--scratch-path' instead

• Add smoke test

The description has been edited to reflect the latest changes.

[Galarius]

@twittemb, another approach is to embed coverage-04.dtd in the binary. Would it make sense?

[twittemb]

@twittemb, another approach is to embed coverage-04.dtd in the binary. Would it make sense?

Hi, thanks for the PR.
I can see this mechanism:

• by default the DTD is embedded in the binary
• we offer the possibility to provide a URL (local or remote) as a new parameter if the user wants to customise it

does it make sense ?

[Galarius]

If it is fine to embed coverage-04.dtd in the binary, I honestly don't see any benefit in providing a custom DTD URL. The main goal is to be able to run xcc in the network isolated environment.

A number of keywords are hardcoded, so providing a DTD file with different content will likely break the converter. Moreover, introducing a new parameter requires some refactoring to be done, because both supported converters conform to the same interface, but only cobertura-xml will need this parameter.

[twittemb]

If it is fine to embed coverage-04.dtd in the binary, I honestly don't see any benefit in providing a custom DTD URL. The main goal is to be able to run xcc in the network isolated environment.

A number of keywords are hardcoded, so providing a DTD file with different content will likely break the converter. Moreover, introducing a new parameter requires some refactoring to be done, because both supported converters conform to the same interface, but only cobertura-xml will need this parameter.

Good analysis. I think it is fair to embed it in the binary and that's it.