[bug] azure xml 1.2.0 depends on javax.xml.stream which is not available on android making core and identity not usable on android

[baywet]

Hi,
Your friends from Microsoft Graph here 👋
Our CI recently started failing with azure identity 1.55.0 providing the following error. Version 1.54.1 was working perfectly fine.

Error:   /home/runner/.gradle/caches/modules-2/files-2.1/com.azure/azure-xml/1.2.0/5a811882dc4eba119c7d1f0fc65acf39eaf417c/azure-xml-1.2.0.jar: Error: Invalid package reference in com.azure:azure-xml; not included in Android: javax.xml.stream.util. Referenced from com.azure.xml.implementation.aalto.stax.InputFactoryImpl. [InvalidPackage]

This is because azure identity 1.55.0 updates its dependency on xml from 1.1.0 to 1.2.0

This version has a dependency on javax.xml.stream which is not available on Android.

This dependency was introduced by @alzimmermsft with PR #43282

This represents a pretty big regression in my views, and that change should either be amended not to depend on this package, or reverted, or modularized as a variant so it's not necessary to have it as a direct dependency.

Here is the failing PR, which also gives you access to our entire repository configuration.

CC @JonathanGiles the author of the original xml implementation issue.

[joshfree]

@alzimmermsft can you work with @baywet to unblock MSGraph?

[alzimmermsft]

Thanks for reporting this @baywet!

I'll work on a possible solution for this issue, but I don't have a good setup for Android verification. Would it be possible for you to help with verifying the solution I create?

[baywet]

I believe part of your fix should include adding some CI to ensure there are no other regressions like these in the future.
This is how we caught the issue before impacting customers in the first place.

The way we're doing this is through an android project which runs android api level validation (see the plugins)

Let me know if you have any additional comments or questions.

[alzimmermsft]

Without changing code I was able to get azure-xml to build by including javax.xml.stream:stax-api:1.0 as an additional dependency in an Android application as that package is effectively the Maven shipped version of the built-in javax.xml.stream APIs.

[baywet]

Thanks for the suggestion, I've logged this issue, we'll revert once the changes are implemented.

microsoft/kiota-java#1755

[alzimmermsft]

Also, after performing further investigation into this, I found that the Microsoft Graph's build had suppressed an Android build warning about javax.xml.stream being an invalid package. The last release of azure-xml introduced the usage of javax.xml.stream.util which reintroduced this error. So, this has been an issue for longer than we knew.

I'm going to leave this issue pending with the statement that

<dependency>
  <groupId>javax.xml.stream</groupId>
  <artifactId>stax-api</artifactId>
  <version>1.0</version>
</dependency>

or

implementation("javax.xml.stream:stax-api:1.0")

Is added into the application to import the missing class files.

[baywet]

Thanks for the additional information.
Anybody taking a dependency on azure XML on Android is going to face the same issue.
Shouldn't this dependency be added to the XML package?

[JonathanGiles]

Hi folks. The azure-xml library tries to be as lightweight as possible, so bringing in dependencies is by default not something we would like to do. This is even more the case as Android is not our primary target for this library (it's a nice-to-have at best). I would recommend that downstream libraries that depend on azure-xml bring in the dependency directly itself.

[baywet]

@alzimmermsft while looking into that further, I realized that the dependency you suggested was deprecated in favor of this one (source)

@JonathanGiles while I understand your team is not looking to expand their support burden with android applications, I think this issue outlines a broader gap: If android is not supported, this should probably be mentioned somewhere. Both to set customers expectations, and so other teams depending on this library can provide a rationale as to why they don't support it themselves.

If android is indeed supported, having CI to prevent regressions like this one would go a long way to provide a reliable experience to anyone who takes a dependency on libraries here. Or at the very least, a list of "additional things that are needed for android" is maintained somewhere for reference.

It seems abnormal to me that as a consumer of a library, I'd need to add additional dependencies for my direct dependencies, keeping the list and versions in sync would probably be a huge pain. Other libraries are usually self sustaining (they bring everything they need) and/or provide variants (e.g. google guava with the -android variants).

As for the size argument here, I'm not sure optimizing for performance is relevant when functionality is broken. Especially when you consider that xml is a dependency of core, which is pretty much a dependency of everything here as far as I can tell. In a server/desktop context, we're talking about a 127kb jar, in a mobile application, this can seem like a lot, until you remember the android SDK does trimming of the application binaries anyway.