Closed arberg closed 1 year ago
It seems I can use v1.7.0 for now.
Hey!
Great to hear that the issue was solved. If you have any other issues feel free to get in touch at any time!
Hi, This issue isn't solved. It is not a viable solution to leave all your customers who use kotlin stuck on NetAxept version 1.7.0. I just wrote it to let you know that I at least can get started.
Hi @arberg,
It maybe misunderstand what you shared from previous answer and we assumed the newer version solved your problem. We will reopen this issue and investigate this issue to be able to get back to you soon! In the meanwhile, we highly recommend you to use the latest SDK version 2.0.1 to get all features and bug fixes in place.
Will also stay on 1.7.0 until this is fixed.
Hello @arberg & @NielsLindberg
A new version v2.1.2 of PiA SDK has been released. Would recommend you to use the latest SDK version which includes fixes to compiler issue allowing for full automated installation. Feel free to reach out to us if you face any issue.
Best regards
It doesn't work, I get
Duplicate class kotlinx.serialization.BinaryFormat found in modules jetified-kotlinx-serialization-core-jvm-1.0.1 (org.jetbrains.kotlinx:kotlinx-serialization-core-jvm:1.0.1) and jetified-kotlinx-serialization-runtime-jvm-1.0-M1-1.4.0-rc (org.jetbrains.kotlinx:kotlinx-serialization-runtime-jvm:1.0-M1-1.4.0-rc)
If you want us to use the the newer version, I need you to deliver a version which does not tie us into a specific version, and which matches the version of your library. So I see three options for you.
1) Get rid of kotlinx serialization. 2) Find a way to use kotlin serialization so we can compile with a different version 3) deliver multiple versions of your library, make it clear from your version which version of your library uses which kotlinx serialization dependency. Furthermore, you would also have to be relative quick about updating your library whenever kotlin releases a new version, or you risk us having to roll back to netaxept 1.7.0. In fact I would much prefer stayng on netaxept 1.7.0, as I do not trust that you can deliver on such a promise to keep it up2date forever more, and it would suck to roll back to 1.7.0 as it might break something on release, and if I stay on 1.7.0, its a different situation.
so that kind of leaves 1) or 2).
Normally its possible to have differing versions, gradle should chose the higher version during dependency resolution. The problem is probably that they changed the naming from runtime -> core, so gradle doesnt recognize it as being the same library.
Nets needs to update their depedency on kotlinx following the setup here: https://github.com/Kotlin/kotlinx.serialization#setup.
./gradlew app:dependencies should look like this:
and not this:
You can see in the second picture where it has the "->" that during dependency resolution its chosing a higher version of a lib than what nets sdk uses because it recognizes that lib to be the same as one i have imported as a higher version in our project.
Hello Arberg & NielsLindberg,
Thanks a lot for your reporting and all relevant suggestions. Our dev team will look into this issue and get back to you once we find a good approach to hamorize the dependencies.
Interesting point, Niels.
I think its also worth noting that the kotlin serialization is a very young project, and had a significant change from 0.2 to 1.0 API. Its possible that they may release a future 1.X.0 version that might fail if executed on code built around 1.0.1.
Should that happen, then the netaxep SDK will break, when the client (ie. me and Niels) includes a newer version of the serialization API. And possibly we won't see the breaking code until its published in production.
That is much less likely to happen with a more mature serialization framework.
Thank you for your inputs and this will be resolved in our next release. However in the meantime, we advice you to exculude the transitive dependency of the following serialization dependency used in SDK
implementation("org.jetbrains.kotlinx:kotlinx-serialization-runtime:1.0-M1-1.4.0-rc")
Something as follows implementation ('eu.nets.pia:pia-sdk:2.1.3'){ exclude module: 'kotlinx-serialization-runtime' exclude group: 'org.jetbrains.kotlinx' }
Best Regards
Why did you close the issue @Miss-PiA? You are still using org.jetbrains.kotlinx:kotlinx-serialization-runtime:1.0-M1-1.4.0-rc for some reason.
Thank you for reachinmg out.
Hope the given workaround did work for you, are you still facing issues while integrating?
Yes we should keep this issue in opened state and we will be coming up with the solution for this in future releases.
BR
I notice that you are just closing all open issues each time any unrelated android release is published. I think we will have to stop reporting on these and assume you are unwilling to fix the issues.
Hi @arberg , We are sorry for inconvenience.
We have release new Netaxept Android SDK v2.7.0. Please try this version and let us know if you are facing the same issue. As we have modified Android SDK version with other dependencies.
We are ready to help you at any time. Please report if you face any issue.
Thanks,
Hi @arberg
Can you please check if your issue has been resolved in v2.7.1 release of the SDK?
Hi @arberg, Currently closing the issue. In case you are facing this issue in the latest version again please reopen the issue.
Thanks
We use
implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.0.1")
and Kotlin 1.4.20I suspect this library use this old beta-version of the library of version 0.20.0.
This old library is not compatible with kotlin 1.4.10 and newer, and prevents compilation.
I get the following error:
Will you update your library to the most recent kotlin and kotlinx-serialization version?
Note that there are some breaking changes, such as rename of every decode/encode, and you need a different dependency when moving from 0.20 to 1.0.1 (see my -json dependency above). Its a minor hassle for me, with search/replace to fix it, though there are also a few other issues.
I suspect there's also a larger issue to resolve, which is avoiding all your clients to use the same kotlinx-serialization version, if that is indeed a problem, though that could be resolved afterwards.