Policy regarding JAR dependencies in GitLab Maven package registry

Scenario: One of my apps relies on an external JAR, which I also maintain. It is not on Maven Central but the source code is in a GitLab repository. I have set up a pipeline which builds the JAR after every push and uploads it to the project’s Maven package registry on GitLab. Gradle/Maven are configured to pull the dependency from there.

Would that setup satisfy F-Droid’s requirements regarding building everything from source/not including any unverifiable blobs?

1 Like

I don’t know if that satisfies the requirement. I believe F-Droid will need to build your jar when it tries to build your app (no pre-built blobs allowed).

For the type of scenario you describe I’m using jitpack to build the dependencies I maintain in other repos. Its just another line in your gradle (easy, as if it really were published to MavenCentral). This works fine w/ F-Droid.

2 Likes

Would that setup satisfy F-Droid’s requirements

Not really.

You can either switch to JitPack or compile the JAR in the F-Droid recipe.

2 Likes

Thanks, I’ll look into JitPack.

Out of curiosity: how do you treat MavenCentral in that respect? I see it has both source and pre-built jars but never cared to look what actually happens when I use them (does my toolchain download the source and build it locally, or does it use the prebuilt JAR?)—how do you verify for these that source that ends up in the APK is what was published?

1 Like

how do you verify for these that source that ends up in the APK is what was published?

We don’t. That’s indeed a problem. We use a black list of artifacts that we know are non-free, but ideally we’d like to build everything from source.

1 Like

Example of Maven Central empty source : https://repo1.maven.org/maven2/com/amap/api/location/4.9.0/ location-4.9.0-sources.jar :560 bytes (?!)

1 Like