v1.0.3 fails to build

[IzzySoft]

While we were able to build v1.0.2 fine, building v1.0.3 fails:

> Task :app:processReleaseResources

> Task :app:compileReleaseJavaWithJavac
/build/repo/app/src/main/java/com/tawhid/webcapture/YouTubeCaptureActivity.java:247: error: cannot find symbol
            return BASE_URL + "?id=" + videoId + "&key=" + Config.youtube_api + "&part=snippet,statistics";
                                                           ^
  symbol:   variable Config
  location: class YouTubeCaptureActivity.FetchVideoDataTask
Note: Some input files use or override a deprecated API.

Note: Recompile with -Xlint:deprecation for details.
1 error
> Task :app:compileReleaseJavaWithJavac FAILED

FAILURE: Build failed with an exception.

It also seems the APK was not built from the commit the tag points to (7aa60e0), but rather from 43ca044 (possibly with local changes committed after the build) – not sure if that's the reason for the failure (also se #35 where we already encountered a similar issue; please always build the APK from a clean tree at the commit the tag points to).

[tawhidmonowar]

Hi, this file contains an API key, so I didn't include it in GitHub. How can I resolve this issue?

app/src/main/java/com/tawhid/webcapture/Config.java

[IzzySoft]

Just tell me the structure and the variable names (e.g. giving me a dummy example how the file should look like; I'm no Java programmer). Usually there's no need to tell me the variable content (aka the key itself), that should be rather easy to figure. Probably something like

public class Config {
  String youtube_api = "API_KEY_HERE";
}

Unfortunately, it does not seem to be that simple (yeah, I'm really no Java dev)…

[tawhidmonowar]

I added the Config.java file in this commit b378c5e

[IzzySoft]

OK, thanks! I've replaced the your_api_key with the correct API key ("AI…"). It builds now, but does not correspond to your APK. You didn't build yours from the commit the release tag points to, but (according to the vcsInfo embedded inside the APK) from 43ca044 (most likely with local, uncommitted changes) – however, if I try building from that commit, the build fails again:

> Task :app:mergeReleaseNativeLibs FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mergeReleaseNativeLibs'.
> Could not resolve all files for configuration ':app:releaseRuntimeClasspath'.
   > Could not find com.github.barteksc:AndroidPdfViewer:2.3.0.
     Searched in the following locations:
       - https://dl.google.com/dl/android/maven2/com/github/barteksc/AndroidPdfViewer/2.3.0/AndroidPdfViewer-2.3.0.pom
       - https://repo.maven.apache.org/maven2/com/github/barteksc/AndroidPdfViewer/2.3.0/AndroidPdfViewer-2.3.0.pom
       - https://jitpack.io/com/github/barteksc/AndroidPdfViewer/2.3.0/AndroidPdfViewer-2.3.0.pom
     Required by:
         project :app

After a little playing-around I finally got it to reproduce: using git reset --soft 43ca044b8a99e637b2c53612cf976202cd456785 (to adjust the embedded commit hash; this was already done automatically by the recipe updater here) and, the final step which fixed it, switching from JDK-17 to JDK-21. Oof.

Please build future releases from a clean tree at the commit the release tag points to, will you? 😉 You're also welcome to take a look at our hints on reproducible builds, where this is mentioned as the "first basic rule" (yupp, the most common cause of RBs failing is not adhering to that rule).

Btw: the build recipe here simply replaces your Config.java – all I needed was the "syntax" of that file (I see I just missed the static keyword and the package declaration, due to not having any Java programming skills). So feel free to either leave it out of the repo or leave the "dummy" in for others to replace the your_api_key with theirs. Maybe it's not the worst idea to keep the Config.java in the repo with "dummy values" so others can see how to set that and specify their own values; should your local Config.java get additional entries, please keep the one in the repo updated then (so when the build fails here, I can check and "repair"). What do you think? Shall we go that way?

[tawhidmonowar]

Yeah, that sounds like a good approach! Keeping Config.java with dummy values will make it easier for others to configure, and I'll make sure to keep it updated if there are any changes. 👍

[IzzySoft]

Thanks! Can you provide me with an APK built from a clean tree, to check against if it's RB? You can attach it here to an issue comment (just rename it to .zip so Github allows you).