I'm trying to migrate existing Karate project from 0.8.0 to 0.9.5
but facing some issues like below
1)None of the below imports are working, Need to figure it out equalling ones from 0.9.5
Looking for help from other, who has already tried this
import com.intuit.karate.cucumber.CucumberUtils;
import com.intuit.karate.cucumber.FeatureWrapper;
import com.intuit.karate.cucumber.KarateFeature;
import com.intuit.karate.cucumber.KarateJunitAndJsonReporter;
import com.intuit.karate.cucumber.KarateJunitFormatter;
import com.intuit.karate.cucumber.KarateReporter;
import com.intuit.karate.cucumber.KarateRuntime;
import com.intuit.karate.cucumber.KarateRuntimeOptions;
import com.intuit.karate.cucumber.KarateStats;
import com.intuit.karate.filter;
2)import com.intuit.karate.cucumber.CucumberRunner;- stating as Deprecated already, need to know replacement of this, my baseClass extends CucumberRunner.
3)also need to know replacement for below also
import com.intuit.karate.cucumber.FeatureFilePath;
import com.intuit.karate.cucumber.FeatureWrapper;
import com.intuit.karate.ScriptContext;
above imports are using in parsing Feature file
public static FeatureFilePath parseFeaturePath(File file) {
Please suggest tips to get this migration done successfully.
Thank you,
Jay
Sorry, only KarateStats was designed as a public API which is replaced by com.intuit.karate.Results. And CucumberRunner is replaced by com.intuit.karate.Runner. These are clearly mentioned in the release notes for 0.9.0.
The core of Karate was completely written and things like the KarateFeature and FeatureWrapper don't even exist anymore. I would say whoever decided to use or extend these classes made a very bad decision, and we never documented or encouraged any such approach. All the best !
Related
I encountered this line of code in a vue project here https://github.com/InfinetyEs/Nova-Filemanager/blob/c6595c29e23cab01be6b7e37a069b13844397c91/resources/js/modules/Image.vue#L42:
import Viewer from 'v-viewer/src/component.vue';
I know from other examples that v-viewer is the dependency, so src/component.vue isn't part of this project. However, those other examples are only importing the dependency, i.e. import Viewer from 'v-viewer'.
The issue I'm facing is that npm run dev is complaining that it cannot find the dependency and I have practically 0 experience with vue.
What is the proper way to write the above so that it is pulling component.vue from the dependency v-viewer?
Thank you!
UPDATE: I wrote this import { component } from 'v-viewer' and it compiled. Appreciate if someone can confirm and explain if what I'm doing is correct.
The project relies on v-viewer internals, which is a dangerous thing to do because they aren't guaranteed to exist.
This is the case here. There is loose version constraint, "v-viewer": "^1.4.2", and src was removed in later versions. You can either fix it to be "v-viewer": "1.4.2", or import and use it like shown in the documentation:
import { component as Viewer } from "v-viewer"
The latter solution is more preferable because this is the way the package was designed to be used without relying on its internals.
I'm upgrading django from 1.8 to 1.11 and this imports are failing
from django.core.management.sql import sql_delete
*** ImportError: cannot import name sql_delete
from django.core.management.sql import sql_all
*** ImportError: cannot import name sql_all
I was looking for the remove mention in the releases notes but I couldn't find anything.
Does anyone know when were removed and any alternative to replace it?
In Django 1.7+, the recommended approach would be to use migrate and sqlmigrate instead of syncdb and sqlall.
I don't think that the sql_all and sql_delete functions were ever a public API, therefore their removal didn't have to be mentioned in the release notes. They were removed in this commit, which was included in Django 1.9.
What does this warning mean?
It is appeared in version 1.0.0-beta-3595 for all usages of kotlin android extensions in my code.
I think they did this to support multiple build variants. For example when you have a flavour proversion and you want to use a layout from that flavour you have to use
import kotlinx.android.synthetic.proversion.activity_main.*
For the main build variant you have to use
import kotlinx.android.synthetic.main.activity_main.*
Not strictly the answer to the question 'why did they do that', but that's how to eliminate warning.
Change
import kotlinx.android.synthetic.activity_main.*
to
import kotlinx.android.synthetic.main.activity_main.*
implying that you already bumped version in build.gradle and updated IDEA (or AS) kotlin plugins.
I tried to work with CPasswordHelper and everytime I got an exception when trying to run one of its methods. I think the reason is that I didn't import the package(system.utils) that CPasswordHelper is belong to. My question is how do I do that?
If it matter I'm working with netBeans.
CPasswordHelper is a core class defined in YiiBase, you don't need import it before using.
It is added since 1.1.14, may be you should check your yii version.
I'm currently experiencing a problem of architecting the application structure and its test infrastructure.
Here's a brief overview of the layout
<GOROOT>/src/myapp/controllers/
<GOROOT>/src/myapp/controllers/account.go
...
<GOROOT>/src/myapp/models/
<GOROOT>/src/myapp/models/account.go
<GOROOT>/src/myapp/models/account_test.go
...
<GOROOT>/src/myapp/components/
<GOROOT>/src/myapp/components/comp1/
<GOROOT>/src/myapp/components/comp1/impl.go
<GOROOT>/src/myapp/components/comp1/impl_test.go
<GOROOT>/src/myapp/components/
...
<GOROOT>/src/myapp/testutil/
<GOROOT>/src/myapp/testutil/database.go
<GOROOT>/src/myapp/testutil/models.go
...
Problem 1
File myapp/testutil/models.go contains some util functions used in the models/*_test.go tests.
The util functions actually do use the package myapp/models data structures and functions. Therefore we have an import cycle: account_test.go imports testutil package, which in its turn imports models.
The only clear solution here is to keep testutil/models.go right inside of models packages at the same package something like test_utils.go, which seems a bit clumsy to me. What would deb the best walkaround in such cases?
Problem 2
testutil package has some initialization of the comp1 (let's say it's a client to a 3rd party service). When we run a test comp1/impl_test.go the testutil package is imported, and it imports comp1 package as it's responsible for initialisation of the component. Same cyclic import hell. Moving initialisation to a every individual place in the test cases seems like a duplication of code. Still looking for some elegant solutions here...
Problem 1
If package testutils just provide utility functions used during testing of package module then just put those functions into models/testutils_test.go: Now these utility function will be included when running the models/*_test.go tests. No import cycle any longer.
This is your "only clear solution" and I cannot see anything "clumsy" with it.
Problem 2
Import cycle: Same as above.
Initialization: Your comp1/impl_test.go can provide a func init() so no need for duplicated code.
(The standard library is good source of how to test different stuff. IMHO code duplication in testing code is not one of the seven deadly sins.)