Could not resolve io.mockk:mockk:1.13.2 for :shared:iosArm64Test Could not resolve io.mockk:mockk:1.13.2 for :shared:iosSimulatorArm64Test Could not resolve io.mockk:mockk:1.13.2 for :shared:iosX64Test
Found that MockK is only supported for jvm target - https://github.com/mockk/mockk/issues/950
But what i know is the unit tests we write on common shared module are meant to be run on local machine (mac/ windows) which do have have JVM installed.
Please can anyone add some light over here. Thanks
You can use mockk only in jvm test sources. If you write common code, and you have native targets, it won't work.
So, you can add jvmTest instead of commonTest and write tests in jvmTest that use mockk. However, that won't test your native code directly.
Related
Setting up a full "KMP" / "KMM" project seems like overkill, as only the commonMain/commonTest directories would be filled.
All the other templates seem to be platform-specific.
Is there something like a "pure" Kotlin library template?
It would just be a module with only commonMain and commonTest. You would need at least:
A Gradle module
Kotlin config with multiple targets in that module
Common code folders
Whether you put the app code in the same repo or have the shared code in a separate repo is up to you. I'm not sure how much simpler you can make the config, though.
One issue I think you'll run into is the need for platform-specific code on iOS because there are different interfaces for concurrency than you might want for a Kotlin-friendly (I.E. Android) environment. Same for things like default params.
My-KMP-Library
│ build.gradle.kts
└───src
└───commonMain
└───kotlin
└───mynamespace
What makes it multiplatform are the targets you specify in build.gradle.kts.
we're using https://github.com/firelyteam FHIR library in a Xamaring application.
When testing in iOS we discovered the PlatformNotSupportedException because of the use of Emit.
We then discovered we could use the Xamarin interpreter: https://devblogs.microsoft.com/xamarin/introducing-xamarin-ios-interpreter/
and it just works!
I have some questions/doubts:
is there any difference between the "Enable the mono interpreter" option or adding "--interpreter" to "Additional mtouch arguments"
is it possible to limit the interpreter to specific libraries? I'm under the impression is now globally enabled. I tried with "--interpreter=FHIR.HL7.Support" but I'm not sure it's working: inspecting the .ipa seems to containe .aotdata for everything. I was under the impression that aotdata was not produced when interpreted
can you suggest better solutions?
Thanks a lot
You can use --interpreter=assemblyname,.... to only allow the interpreter to work on just those assemblies, i.e. include the IL in only those assemblies.
We are using a Jenkins Shared Library to centralize some code for all our (scripted) pipelines. Now we factored out some Groovy code into a .jar library (written in Kotlin, compiled to be Java 8 compatible). We published this library to our in-house maven repo and now want to use it in our Shared Libary.
We are using #Grab to load our library and up until that point it works like a charm. However we are getting NoSuchMethodError's. We pinpointed it down a bit, we are using OkHttp in our Kotlin lib. OkHttp internally uses Okio. When we call methods that internally call OkHttp-Code from our pipeline, everything is fine. However when the OkHttp-Code call Okio internally, we get a NoSuchMethodError.
We already checked the published .jar file, it contains the classes with the methods that seem to be missing. Does anybody have an idea what the issue could be?
While we are at it, we can't access environment variables set on Jenkins in our Kotlin library, is there a way we can fix this?
We figured it out. The problem was, that a Jenkins plugin used an older version of okio internally. Because plugins and shared libraries somehow share the same classpath, okio did not get loaded and the version from the plugin got used, therefore the class was not present.
We fixed this by repackaging all dependencies in our .jar, so package names would not interfere and we can make sure that our specified dependencies are being used.
Looking the dependencies here you have a few problems:
OKHttp - seems to expect some Android libraries
okio - depends on the Kotlin runtime
Any calls to these will result in method not found errors unless you find a way to make them available without causing problems in Jenkins
I'm having a problem with usage of khttp library (which is supposed to work in Kotlin and provides equal to python's request's library features)
My build.gradle contains those strings:
repositories {
mavenCentral()
}
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib"
compile "com.github.jkcclemens:khttp:-SNAPSHOT"
}
Project builds with success, but importing with import khttp doesn't work
In general, I'm using kotlin as framework to IOS project, and khttp is needed to connect to longpoll server. If khttp isn't supposed to work in my case so what are my options? Using it's sources aint good idea i think
Try using this:
compile "com.github.jkcclemens:khttp:0.1.0"
And add https://jitpack.io/ as a repository
I know that I might be necrobumping, but if anyone is looking for an answer, they wouldn't be able to get it from the above.
Khttp library is build for kotlin JVM and not native. If you take a look at the source code, you'll be able to notice that it's using Java's libraries for it to function, this for example.
That means that sadly you can't run it on iOS and any platform that doesn't run JVM, as khttp will only run on the JVM platform and won't be able to run on native because of missing libraries.
I have two Xcode projects, Test and TestFramework in Xcode. Test is related to TestFramework.
There are 2 configurations in TestFramework, which are DEBUG and RELEASE. But 3 configurations in Test. Two of them are same with the configurations in TestFramework. The other one is DEBUG_FOR_TEST.
Test Configuration List:
DEBUG
RELEASE
DEBUG_FOR_TEST
TestFramework Configuration List:
DEBUG
RELEASE
Now When I build Test in DEBUG_FOR_TEST, it will fall into trap by missing TestFramework.
Since there is no DEBUG_FOR_TEST configuration in TestFramework, RELEASE will be used to build. And Test could not find TestFramework in the directory of DEBUG_FOR_TEST. Then it comes to that error.
I try to find the solution. There are several way to solve it:
Add DEBUG_FOR_TEST configuration for TestFramework. It acts but I don't want to change the Build Setting in TestFramework. Because it could be a 3rd party framework sometimes. It could be a hard work under the source control.
Add the path of TestFramework's RELEASE framework into the Framework Search Path of Test. It also acts but I may want DEBUG_FOR_TEST to be related to DEBUG.
So, both of them can not solve this perfectly.
I think if I can specific the configuration while it's propagated through different project, it should be done.
I do find a way in this website by adding SUBPROJECT_CONFIG and running a script. It also acts but very redundant.
I think it's a common problem. Most of the article about this question is written many years before. Apple might provide a common way to solve it now. But I can't find this. Does anyone have ideas?