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
Suggest dependencies to add #238
Comments
I'm not sure we need to add Guice, nor Kotlin unfriendly Gson (lying nullability). |
those non-kotliny things would fit well enough into |
RxJava is also missing |
Also for backend people we already have ktor and we should add the dependencies for the Spring framework that are displayed on https://start.spring.io/ Using the web interface, I added all available dependencies which generated the following Gradle file
|
And if someone is courageous enough, those are the other kotlin solutions on the backend
|
@jmfayard @LouisCAD Ideally, you could have them splitted, and also offer a meta package for importing them all. This also could help in case of conflicts. |
I asked |
@DanySK we can always split the definitions later, but I'm not super worried for that now. |
It's also peanuts compared to the size of the webpages one would browse to find if there's any update. |
@jmfayard I believe it'd be more to reduce the probability of conflicts than an issue with size - which I frankly did not even think of as an issue. |
Which kind of conflicts? And what can we do to prevent them? |
Multiple libraries with the same name, for instance, of which one has an overridden name, and the other does not. Say that some random company creates a patched version of Kotest (or another library for which there is a very reasonable key rule) and calls it "my.company:kotest-*". What if they want to have version.kotest custom rule pointing at their own package? Can they not load or unload or override the default setting? I realize they are corner cases, but if supporting the possibility of selectively load/reject aliases or shadow them is cheap, I'd support it. |
If they don't use any kotest official artifacts in their dependencies having the version placeholder (or constants from refreshVersions), they can have a more specific rule for their maven coordinates with the same alias, though I'd always recommend to have the company name in the version key to avoid any confusion. If that's not enough, then let them convince us to make an "enterprise" version of refreshVersions 😄 |
I am not sure if this is a good place to drop the libraries I found missing, so please let me know if you would prefer another ticket Android:
Google APIs:
Firebase:
ReactiveX:
Misc:
|
From the Kotlin Libraries Playground: https://github.com/LouisCAD/kotlin-libraries-playground
|
We need to make it a little easier, and documented to add dependencies constants with the proper rules. This is one of the priorities for 1.0 |
Add GraphQL https://github.com/jmfayard/refreshVersions/pull/258/files
|
Part of Splitties#238 Based on Splitties@4540bc8 Co-authored-by: Jean-Michel Fayard <jmfayard@gmail.com>
Add ksp: https://github.com/google/ksp In the kotlin project, ksp will be better than kapt, so I highly recommend adding this dependency |
The various libraries by Mike Penz would be very useful (at least for me): This one is awesome, and has lots of additional items: |
the followings are also missing
|
wish to have these available as well
|
I would like to propose the great Arrow libs
Note that they also have a BOM available
|
More missing libs:
|
|
Splitties#238 [Summary] Koin is a common DI / Service Locator framework for KMP, and we'd like to migrate to refreshVersions completely. https://insert-koin.io/docs/setup/v3 How we're using it for safe multithreading on native in KaMP Kit: https://github.com/touchlab/KaMPKit/blob/main/shared/src/commonMain/kotlin/co/touchlab/kampkit/Koin.kt [Fix] Add the Koin dependencies. [Testing] - `./gradlew :refreshVersions:check` - inspections that the coordinates are generated in dependencies-mapping-validated.txt and bundled-dependencies-validated.txt.
|
@jmfayard Shall we close this issue, now that we have issue templates for new dependency notations, and contributing docs to submit a dependency notations PR? |
Yes |
Alright. Please everyone that suggested dependency notations that are still not into refreshVersions, create one issue per group of dependencies, or if you want, directly submit PRs from the ones that are part of groups already present in refreshVersions. Submitting issues with the template is now the way. Thank you all :) |
Want to contribute new libraries?
Propose it here.
We have homework on our side, we wants to make it easier to contribute a new group:
Proposal for simplifying adding a dependency group #262
The text was updated successfully, but these errors were encountered: