Android Build Failure When Locking Dependencies `Could not resolve app.notifee:core:+.`

[Jad-Jbara]

Description

Build fails when locking gradle dependencies.

Note

this started happening after upgrading to "react-native": "0.74.3", where Gradle was upgraded to version 8.

Error Message

> Could not resolve all artifacts for configuration ':app:developmentDebugRuntimeClasspath'.
   > Could not resolve app.notifee:core:+.
     Required by:
         project :app > project :notifee_react-native
      > Failed to list versions for app.notifee:core.
         > Unable to load Maven meta-data from file:/Users/jadjbara/projects/......./node_modules/@notifee/react-native/android/libs/app/notifee/core/maven-metadata.xml.
            > org.xml.sax.SAXNotRecognizedException: Property 'http://javax.xml.XMLConstants/property/accessExternalSchema' is not recognized.

Project Specifics

• react-native version: 0.74.3
• notifee version: 7.8.2

Steps to Reproduce

1. Enable gradle dependencies locking
   You can follow the guide on the official Gradle docs
   Steps are below:
   Add the following to your root android/build.gradle directory.

subprojects {
    configurations.all {
        it.resolutionStrategy.activateDependencyLocking()
    }
}

dependencyLocking {
    lockAllConfigurations()
}

2. Build the app with adding --write-locks to the command for example in our case we are running ./android/gradlew -p ./android androidDependencies --write-locks

R&D

According to Gradle, depending on version 8 will lead to builds failing in case a dependency still uses legacy xml parsers.

How to Bypass the Error

The only way I could actually bypass the error was by disabling dependency locking in the project, which is not ideal since we would like to keep this in our repo.

Any idea how this can be resolved? Thanks!

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[Jad-Jbara]

Bump

[mikehardy]

Hey @Jad-Jbara

Did you try:

If you are unable to upgrade XML parsers coming from your build logic dependencies, you can force the use of the XML parsers built into the JVM. In OpenJDK, for example, this can be done by adding the following to gradle.properties:

from the doc you linked https://docs.gradle.org/current/userguide/upgrading_version_8.html#xml_parsing_now_requires_recent_parsers ?

Did you try ignoring this specific dependency as described in https://docs.gradle.org/current/userguide/dependency_locking.html#ignoring_dependencies ?

It is curious to me that turning on locking would cause XML secure parsing to be enabled - they seem orthogonal
It is also curious to me that the maven-publish plugin - an official gradle plugin as far as I can tell? - would not be updated in concert with XML secure parsing such that if publishing to a local repo (as we do) they would not also publish a POM XML that either had all necessary items internalized or had them localized in the local repo for local reference

Unsure what to do here but happy to take a PR

Things I'm unclear on:

• will this reproduce in our example app if we update it to current gradle, without rebuilding the local .aar file in the local repository?
• will this go away if we rebuild the local .aar file with a newer gradle to do the local publish, even if we are using newer gradle in the example/test app?

[Jad-Jbara]

Thank you for your response, @mikehardy!

Due to time constraints, we decided to temporarily remove dependency locking from our repo to keep things moving. I hadn't initially noticed the part of the documentation about ignoring the dependency, so I haven't had a chance to try that approach.

Regarding your first suggestion:

If you are unable to upgrade XML parsers coming from your build logic dependencies, you can force the use of the XML parsers built into the JVM. In OpenJDK, for example, this can be done by adding the following to gradle.properties:

I did attempt to force the new XML parsers, but unfortunately, encountered several other build errors. I began looking into them but, given the tight timeline, wasn’t able to fully troubleshoot and resolve the issues.

Once I have some free time, I plan to revisit this, try and create a minimal reproducer, and hopefully address the questions you've raised. Thanks again for your insights!

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[mujehoxe]

Facing the same issue, using expo

[mikehardy]

This will most likely not be possible until I change up the structure of how part of this library's source is distributed from compiled/AAR to copy-on-build / publish-all-source

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[mikehardy]

This one is important for reproducible builds etc and I have a technical means to do it, I know it's slow-going here on the maintenance side but I swear there is progress.

I've just late last week gotten the Apple information I needed to set up push notifications and stuff, and now I'm working through Firebase Console issues in order to get the testing rig here fully ready to go for development. That's just a natural pre-requisite to actually doing all these changes, so please keep bearing with me