ncalexan / mozilla-central-geckoview

Package mozilla-central's GeckoView into an Android aar in a maven repository
Mozilla Public License 2.0
0 stars 1 forks source link

Gradle can not expand generated AAR #1

Open dominikschreiber opened 10 years ago

dominikschreiber commented 10 years ago

Hi there,

I'm using the GeckoView in a Android Gradle project as described in your blog post. However, Gradle builds fail while unpacking the generated aar file:

Execution failed for task ':app:prepareOrgMozillaGeckoviewLibrary20141016030201Library'.
> Could not expand ZIP '/Users/dominik/.gradle/caches/modules-2/files-2.1/org.mozilla.geckoview/library/20141016030201/855055fac50a4dc9c7896b6b4785bfc8c04f8903/library-20141016030201.aar'.

The stack trace (not the full... dispensable parts omitted) is

org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':app:prepareOrgMozillaGeckoviewLibrary20141016030201Library'.
    at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
    [...]
Caused by: org.gradle.api.GradleException: Could not expand ZIP '/Users/dominik/.gradle/caches/modules-2/files-2.1/org.mozilla.geckoview/library/20141016030201/855055fac50a4dc9c7896b6b4785bfc8c04f8903/library-20141016030201.aar'.
    at org.gradle.api.internal.file.archive.ZipFileTree.visit(ZipFileTree.java:101)
    [...]
Caused by: java.io.IOException: central directory is empty, can't expand corrupt archive.
    at org.apache.tools.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:458)
    [...]

The code that throws this exception looks like this:

if (sig != CFH_SIG && startsWithLocalFileHeader()) {
  throw new IOException("central directory is empty, can't expand"
                      + " corrupt archive.");
}

I've tried this for every version the Mozilla Jenkins offers (Build 125 to 133), same song everywhere.

My gradle file looks like

// ...
repositories {
  main {
    url 'https://ci.mozilla.org/job/mozilla-central-geckoview/mozilla-central_Maven_Repository'
  }
}
dependencies {
  // ...
  compile 'com.android.support:support-v4:20.+'
  compile 'org.mozilla.geckoview:library:+' // I used hardcoded version numbers here to test
}

Assuming I'm not doing it wrong, could it be that the generated AAR file is corrupt?

ncalexan commented 10 years ago

Hey! Glad you're trying GeckoView.

Assuming I'm not doing it wrong, could it be that the generated AAR file is corrupt?

I did see, infrequently, that the web server (Jenkins?) backing ci.mozilla.org would serve corrupt AAR files.

Can you verify that you can unzip the AAR file in your Gradle cache?

Can you try to manually download a test AAR, stick it into your Gradle configuration (or put it in your Gradle cache), and see what happens?

I chased this to a transient web server problem triggered by Gradle's downloading code, but no further. Let me know what you find!

dominikschreiber commented 10 years ago

I just tested todays nightly build (20141016030201, downloaded during gradle build) and unzipping it manually works like a charm.

I then downloaded the file manually.

First thing to note is that the two files have different shasums (gradle-downloaded: 855055fac50a4dc9c7896b6b4785bfc8c04f8903, manually downloaded: 771712b8a95f5ce286ad75433a69613308e95014).

Then I moved the manually downloaded file into the gradle cache and restarted the build. The build complains about missing checksums

Checksum missing at https://ci.mozilla.org/job/mozilla-central-geckoview/mozilla-central_Maven_Repository/org/mozilla/geckoview/library/20141016030201/library-20141016030201.aar.sha1 due to: Illegal embedded sign character

and downloads the geckoview library again

Download https://ci.mozilla.org/job/mozilla-central-geckoview/mozilla-central_Maven_Repository/org/mozilla/geckoview/library/20141016030201/library-20141016030201.aar

Finally, the build succeeds. Even removing the manually downloaded file from the cache and restarting the gradle build succeeds (the new gradle-downloaded aar has the same shasum as the manually downloaded).

So, I'd blame it on the web server who did serve a corrupted file before.

ncalexan commented 10 years ago

On Thu, Oct 16, 2014 at 8:31 AM, Dominik Schreiber <notifications@github.com

wrote:

I just tested todays nightly build (20141016030201, downloaded during gradle build) and unzipping it manually works like a charm.

I then downloaded the file https://ci.mozilla.org/job/mozilla-central-geckoview/mozilla-central_Maven_Repository/org/mozilla/geckoview/library/20141016030201/library-20141016030201.aar manually.

First thing to note is that the two files have different shasums (gradle-downloaded: 855055fac50a4dc9c7896b6b4785bfc8c04f8903, manually downloaded: 771712b8a95f5ce286ad75433a69613308e95014).

Then I moved the manually downloaded file into the gradle cache and restarted the build. The build complains about missing checksums

Checksum missing at https://ci.mozilla.org/job/mozilla-central-geckoview/mozilla-central_Maven_Repository/org/mozilla/geckoview/library/20141016030201/library-20141016030201.aar.sha1 due to: Illegal embedded sign character

and downloads the geckoview library again

Download https://ci.mozilla.org/job/mozilla-central-geckoview/mozilla-central_Maven_Repository/org/mozilla/geckoview/library/20141016030201/library-20141016030201.aar

Finally, the build succeeds. Even removing the manually downloaded file from the cache and restarting the gradle build succeeds (the new gradle-downloaded aar has the same shasum as the manually downloaded).

So, I'd blame it on the web server who did serve a corrupted file before.

Thanks for testing so thoroughly. Your experience is exactly like mine, and yes, I blame the ci.mozilla.org web server. I'll open a ticket for Mozilla's ops. Glad it's working for you now.