I have query about okio , is it possible to run the okio in javascript, is there is any okio package available for javascript ?
i got this query due to this commands in release notes of okio.
Version 3.0.0-alpha.3¶
2021-04-06
New: Move NodeJsFileSystem into its own module. Having it built-in prevented Okio from working in a browser where there’s no synchronous file system API. This is in the okio-nodefilesystem artifact.
Okio is a Kotlin Multiplatform library and runs in JVM, JS, and native.
Related
I am new to gradle. But I do understand to some extent why developers are encouraged to use gradlew instead of gradle. However what worse could happen if developers use different versions of gradle to build their project? At the end of the day any gradle version makes sure that dependencies of the project is managed properly. For example if a Spring Boot project is dependent of a starter plugin version 2.x, no matter what version of gradle is used, the build tool makes sure that 2.x is available
As far as I'm aware the main point to use a common version of Gradle is plugin compatibility.
Gradle's internal APIs changed quite a lot in the last few versions, so not every plugin works with every Gradle version.
For example: Spring Boot's 2.3.4 reference explicitly states that it's build plugin requires Gradle 6.3 or later (although 5.6 is mentioned to work in a deprecated form)
https://docs.spring.io/spring-boot/docs/2.3.x/reference/htmlsingle/#getting-started-system-requirements
So while you can be sure that the Spring Boot version is used (because you defined it in your buildfile) any older version of Gradle is likely to run into Exceptions when trying to build your project.
Even if you're just using plugins that are provided by Gradle itself there can be compatibility issues. For example the java configuration block was first introduced in Gradle 5 (I think) and therefore would cause a syntax error in earlier versions.
Or simple things like Java versions that older version of Gradle do not support.
The more plugins you use it becomes increasingly unlikely that a lot of Gradle versions will be able to run it. Using the Gradle Wrapper is therefore a simple way that your build works for everyone.
And from the other perspecitve: if you are the one that usually maintains the build you can use all the latest Gradle features using the Wrapper as you can be sure it will not break anything. Getting everyone on the team to update manually before you can use a feature can be a pain
That beeing said, it's really primarly a maintenance issue. Nothing bad can happen if anyone uses their own installed version of gradle, except it might just not work
If everyone on the team uses a similar version nothing might happen at all
I'm using OkHttp3 to build up a simple connection API for a pure Java app, and I've run into a build problem that seems triggered by the fact that Square uses the same package name for multiple dependency artefacts.
I've seen some previous Q&A that discusses Maven dependencies and messaging from Eclipse, but all of those indicate that a Maven or Gradle build still works even if Eclipse annotates imports with module errors. In this case the Gradle build fails as soon as I simply add a dependency and make no other changes.
The app is a pure Java 11 module build. I'm using a very recent Eclipse with Gradle nature as an IDE, but I don't think this is strictly relevant. I'm using OkHttp3 to turn private endpoints into API, and one of those endpoints requires a CookieJar. Hoping to just use the default implementation, I add 'com.squareup.okhttp3:okhttp-urlconnection:3.14.9' as a dependency in a project that has already pulled in 'com.squareup.okhttp3:okhttp:3.14.9' as a transitive dependency. Both of these technically offer classes using the same package name: "okhttp3".
e.g., all I do is uncomment the dependency line seen in this snippet and save the build.gradle:
dependencies {
implementation ('com.squareup.retrofit2:retrofit:2.9.0')
implementation ('com.squareup.retrofit2:converter-gson:2.9.0')
implementation ('com.squareup.okhttp3:logging-interceptor:3.14.9')
// implementation ('com.squareup.okhttp3:okhttp-urlconnection:3.14.9')
As soon as the project refreshes I get annotations in Eclipse for all "okhttp3" imports:
The package okhttp3 is accessible from more than one module: okhttp3, okhttp3.logging, okhttp3.urlconnection
A clean build results in:
$ ./gradlew clean build
[...]
> Task :compileJava FAILED
error: the unnamed module reads package okhttp3 from both okhttp3.urlconnection and okhttp3
error: module retrofit2.converter.gson reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
error: module retrofit2 reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
error: module org.apache.commons.io reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
error: module httpcore5 reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
[...]
I don't think it matters, but I'm using Gradle wrapper 5.6.4.
All OkHttp3 libraries, as far as I know, have set module info enough to satisfy Java 9+. The module stuff in Eclipse seems satisfied by that. It looks like neither Eclipse or Gradle like the fact that two different dependencies advertise their Java package as "okhttp3". It seems to me that any Gradle or Maven based project using Java 9 or higher will fail with split-package dependencies.
Based on some advice I read elsewhere, I've tried excluding 'com.squareup.okhttp3:okhttp' from all the dependencies that include it transitively and then pull it in separately, but this did not help (not that I thought it would, but I'm trying any hail-mary at this point).
Workarounds include hacks like simply dropping the two Kotlin classes I want into the project directly and renaming the package that way. This is an egregious hack, and is probably contrary to the library license. I can also implement the cookie stuff I need directly, but I'm lazy (though, apparently, I want to spend my energy solving this problem instead of implementing a cookie class using the interface I already have).
I feel like this is a bug on the part of Square and how they package these libraries/modules. Since their focus is so much on Android maybe I'm the only one who has wanted okhttp-urlconnection on Java 9 or higher? So, this Question is more about seeing if I should raise this as a defect, and also maybe I've overlooked something obvious.
It's OkHttp’s fault and we can fix it for you. Please open a tracking bug with a link to this issue.
We'll move those two classes to a new package. For backwards compatible we'll also need to leave delegating implementations behind. Hopefully the tools permit this!
It's too bad that JPMS has this constraint. We already fixed some of our other open source projects but didn't fix this one.
I am looking for a WebSocket library that I can use in a Kotlin Multiplatform project for my iOS implementation. This project is currently in IntelliJ and I am using Gradle to manage dependencies.
I have not been able to find a library that supports iOS and that I can specifically pull into my project via Gradle.
The likes of Starscream, Socket.io, SocketRocket etc seem to only have a means of importing dependencies within Xcode/CocaoPods and nothing via Gradle for my IntelliJ project.
To give some more context I have the following for my project
Kotlin Common code for all my common functionality for the project
Platform specific code for my WebSocket implementations for Java, JavaScript and iOS/Swift
The reason for the platform specific implementations is because I have not found a common library that supports WebSockets for all platforms.
Ktor comes close, but from what I see in their documentation their WebSocket client does not support iOS while their Http client supports all platforms.
If anyone has any recommendations that would be really helpful.
The guys from ktor said that they are working on bringing Websockets to iOS but it's still a few months from release.
I haven't tried it yet but you can import cocoapods to an multiplatform project so maybe you can use it that way, but note that it will only compile in xcode.
Also you should join kotlinlang on slack, the guys from jetbrains are really active there and will usually have an answer in a day.
I came across this pom.xml file of a sample spring boot project. I was surprised to see dependency section for client side javascript libraries like bootstrap and jquery inside it.
I would like to know what are these dependencies, what do they offer and is there any advantage of using them in a Spring Boot application?
This is a special project called WebJars.
It aims to package most popular JavaScript libraries into JAR files that could be used in the Java projects as a Maven/Gradle/etc dependencies.
Some of its benefits are:
you don't need to import all the JS libraries into your version control system (Git, for example)
you can easily manage JS libraries and its versions by updating and rolling them back, like you do with other Maven dependencies
other benefits (like resolving transitive dependencies) are listed on the official site
See also: Utilizing WebJars in Spring Boot
This allows a dependency management for js libraries/frameworks over maven. That's all.
Alternately, you could do this as well with bower or node.js
I'd like to create my own gradle library, that can be compiled into other projects using gradle compile statement.
Example from Picasso's README:
Download the latest JAR or grab via Gradle:
compile 'com.squareup.picasso:picasso:2.5.2'
I'm developing few applications that share common source: fragments, views, some logic... Sometimes I extend these sources while I'm developing app A, sometimes while I'm developing app B,... And I feel that copy-paste of packages/classes in Android Library Module is not an proper solution.
So I would like to setup my own library, that:
it could be easily deployed to as gradle library that could be used by compile.
I can easily develop/extend it together with currently developed application
Disclaimer: I had been googling it a lot, but without luck.
If you want to reuse a library across completely separate projects then you'll want to publish your library to repository. Assuming this is open source and you don't mind sharing, you could use JCenter, which is already added as a repository to Android projects by default.
https://www.virag.si/2015/01/publishing-gradle-android-library-to-jcenter/