Can not run single test after upgrading cucumber-js to v3 - protractor

I'm upgrading cucumber-js library in my project from v 1.3.2 to 3.0.3.
For now most things work as expected, but I found out that while I'm trying to run a single test scenario old way:
./node_modules/protractor/bin/protractor ./tmp/config/devDirectConnect.js --specs ./features/redirects.feature:20
the whole feature file runs.
Do you know what is a reason and maybe the solution?
Rgs

The syntax has changed since 1.x, and my answer to this question should also answer this one, as I show the syntactic changes needed to upgrade to 2.x or 3.x in the examples that I give there.
If there are any other syntactical errors, update your question and post a comment below to notify me, and I'll update my answer.

Fix for the issue has been released in cucumber-js 3.1.0:
https://github.com/cucumber/cucumber-js/blob/master/CHANGELOG.md#310-2017-10-25

Related

Drools 6.5: java.lang.RuntimeException: Illegal class for global. Expected [com.user.PersonAccount], found [com.user.PersonAccount]

I'm using the "org.springframework.boot:spring-boot-devtools" dependency in my Grails application for the live reload of the application on code change. The problem is, it seems that this dependency is causing some conflict with drools.
On kieSession.setGlobal(name, value) in my code, I get the following error:
java.lang.RuntimeException: Illegal class for global. Expected [com.user.PersonAccount], found [com.user.PersonAccount]
Removing the "spring-boot-devtools" dependency fixes the issue but I need this dependency for the live reload, it's important in development.
Anyone knows why this dependency is causing this conflict? and what I can do to fix it or as a workaround?
Thanks in advance!
To whoever might have the same issue in future, the issue is already reported and described before: https://issues.redhat.com/browse/DROOLS-1540 and a fix has been included in drools starting from version 7.26.0.Final (https://github.com/kiegroup/drools/commit/85c5308031a84a0ac4086c1df363bb1b4b3c6af9)
If you don't want to upgrade to the latest version of drools, there's still a workaround to fix the issue which is already mentioned on the devtools page of spring-boot (https://docs.spring.io/spring-boot/docs/current/reference/html/using.html#using.devtools.restart.customizing-the-classload).
I added META-INF/spring-devtools.properties with the jars that I want to include in the restart classloader (mainly the drools + kie jars) & the issue is fixed.
When the devtools recompile the class, the byte code no longer matches the byte code from your rules. It's not doing a very good job of warning you, but what it's trying to say is "you are trying to give me a com.user.PersonAccount instance, but it doesn't look like what I know a com.user.PersonAccount instance should look like."
Therefore if you insist on using this tool which will recompile things on the fly, you'll need to also recompile and reload the rules on the fly. Or not use spring-boot-devtools.

Scala library, Bintray not syncing versions to JCenter

I found a similar issue but couldn't understand any action to take. I have two open-source scala libraries - I published the second one just yesterday. Everything looks good on the Bintray repo, but only one version makes it to jCenter.
https://dl.bintray.com/ticofab/maven/io/ticofab/ :
aws-request-signer_2.10/
aws-request-signer_2.11/
aws-request-signer_2.12/ <-- latest scala version, missing later
reactive-kraken_2.11/
reactive-kraken_2.12/ <-- latest scala version, missing later
http://jcenter.bintray.com/io/ticofab/ :
aws-request-signer_2.11/
reactive-kraken_2.11/
Is there a way I can solve this? Thanks.
Thank you for your submitting this issue.
We have managed to resolve the issue you were experiencing. The issue occurred due to a bad link to JCenter.
Usually in order to add packages to JCenter, we add only packages under 'groupID/groupID/artifactID'. Since Scala packages are different and they contain versions of their own we needed to change the link to groupID only without artifactID (groupID/groupID. i.e /io/ticofab).
This means that all artifactIDs (reactive-kraken_2.11, reactive-kraken_2.12, aws-request-signer_2.10, aws-request-signer_2.11, aws-request-signer_2.12) are now approved and synced to JCenter.
We hope this clarifies. Please let us know if you encounter any other issues.
Best Regards,
Yonatan Brand
JFrog Support

Troubleshoot option not printing plugin for protractor

I am trying to find out if my plugin is being loaded for my protractor tests. The plugin is protractor-istanbul-plugin but when I enter protractor myConf.js --troubleshoot on the command line it does not print out the data that it is said to from the accepted answer from this question. Am I missing something in my code maybe? I can't find anything that details what I should be doing other than what I already am.
I think --troubleshoot flag is being broken since version 3.2.1 (experimentally determined).
I've created an issue in Protractor issue tracker to confirm if this is a bug:
Is troubleshoot flag still working?
This is now fixed in "trunk" and will be released in the next version (4.0.5).

Eclipse/MapReduce plugin

I've been searching for a MapReduce plugin for eclipse, but most of them didn't work for me. The only one that did work had the old API's template when creating Mappers/Reducers/Drivers.
So I thought I'll compile one myself, which unfortunately uses the same "old API" as the default template which gives errors. Even with the newest alpha and beta (2.0.3 and 2.0.4) versions of Hadoop.
I got it working. I've changed the source of $HADOOP_HOME/src/contrib/eclipse_plugin and then compiled it with Hadoop 1.2.0. I thought I'd share it but didn't know where. The only place that came to my mind was StackOverflow, so sorry if this isn't the place.
So here it is, Hadoop Eclipse Plugin with the new API template:
https://www.dropbox.com/s/y990pp610t3edfo/hadoop-eclipse-plugin-1.2.0-newapi.jar
If someone wants to compile it himself I'll post the source codes too, which are only 3 more *.java files. Just ask.

MonoTouch - System.Reflection.Emit.ModuleBuilder error

I am trying to test my app in IPhone (IOS 5) and I get the following error. It works in simulator without any issues.
I am referencing an external library (NewtonSoft.Json.Monotouch.dll) which seems to be using System.Reflection.Emit.ModuleBuilder. Is there a way to overcome this issue? Any help regarding this is much appreciated.
" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Core.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Runtime.Serialization.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Web.Services.dll" -r "/Users/test/application/libraries/Newtonsoft.Json.MonoTouch.dll" -linksdkonly -sdk "5.0" Framework is: /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk
Copied
/Users/test/application/bin/iPhone/Release/Unleashed.app
Could not link assemblies: Mono.Linker.ResolutionException: Can not resolve reference: System.Reflection.Emit.ModuleBuilder
Thanks
UPDATE:
Alright, I downloaded the latest NewtonSoft.Json source code from link, compiled the project and dropped the dll into my project. I still have the same issue. I did figure out the class that refers to System.Reflection.Emit. It is DynamicWrapper class in the Utilities folder.
I saw a similar issue posted in another blog link. The responded to the question suggests to set the Liner behavior to "Link all assemblies". Can anyone explain how to set this?
Newtonsoft.Json.MonoTouch.dll is known to work with MonoTouch. I've seen/compiled many application using it myself.
It's likely that you are either using an old or a mis-compiled version of assembly (e.g. missing defines). Difficult to say which without knowing it's origin. Try to track a newer version (or edit your question to include where it comes from).
Note: The fact that it works with the simulator is because a different mscorlib.dll is used to allow JITting (instead of AOTing) the managed code. This allows the simulator builds to be much faster than device builds.
Instead of compiling the Newtonsoft.Json.MonoTouch.dll, which did not work for me either, I downloaded the source code from github and added the project to my solution in MonoTouch and compiled the solution. Only then everything worked. (and of course as popou mentioned do not forget the MONOTOUCH;NET35;SILVERLIGHT options.)