Cucumber-JVM v1.2.3 (and v1.2.4) fails to build for Android

[brasmusson]

As reported on the mailing list, Cucumber-JVM release v1.2.3 (and v1.2.4) fails to build for Android. The issue occurred when Cucumber-JVM-Deps was updated to use XStream v1.4.8, which contains two classes (com.thoughtworks.xstream.mapper.LambdaMapper.class and com.thoughtworks.xstream.converters.reflection.LambdaConverter.class) compiled to the byte code version of Java8 (major version 52), and classes of that byte code version cannot be included in an Android dex file.

cucumber-attic/cucumber-jvm-deps#4 fixes the problem by filtering out those two classes from the Cucumber-JVM-Deps jar file.

[aslakhellesoy]

I'll take a look at this. I wonder - is there a way this could have been discovered by an automated test you think?

[brasmusson]

Building the integration test for cucumber-android, that is the project examples/android/android-test would have discovered this. The caveat is that to build it you need a Android SDK installed, and to run it you also need an Android emulator running (or an Android device connected).

Now Travis have better support for Android compared to when we used and Android SDK to build cucumber-android itself - but still beta they write.

I just rebased the PR where I worked on running the integration test (examples/android/android-test) and example (examples/android/cukeulator + examples/android/cukeulator-test) for Android, and as expected the issue is disclosed on Travis

[mikeholler]

@aslakhellesoy this can absolutely be discovered by an automated test. We use Animal Sniffer for all of our tests. It allows us to use the Java 7 language features while making sure we don't use any Java 7 libraries.

[aslakhellesoy]

Animal sniffer doesn't even have a README. That smells like abandonware to me.

[mikeholler]

It is not abandonware. The Codehaus website shutdown recently but the code
has been forked and is being maintained on GitHub. Unfortunately, I believe
the user doc was lost in the process. Plenty of popular projects still use
and depend on it, like square's OkHttp.
On Aug 3, 2015 16:35, "Aslak Hellesøy" [email protected] wrote:

Animal sniffer doesn't even have a README. That smells like abandonware to
me.

—
Reply to this email directly or view it on GitHub
#893 (comment)
.

[mikeholler]

Here is a link to OkHttp's usage. Animal Sniffer is very stable from my
experience (never had a single problem with it), although I understand your
hesitation to adopt.

https://github.com/square/okhttp/pull/194/files
On Aug 3, 2015 17:28, "Mike Holler" [email protected] wrote:

It is not abandonware. The Codehaus website shutdown recently but the code
has been forked and is being maintained on GitHub. Unfortunately, I believe
the user doc was lost in the process. Plenty of popular projects still use
and depend on it, like square's OkHttp.
On Aug 3, 2015 16:35, "Aslak Hellesøy" [email protected] wrote:

Animal sniffer doesn't even have a README. That smells like abandonware
to me.

—
Reply to this email directly or view it on GitHub
#893 (comment)
.

[mikeholler]

Looks like someone did make a documentation site:
http://www.mojohaus.org/animal-sniffer/
On Aug 3, 2015 17:32, "Mike Holler" [email protected] wrote:

Here is a link to OkHttp's usage. Animal Sniffer is very stable from my
experience (never had a single problem with it), although I understand your
hesitation to adopt.

https://github.com/square/okhttp/pull/194/files
On Aug 3, 2015 17:28, "Mike Holler" [email protected] wrote:

It is not abandonware. The Codehaus website shutdown recently but the
code has been forked and is being maintained on GitHub. Unfortunately, I
believe the user doc was lost in the process. Plenty of popular projects
still use and depend on it, like square's OkHttp.
On Aug 3, 2015 16:35, "Aslak Hellesøy" [email protected] wrote:

Animal sniffer doesn't even have a README. That smells like abandonware
to me.

—
Reply to this email directly or view it on GitHub
#893 (comment)
.

[dkowis]

Abandonware isn't inherently bad, as long as it works, when it stops working, we can do something else. Perhaps by then the travis android support will be sufficient.

I bet this works by checking the bytecode to see what JDK your stuff is compiled against and extends that test to the dependency jar files you've got.

That's probably stable enough to keep using, even if it is abandonware.

[dkowis]

I bet I can probably make this happen pretty quickly. Perhaps that'll be something I get to this week, if it doesn't get gotten to first by someone else :)

[emaillenin]

What is the latest version that is known to work?

I was adding support for Cucumber to my existing android app. Added the following JAR files:

• cucumber-android-1.2.4.jar
• cucumber-core-1.2.4.jar
• cucumber-html-0.2.3.jar
• cucumber-java-1.2.4.jar
• cucumber-junit-1.2.4.jar
• cucumber-jvm-deps-1.0.5.jar
• gherkin-2.12.2.jar

Getting this error for "./gradlew --info clean assembleDebug":

processing cucumber/deps/com/thoughtworks/xstream/mapper/DynamicProxyMapper$DynamicProxy.class...
processing cucumber/deps/com/thoughtworks/xstream/mapper/PackageAliasingMapper$1.class...
processing cucumber/deps/com/thoughtworks/xstream/mapper/LambdaMapper.class...

Unknown source file : UNEXPECTED TOP-LEVEL EXCEPTION:
Unknown source file : com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000)
Unknown source file :   at com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:472)
Unknown source file :   at com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)
Unknown source file :   at com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)
Unknown source file :   at com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251)
Unknown source file :   at com.android.dx.command.dexer.Main.processClass(Main.java:704)
Unknown source file :   at com.android.dx.command.dexer.Main.processFileBytes(Main.java:673)
Unknown source file :   at com.android.dx.command.dexer.Main.access$300(Main.java:83)
Unknown source file :   at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:602)
Unknown source file :   at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
Unknown source file :   at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
Unknown source file :   at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
Unknown source file :   at com.android.dx.command.dexer.Main.processOne(Main.java:632)
Unknown source file :   at com.android.dx.command.dexer.Main.processAllFiles(Main.java:510)
Unknown source file :   at com.android.dx.command.dexer.Main.runMonoDex(Main.java:280)
Unknown source file :   at com.android.dx.command.dexer.Main.run(Main.java:246)
Unknown source file :   at com.android.dx.command.dexer.Main.main(Main.java:215)
Unknown source file :   at com.android.dx.command.Main.main(Main.java:106)
Unknown source file : ...while parsing cucumber/deps/com/thoughtworks/xstream/mapper/LambdaMapper.class
Unknown source file : 1 error; aborting

:app:preDexDebug FAILED
:app:preDexDebug (Thread[main,5,main]) completed. Took 7.305 secs.
Starting process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java''. Working directory: /Users/leninraj/Dropbox/Projects/duggout/duggout-android/app Command: /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java -Xmx1024M -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant -cp /Users/leninraj/Library/Android/sdk/build-tools/21.1.2/lib/dx.jar com.android.dx.command.Main --dex --verbose --output /Users/leninraj/Dropbox/Projects/duggout/duggout-android/app/build/intermediates/pre-dexed/debug/support-annotations-22.2.1-572ba533a1ff5ff170aeef85dc74e608e4256da3.jar /Users/leninraj/Library/Android/sdk/extras/android/m2repository/com/android/support/support-annotations/22.2.1/support-annotations-22.2.1.jar
Successfully started process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java''

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:preDexDebug'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output.

BUILD FAILED

Total time: 22.186 secs
PREDEX CACHE HITS:   0
PREDEX CACHE MISSES: 7
Stopped 0 compiler daemon(s).

If I remove "cucumber-jvm-deps-1.0.5.jar" from the libs directory, build works correctly. Which JAR file should I downgrade to get cucumber working for the Android App?

[emaillenin]

Downgrading to cucumber-jvm-deps-1.0.3.jar works!

[programmerdave]

Hi! So we finally figured out how to make it run correctly based on what @emaillenin said.

Just use the following setup in your build.gradle file:

dependencies {
   compile fileTree(include: ['*.jar'], dir: 'libs')
   testCompile 'junit:junit:4.12'
   compile 'com.android.support:appcompat-v7:23.1.1'

   androidTestCompile 'com.android.support:support-annotations:23.1.1'

   androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1'

   androidTestCompile ('info.cukes:cucumber-android:1.2.4') {
       exclude module: 'cucumber-jvm-deps'
   }
   androidTestCompile ('info.cukes:cucumber-picocontainer:1.2.4') {
       exclude module: 'cucumber-jvm-deps'
   }
   androidTestCompile 'info.cukes:cucumber-jvm-deps:1.0.3'
}

Hope this helps someone!

[mikeholler]

Are there any plans to permanently fix this so we don't need to manually edit this library's dependencies?

[florent37]

@programmerdave you saved my life :)

[dhoskins]

@programmerdave This information needs to be somewhere far more prominent for newcomers to this project

[urbantom]

@programmerdave You saved the day. Thx.
PS> Does the cucumber-jvm become an abandonware?
The issue seems to be well analysed and understood, but there is still only this workaround after almost two years.
Are there any other options to use Gherkin notation in Android projects?

[mikeholler]

@urbantom Yeah, I'm a little concerned about this as well. Whether or not development on Cucumber JVM is moving forward, there seems to be little interest in first-class Android support. Thankfully, I haven't noticed any major bugs with @programmerdave's suggestion so infrequently updated does not mean bad. That being said, it makes me nervous if any bugs crop up with newer Android releases.

[mpkorstanje]

At the moment the best way to get first class android support is by doing it yourself. I reckon if some one could help with #824 we'd at least stop breaking Android support. :D

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.