>> By the way, latest commits 43ddccb and 5918182 introduced nested "javaversion" element, which breaks Jenkins CI build; I had to remove this for both
I just fixed the PR build to use the latest 1.9.x version of Ant to build the project.

@aprelev the latter, you can push a new commit. What I meant is that hardcoding "e:" is probably a bad idea, one may choose a different namespace prefix; rather, we should be enforcing use of namespace URL for extra attributes.

That is why I introduced parameterised version of `ExtendableItemHelper::getExtraAttributes()` used by `XmlReportParser`, this way parsed dependencies have both versions of qualifiers, same as resolved dependencies.

As I pointed out in original PR message, issue may instead be solved by modifying `ModuleRevisionId::equals()` to use `super.extraAttributes`, provided attributes namespaces cannot clash, of course, which will result in ignoring qualifiers:
```Java
@Override
public boolean equals(Object obj) {
...
return other.getRevision().equals(getRevision())
&& !(other.getBranch() == null && getBranch() != null)
&& !(other.getBranch() != null && !other.getBranch().equals(getBranch()))
&& other.getModuleId().equals(getModuleId())
&& other.getExtraAttributes().equals(getExtraAttributes()); //< ignoring qualifiers
}
```
At what point do you suggest we check for presense of `':'` in the names of attributes?

Sorry, my reasoning took the wrong turn, must be the heat ð¦Yes, passing qualified attributes to XmlReportWriter is the way to go.

I wonder what was the reason for using "extra-" hack? I assume it was conceived as a way to avoid dealing with with random namespaces in the XML report. If it makes sense to continue with that, a way to encode the namespace prefix must be figured out.

That means one should look at the permitted characters in the [XML Specification](https://www.w3.org/TR/xml11/#NT-NameChar) and try to figure out a separator such that from a name constructed as "extra<separator><namespace-prefix><separator>-<name>" a namespace prefix and a name could be extracted unambiguously.

I propose using something like ".-_-." as a separator since it is unlikely to occur in any namespace prefixes for extra attributes describing Ivy artifacts (if somebody does that, it must be on purpose and thus an attempt to shoot oneself in the foot). Or should we rather deal with namespaces in XML reports?

P.S. You're right about the Jira issue, please add it to the name of the PR (and eventually to the commit name).

@twogee, why don't we just stick with deterministic encoding like
```Java
extra-<qualifiedName> // e.g. extra-e:foo, extra-m:classifier, extra-foo
```
since both `'-'` and `':'` are allowed name characters? This would also incur minimum changes to the codebase: literally passing `::getQualifiedExtraAttributes()` to `XmlReportWriter::extraToString()` so qualifiers can be picked up by `XmlReportParser::startElement()` automatically.

Or, if you want to avoid using `':'` in the report (if original `extra-` prefix was supposed to replace the namespace, as you guessed it was), we could use another deterministic encoding like
```Java
extra-<qualifier>-<name> // e.g. extra-e-foo, extra-m-classifier, extra--foo
```
which would require additional encoding and decoding overhead in both XML report parser and writer, but otherwise imply no restrictions on naming?

Also, in the name of code clarity and with respect to single responsibility principle, in my opinion, it would be better if `ExtendableItemHelper` handled both encoding and decoding of attributes (as of now, encoding is handled by `XmlReportWriter::extraToString()`).

Keeping `':'` would require XML report to deal with all those pesky namespaces, because it must be a valid XML.

Using a simple `'-'` as a separator may cause trouble if somebody decides to use a namespace prefix with `'-'`. That's why I insist on something less likely to be used. I hope dev list would comment, too.

> Using a simple '-' as a separator may cause trouble if somebody decides to use a namespace prefix with '-'.

I don't actually see a problem with that: we can
- either escape dashes with some other character, like `.` (`-ns-:-foo.` â `extra-.-ns.--.-foo..`),
- or replace them with `&#45;` (`-ns-:-foo.` â `extra-&#45;ns&#45;-&#45;foo.`).