-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kickstart a project kotlin-server #24
Comments
Would it be safe to use a single Gradle project for many different web servers? Couldn't that create dependency problems (different versions)? |
@jaguililla Do you have any example where a dependency upgrade is not possible for a Kotlin/JVM server framework? |
No, but it would be hard to tell without knowing the list of examples in advance... And being it open, it could eventually generate a problem with conflicting dependencies. And also, there are products sensible to the classpath (Spring). Wouldn't you consider creating a multimodule Gradle project? It wouldn't be much work and it would be safer. |
We are considering making a multi-modules project, yes. |
If you share more details, I could be interested in doing it. What should a typical sample implement? Or you could take the TechEmpower Benchmark implementations as valid examples :) https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Kotlin |
I am giving a try, will start with a Spring Boot module |
@jaguililla @fultonbrown @NikkyAI If you have any feedback, you are welcome. Everyone could then reimplement it with $FAVORITE_FRAMEWORK |
Currently all samples are inside
kotlin-jvm
and are self-contained in their own package, with each having itsmain()
function.But what about servers?
Ideally I would like to have a new directory/project
kotlin-server
that will contain an implementation of the same simple server spec in ktor but also later spring boot, http4k, javalin or whatever people want to contribute.For a real project, one would use a multimodule Gradle build for that, but for pedagogy simplicity is key so if that's possible to put all implementations in a single module, that's better!
The text was updated successfully, but these errors were encountered: