Commons: incorrect MavenPublication configuration

tom93 commented 3 months ago

Checklist

[X] I can reproduce the bug with the latest versions.
[X] I made sure that there are no existing issues - open or closed - to which I could contribute my information.
[X] I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
[X] I have read the FAQs inside the app (Menu -> About -> FAQs), in the README and my problem isn't listed.
[X] I have taken the time to fill in all the required details. I understand that the bug report may get dismissed otherwise.
[X] This issue contains only one bug.

Affected Android/Custom ROM version

N/A

Affected device model

N/A

How did you install the apps?

None

Which apps are affected?

No response

Steps to reproduce the bug

When I try to build one of the apps against a local version of Commons (using Maven's local repository) I run into errors. I think it's due to an issue with the configuration of the MavenPublication task, but maybe I'm just doing something wrong -- how do you normally build the apps against a locally-modified version of Commons?

Here are the steps I've been using:

In Commons, edit gradle/libs.versions.toml and change app-version-versionName to something unique (e.g. "1.0.0-local").
In Commons, run ./gradlew publishToMavenLocal
In the app, edit gradle/libs.versions.toml and change the commons = "..." line to the same version. Also edit settings.gradle.kts and insert mavenLocal() at the top of the dependencyResolutionManagement section.
In the app, build using ./gradlew assembleDebug

Expected behavior

It should succeed.

Actual behavior

It fails with:

> Task :app:dataBindingMergeDependencyArtifactsCoreDebug FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:dataBindingMergeDependencyArtifactsCoreDebug'.
> Could not resolve all files for configuration ':app:coreDebugCompileClasspath'.
   > Could not find org.fossify:commons:1.0.0-local.
     Required by:
         project :app

If I add --debug then I get:

[DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver] Attempting to resolve component for org.fossify:commons:1.0.0-local using repositories [MavenLocal, Google, MavenRepo, maven]
[DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.DefaultExternalResourceArtifactResolver] Loading file:/home/user/.m2/repository/org/fossify/commons/1.0.0-local/commons-1.0.0-local.pom
[DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.ExternalResourceResolver] No meta-data file or artifact found for module 'org.fossify:commons:1.0.0-local' in repository 'MavenLocal'.
[DEBUG] [org.gradle.api.internal.artifacts.ivyservice.modulecache.PersistentModuleMetadataCache] Recording absence of module descriptor in cache: org.fossify:commons:1.0.0-local [changing = false]
[DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleComponentRepository] Detected non-existence of module 'org.fossify:commons:1.0.0-local' in resolver cache 'Google'
[DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleComponentRepository] Detected non-existence of module 'org.fossify:commons:1.0.0-local' in resolver cache 'MavenRepo'
[DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleComponentRepository] Detected non-existence of module 'org.fossify:commons:1.0.0-local' in resolver cache 'maven'
[DEBUG] [org.gradle.api.internal.artifacts.repositories.resolver.DefaultExternalResourceArtifactResolver] Loading https://dl.google.com/dl/android/maven2/org/fossify/commons/1.0.0-local/commons-1.0.0-local.pom
[DEBUG] [org.gradle.internal.resource.transfer.DefaultCacheAwareExternalResourceAccessor] Constructing external resource: https://dl.google.com/dl/android/maven2/org/fossify/commons/1.0.0-local/commons-1.0.0-local.pom
[DEBUG] [org.gradle.cache.internal.DefaultCacheCoordinator] Creating new cache for metadata-2.106/resource-at-url, path /home/user/.gradle/caches/modules-2/metadata-2.106/resource-at-url.bin, access org.gradle.cache.internal.DefaultCacheCoordinator@571e51d5
[DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Opening cache resource-at-url.bin (/home/user/.gradle/caches/modules-2/metadata-2.106/resource-at-url.bin)
[DEBUG] [org.gradle.internal.resource.transport.http.HttpResourceAccessor] Constructing external resource: https://dl.google.com/dl/android/maven2/org/fossify/commons/1.0.0-local/commons-1.0.0-local.pom
[DEBUG] [org.gradle.internal.resource.transport.http.HttpClientHelper] Performing HTTP GET: https://dl.google.com/dl/android/maven2/org/fossify/commons/1.0.0-local/commons-1.0.0-local.pom

Screenshots/Screen recordings

No response

Additional information

When I look in ~/.m2/repository, I the .pom file is actually in ~/.m2/repository/org/fossify/commons/release/1.0.0-local/release-1.0.0-local.pom and has the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- ...  -->
  <!-- do_not_remove: published-with-gradle-metadata -->
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.fossify.commons</groupId>
  <artifactId>release</artifactId>
  <version>1.0.0-local</version>
  <packaging>aar</packaging>
  <dependencies>
    ...

For comparison, https://jitpack.io/org/fossify/commons/b34aef8104/commons-b34aef8104.pom has the following contents (note that different groupId and artifactId):

<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <!-- do_not_remove: published-with-gradle-metadata -->
<modelVersion>4.0.0</modelVersion>
  <groupId>org.fossify</groupId>
  <artifactId>commons</artifactId>
  <version>b34aef8104</version>
  <packaging>aar</packaging>
  <dependencies>
    ...

This makes me think that the Maven configuration is incorrect. The following patch fixes the problem for me (but I have no idea if it will cause problems with jitpack):

diff --git a/commons/build.gradle.kts b/commons/build.gradle.kts
--- a/commons/build.gradle.kts
+++ b/commons/build.gradle.kts
@@ -59,13 +59,13 @@
     sourceSets {
         getByName("main").java.srcDirs("src/main/kotlin")
     }
-    namespace = libs.versions.app.version.groupId.get()
+    namespace = "org.fossify.commons"
 }

 publishing.publications {
     create<MavenPublication>("release") {
         groupId = libs.versions.app.version.groupId.get()
-        artifactId = name
+        artifactId = libs.versions.app.version.artifactId.get()
         version = libs.versions.app.version.versionName.get()
         afterEvaluate {
             from(components["release"])
diff --git a/gradle/libs.versions.toml b/gradle/libs.versions.toml
--- a/gradle/libs.versions.toml
+++ b/gradle/libs.versions.toml
@@ -51,7 +51,8 @@
 app-build-javaVersion = "VERSION_17"
 app-build-kotlinJVMTarget = "17"
 #versioning
-app-version-groupId = "org.fossify.commons"
+app-version-groupId = "org.fossify"
+app-version-artifactId = "commons"
 app-version-appId = "org.fossify.commons.samples"
 app-version-versionCode = "1"
 app-version-versionName = "1.0.0"

I had to change how the namespace is set in commons/build.gradle.kts because it is no longer equal to the groupId. I'm not sure what the best practice is with respect to hard-coding (like I did for the namespace) or using a string from gradle/libs.versions.toml (like in MavenPublication); personally I think gradle/libs.versions.toml somewhat overkill and not really the right place for these non-dependency constants.

naveensingh commented 3 months ago

@tom93 check settings.gradle.kts in the the gallery.

tom93 commented 3 months ago

Thanks. I tried it on File-Manager but got some errors (e.g. in ChangeViewTypeDialog.kt, useForThisFolderDivider had type DividerBinding instead of View), sounds very similar to the binding issues you ran into in https://github.com/SimpleMobileTools/Simple-Gallery/pull/2967. I don't have a clue why, do you have any insights? (Since the Maven local repository works, my take is that it's not worth changing the code to make includeBuild() work unless includeBuild() is uncovering an actual bug.)

And is it okay if I still create a PR with my patch from above? The existing Maven configuration seem plain wrong.

naveensingh commented 3 months ago

got some errors (e.g. in ChangeViewTypeDialog.kt, useForThisFolderDivider had type DividerBinding instead of View), sounds very similar to the binding issues you ran into in https://github.com/SimpleMobileTools/Simple-Gallery/pull/2967. I don't have a clue why, do you have any insights?

Yep, it's the same issue. I never investigated it, it probably has something to do with how bindings are generated.

is it okay if I still create a PR with my patch from above?

Sure but please do test the Jitpack build once, you can trigger a build at https://jitpack.io/#org.fossify/commons or https://jitpack.io/#tom93/commons in your case.

tom93 commented 3 months ago

@naveensingh I created a PR (FossifyOrg/Commons#46) with an improved version of the patch from above that also fixes composite builds (and moves the values out of gradle/libs.versions.toml). I'm not sure how to trigger the JitPack build (it asks me to log in), can you please check for me? The commit is f0d9cd9f6f.

Aside: I found and wrote a patch for a serious issue in the Messages app relating to deletion, please give that priority over my other PRs!

naveensingh commented 2 months ago

@tom93 It works™

tom93 commented 2 months ago

Yay, thanks!

FossifyOrg / General-Discussion