I sanitized both projects, I think all uses of the class are gone. I'll remove it and remove the dependency on the legacy jar and resolve once we have nightlies passing.

Never mind, Eclipse's search is being weird, I see the references now. I'll go ahead and at least deprecate the class.

@Ian Young
I'm not seeing any references across the V4 stack to the XMLAssertTestNG class. I don't think any of these issues up the stack were ever resolved, but maybe the dependency on this class was?

If so, we should obviously just go ahead and remove it (and it's not API since it's a test class, so we can just yank it immediately).

is this something we actually want to completely forget about until IdP 4.0.  Might it be too disruptive to do it in the 3.4 timescale?

There's only one test class referencing the legacy API in this project, XMLAssertTestNG. This is not a test, but a test utility class described as follows:

It has an interesting non-Apache license at the top because of this; I assume this is not an issue because it's for internal use and not shipped as part of any product.

It's used by just two tests in java-identity-provider and about a dozen in java-opensaml.

The XMLAssert class is no longer part of the XMLUnit API with version 2, and the meaning of the Diff objects passed through to the methods in this class have changed enough that the V2 ones aren't a drop-in replacement for the V1 ones.

It seems, therefore, as if the easiest way to resolve this will be to:

• deprecate this class in the V3 stack

• migrate java-opensaml and java-identity-provider to use the V2 XMLUnit native API and perform their own asserts as part of https://shibboleth.atlassian.net/browse/IDP-1263#icft=IDP-1263 and https://shibboleth.atlassian.net/browse/OSJ-233#icft=OSJ-233 respectively (this could be done as part of V3.4, or later)

• remove this class from the V4 stack