Make KotUniL available via JitPack
vsirotin opened this issue · comments
For special user groups is it important to make KotUniL available not only via MavenCentral, but also via JitPack.
As si-units as an open-source project using gradle as a build system, jitpack is creating builds for you already.
See https://www.jitpack.io/#vsirotin/si-units/2bd450be91 for an example.
In that case, you can use it like this
allprojects {
repositories {
...
maven { url 'https://www.jitpack.io' }
}
}
dependencies {
implementation 'com.github.vsirotin:si-units:Tag'
}
As Tag you can use git commit hashes
Jitpack also supports build with fixed release versions, in that case this project need add a support for github releases. See https://github.blog/2013-07-02-release-your-software/ for more details.
In case, you are interested in, I can support you with this too.
Thank you Michal!
I think it would make sense to manage the versions in parallel in MavenCentral and in JitPack.
The correctness and accessibility version it would be useful to test automatically before announcing new version in documentation and in media.
I am thinking if it would be useful to add corresponding independent modules directly in project. One test module for Magen-Central and one for JitPack.
What do you keep from this idea?
Hi @michalharakal,
unfortunately, it don't work by me. The error message:
HomeEnergySimulator:test: Could not find com.github.vsirotin:si-units:SNAPSHOT.
BTW: JitPack recommends use implementation 'com.github.vsirotin:si-units:-SNAPSHOT' against your recommendation 'github.vsirotin:si-units-jvm:SNAPSHOT'
But I tried different variants. Without success.
How are you tested it local?
It seems to works with an explicit commit for me:
implementation("com.github.vsirotin:si-units:03db64e7a9")
Also, I've learned that additional jvm in a name is not necessary because gradle can figure it out automatically. I have to change this in docs...
I am not sure, if the build has to be started manually or will created automatically. Official docs states that a build is started on demand. So, the first referencing of a version starts a build if there is no artifact there.
Here a minimal version attached.
si-unit-cli.zip
Versioning with SNAPSHOT will hopefully start to work after we have the first version released.
I analysed https://jitpack.io/com/github/vsirotin/si-units/03db64e7a9/build.log and found out that
implementation("com.github.vsirotin.si-units:kotunil:03db64e7a9") should working correct.
I checked it. It works.
Are you know, how one can browse maintained deliveries on JitPack?
If not, probably it's should be possible to set logging by each build in JitPack. What are you think about it?
@vsirotin I was playing around with jvm target to see how well sources are imported in plain java gradle project. I have created simple java only cli-app. See code here
si-units-cli-java.zip
Good news, you have the source code already packaged with jitpack.
But, I have also learned how are Kotlin's class extensions compiled and consumed with JVM. For java are extension functions added as static methods into the class. See more simple explanation here https://stackoverflow.com/a/36452456 and official docs here https://kotlinlang.org/docs/java-to-kotlin-interop.html
Immediate impact is, that without further doing, this static classes have Kt on the end of the name, like this for importing Amper:
import static eu.sirotin.kotunil.core.ExpressionKt.times;
Lets discuss about a solution by using @file:JvmName("Expression")
Thank you, @michalharakal !
I know this document. Last week I invested time to understand all "interops" (Java, JS/TS, C, Swift) and I started to develop generators for all main targets in directory apps.
I hope that during this week I will make available the sample applications for a few platforms.
Interops require KotUniL code to have certain annotations. Nevertheless, not all features of the Kotlin version are available in other languages. That means we need to mark in which version the feature is present. I have seen in your Dokka experiment, you can do that already.
Could you please round this part as soon as possible so I could use this in my generators?
Thanks in advance!
@vsirotin I have learned more about usage of not released versions via Jitpack. Documentations states, that
If the project doesn't have any [GitHub Releases](https://github.com/blog/1547-release-your-software) you can use the short commit hash or 'master-SNAPSHOT' as the version.
What is our case. So, I will try this out (using master-SNAPSHOT), and if it works, we could move java and Kotlin apps to use jitpack instead of localMaven.
Ok. Fine! Thanks!
@vsirotin Finally, it seems to work. You can use jitpack packages like they are already used with sample apps:
see for Example https://github.com/vsirotin/si-units/blob/main/apps/jvm/kotlin-console/build.gradle.kts#L14
It was a typical "chicken or the egg causality dilemma" combined with strange gradle errors on jitpack.
I solved it so, that as the first I've removed apps from the project completely (even not compiled, the dependencies have to be fulfilled). After taht, the first jitpack valid artifact for main-SNAPSHOT has been built. Then I have added the apps back, and now they could download the lib from jitpack.
Problem solved :-)
Thanks, @michalharakal!
I'll see your solution asap.
Viktor
It seems JitPack is working at the moment very unstable.
In my opinion, it is not worth investing our time for this optionalle platform at the moment. That's why I'm closing this ticket.