Gradle 7 required to build mupdf submodule

,
1

Hello,
we are using mupdf for the taz newspaper application (de.taz.android.app.free).

As the main developer of mupdf (ArtifexSoftware) is not publishing the library to a allowed repo like jcenter but only to maven.ghostscript.com ( Index of /com/artifex/mupdf/fitz ) we can’t use it for f-droid.

Thus we have a local submodule in our code to build and publish the artifacts to a local maven repo before we build our app.

Unfortunately mupdf requires Gradle 7 to build successfully and it seems like f-droid did update the gradle version used on the build system. A failing job can be seen on my personal fork: fdroid build (#5038302505) · Jobs · Johannes Dillmann / Data · GitLab
The build of the taz application a couple of month ago did just pass fine.

As we would still like to submit the taz app to f-droid i have the following questions:

  • Is it possible to use a specific gradle version to build the mupdf artifact from a submodule?
  • Is there any chance you might add the ghostscript.org repo or at least the mupdf fitz library part to the list of allowed repos in f-droid?
  • If not, do you have any tipps on how to proceed. Are you aware of any other f-droid app and how they handle the mupdf build problem?
2

Latest gradle supported is like 8.3.1 so 7 is… very supported :slight_smile:

The log says:

...
make: Leaving directory '/builds/kleingeist/fdroiddata/build/de.taz.android.app.free/thirdparty/mupdf-jni/libmupdf'
+ gradle -p ../thirdparty/mupdf-jni assembleRelease publishReleasePublicationToMavenLocal
Found 8.0 via distributionUrl
Downloading missing gradle version 8.0
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':bundleReleaseAar'.
> Could not create task ':packageReleaseAssets'.
   > Cannot use @TaskAction annotation on method IncrementalTask.taskAction$gradle_core() because interface org.gradle.api.tasks.incremental.IncrementalTaskInputs is not a valid parameter to an action method.

…which means “I’ll get gradle 8 since you said so https://github.com/die-tageszeitung/taz-neo/blob/1.7.4/gradle/wrapper/gradle-wrapper.properties#L3”

Oh, for that submodule you want gradle 7? Well…

Why can’t I click on https://github.com/die-tageszeitung/taz-neo/tree/1.7.4/thirdparty the link to mupdf-jni @ 3cfbecb ? I’d like to see that source code…

3

Ok, cloned locally to take a look, right, so, why not build in that folder so its gradle version 7 is detected?

eg:

      - pushd ../thirdparty/mupdf-jni/libmupdf
      - make generate
      - gradle -p .. assembleRelease publishReleasePublicationToMavenLocal
      - popd

maybe?

4

we used the original git repository at https://git.ghostscript.com/mupdf-android-fitz.git/ instead of the clone at github. thats why github won’t link it to this
GitHub - ArtifexSoftware/mupdf-android-fitz: Android SDK: JNI bindings

thanks for the idea with subdirectory change. i am not entirely sure how the f-droid build system works. i tried to use the gradlew wrapper in the submodule path before, but that failed because it got stripped as part of the f-droid build preparation

5 
  - versionName: 1.7.4
    versionCode: 10704900
    commit: 1.7.4
    subdir: app
    submodules: true
    sudo:
      - apt-get update
      - apt-get install -y make file
      - apt-get install -y openjdk-17-jdk-headless
      - update-java-alternatives -a
    output: build/outputs/apk/freeTazProduction/unminifiedRelease/app-free-taz-production-unminifiedRelease-unsigned.apk
    prebuild:
      - cd ../thirdparty/mupdf-jni
      - git apply ../../scripts/mupdf-mavenlocal.patch
      - touch "settings.gradle"
      - sed -i -e "s/'-j4'/'-j`nproc`'/" build.gradle
    scandelete:
      - thirdparty/mupdf-jni/libmupdf/thirdparty
    build:
      - pushd ../thirdparty/mupdf-jni/libmupdf
      - make generate
      - gradle -p .. assembleRelease publishReleasePublicationToMavenLocal
      - popd
      - export VERSION_IGNORES_DIRTY_TREE=true
      - export SENTRY_ENVIRONMENT=fdroid
      - gradle assembleFreeTazProductionUnminifiedRelease

…passes the mupdf build stage then needs Java17, added that too now

6

This ^^^ builds fine fyi

7

thanks a lot for your help :slight_smile:

i adapted it a little bit, but your tipp with changing the directories basically did the trick. i was so used to gradlew wrappers that i didnt realize the actual problem

i will open a MR in a minute with additional info to this release

1 Like