Hii Markus!
I haven't followed all the discussions about the progress of introducing Kotlin to Debian. This appears to be the major obstacle to maintain future Gradle releases anyway. Where do we stand here?
Me and Samyak Jain had started on Gradle and Kotlin simultaneously last year. And kotlin right now is blocked by Kotlin-dsl plugin from Gradle. Which I as I mentioned, is blocked by enterprise plugin.
ooof! I will ask in Fedora IRC channels. Recently joined them for kernel testing week.I had a look at the Fedora packaging and it seems they have already given up a few years ago?
At best gradle could be shipped in non-free if the license of the proprietary plugin allows redistribution.
We will have to check that with upstream.
Moving gradle to non-free might seem as the easiest solution but many Java packages would no longerbe available in Debian main.
Hence this mail to java-team.
In my opinion, before we talk about upgrading gradle in Debian, we should finally package Kotlin. This appears to be the major blocker at the moment.
Kotlin is blocked by Gradle. hehe.
The main problem with that approach is, any version after 4.4.1 (which is currently in Debian) is written in kotlin and not in goovy. meaning, it uses build.gradle.kts files instead of build.gradle ones. So we anyway cannot use existing Gradle and tools to build it. so we might as well go with latest available gradle which is written in kotlin. This is why we started with Gradle 6.4.1 last year.After that we could take smaller steps by upgrading only to gradle 5.x or any minor version in between that makes it easier to maintain this build system.
Packaging gradle probably will never be perfect.
If only upstream will help us...
Most of the components which are ommited can be found in debian/patches/ like Google Apis, AWS SDK for java, etc. Those along with hard coded version numbers of artifacts used are blockers.While working on that we should identify the major blockers of maintaining future gradle versions and voice our concerns about the non-free components in gradle with the upstream developers.
I got Gradle actually working without enterprise-plugin and scala features last year. You can find the instructions here.[1] The binary which we get after first online build should be capable of running a second build in offline mode. That would happen if it didn't fail due to mis-match of version numbers.
This hard coding of version numbers in gradle/dependencies.gradle file is a major concern for future maintenance.
Stripping components away has been the way 4.4.1 was packaged. But it has become tedious to update. But frankly we don't have any other choice here.Otherwise we also can try to strip away those components, >if technically possible, and try to maintain a core gradle package that just works for our main purpose of building packages from source.
We also have the option to use a custom build system, just using Ant or Maven instead of Gradle for affected packages. Of course this requires additional developer time and the question is, would it really help us in the long-term?
+1
Sure. We in Android-tools-team are more active on IRC. And we will be discussing this there by the end of this month. in our monthly meet. Please join us, we can discuss this there too. I will ask Samyak to send an invite to java team as well.Good start. Let's discuss this on this mailing list which is easier to follow than IRC.
[1] https://salsa.debian.org/android-tools-team/admin/-/issues/16#note_190550
Thanks! Raman Sarda https://theloudspeaker.social
Attachment:
OpenPGP_0xAB606D73399C0B52.asc
Description: application/pgp-keys
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature