1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.JAVA

  • Packaging Gradle

    From Raman Sarda@21:1/5 to All on Fri Mar 12 22:00:03 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --soS9XFaDwo3EY5IfBJpyArtOZ8y3qbwtF
    Content-Type: multipart/mixed;
    boundary="------------5AA3604E98109B83290BD5B7"
    Content-Language: en-US

    This is a multi-part message in MIME format. --------------5AA3604E98109B83290BD5B7
    Content-Type: multipart/alternative;
    boundary="------------937ABE61F45910F764CCDE24"


    --------------937ABE61F45910F764CCDE24
    Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable

    Dear all,

    I have a few queries.

    Is there a way we can go about updating gradle using some another way? I
    have worked on major part of the update last summer but seems we can't
    go any further without gradle enterprise plugin.
    I am trying to update gradle to 6.4.1 and it doesn't build kotlin-dsl
    plugin as of now. Gradle enterprise plugin (formerly buildscan) is
    needed for it which is proprietary.


    I am working on it here <https://salsa.debian.org/theloudspeaker-guest/gradle>. current progress
    about enterprise plugin is under enterprise-test branch.


    There have been already tons and tons of patches to remove other parts
    which are missing in debian in a bid to atleast make core gradle work.
    These patches along with all the changes in upstream have made it almost impossible to upgrade Gradle in Debian. A better approach is needed in
    my opinion. A gradle installer which pulls latest gradle and installs it
    would be easiest way to go about. But then it won't come under standard
    Debian repositories.


    I created a upstream issue to discuss the enterprise plugin situation
    #16439 <https://github.com/gradle/gradle/issues/16439>

    They mentioned that it is possible but didn't mention how yet.

    I also created a upstream issue to discuss better ways of packaging
    Gradle. #16512 <https://github.com/gradle/gradle/issues/16512>

    We can discuss this here on mailing list or IRC or salsa to find a way
    to go forward with this.


    Thank you.

    --
    Raman Sarda
    https://theloudspeaker.social/ <https://theloudspeaker.social/>

    --------------937ABE61F45910F764CCDE24
    Content-Type: text/html; charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <html>
    <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>Dear all,</p>
    <p>I have a few queries.<br>
    </p>
    <p>Is there a way we can go about updating gradle using some another
    way? I have worked on major part of the update last summer but
    seems we can't go any further without gradle enterprise plugin.<br>
    I am trying to update gradle to 6.4.1 and it doesn't build
    kotlin-dsl plugin as of now. Gradle enterprise plugin (formerly
    buildscan) is needed for it which is proprietary.<br>
    </p>
    <p><br>
    </p>
    <p>I am working on it <a moz-do-not-send="true"
    href="https://salsa.debian.org/theloudspeaker-guest/gradle">here</a>.
    current progress about enterprise plugin is
  • From Markus Koschany@21:1/5 to All on Fri Mar 12 23:00:02 2021
    Hello,

    Am Samstag, den 13.03.2021, 02:29 +0530 schrieb Raman Sarda:
    Dear all,
    I have a few queries.
    Is there a way we can go about updating gradle using some another way? I have worked on major part of the update last summer but seems we can't go any further without gradle enterprise plugin.
    I am trying to update gradle to 6.4.1 and it doesn't build kotlin-dsl plugin as of now. Gradle enterprise plugin (formerly buildscan) is needed for it which is proprietary.

    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?

    It is obvious by now that Gradle is the most difficult to maintain build system for the Debian Java ecosystem. I had a look at the Fedora packaging and it seems they have already given up a few years ago? Really? How does Red Hat build gradle packages now?

    https://src.fedoraproject.org/rpms/gradle

    If new releases of Gradle require proprietary plugins to function then we have a serious problem, because the DFSG is very clear about that. At best gradle could be shipped in non-free if the license of the proprietary plugin allows redistribution. All reverse-dependencies of gradle could no longer be shipped in Debian main and had to be moved to the contrib distribution.

    I am working on it here. current progress about enterprise plugin is under enterprise-test branch.

    There have been already tons and tons of patches to remove other parts which are missing in debian in a bid to atleast make core gradle work. These patches along with all the changes in upstream have made it almost impossible to upgrade Gradle in Debian. A better approach is needed in my opinion. A gradle installer which pulls latest gradle and installs it would be easiest way to go about. But then it won't come under standard Debian repositories.

    Ok, you have already noticed the implications yourself. Moving gradle to non- free might seem as the easiest solution but many Java packages would no longer be available in Debian main.

    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. 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. As long as all packages can be built from source, this would be fine. Packaging gradle probably will never be perfect.

    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. If there is a point when it becomes impossible to package gradle for Debian main because of the licensing and upstream refuses to change the license, then we have no choice and need to move the package to non-free. 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?


    I created a upstream issue to discuss the enterprise plugin situation #16439 They mentioned that it is possible but didn't mention how yet.
    I also created a upstream issue to discuss better ways of packaging Gradle. #16512
    We can discuss this here on mailing list or IRC or salsa to find a way to go forward with this.

    Good start. Let's discuss this on this mailing list which is easier to follow than IRC.

    Regards,

    Markus


    -----BEGIN PGP SIGNATURE-----

    iQKTBAABCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmBL4i9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7 UeROcA//Y8lglASA9OwCHNycGelNXQww1bagwv+UAYuoAXycZCEsJfACkVaSN/EW pePtHWjpwBrj5URRHA9J6IkhQgjOTkHkN30HTpxD7eodoLb41lqNV6ZQ0E7rnLxD Q/d29zyU2tw7h+N0UcgfXtQo9FFDKXh9yr0MWLe7+cbJxHuepfMIOSxBoVSigOcS oqBtZOxKJtD35oxgPryQi6UzINALVD1xy6TT8nGxzrzGz05CkCVoj7xQAlpejcTv mf3NDcbZhmXSoKIJw6C/fSeLgkqs+ltFPG3f0rXoo6yV8P1mNlCqp/MScf//wy/A xGbOiLHdieU6tdUnUm+GhCTfi7ug+MdqHij9zsqKnMIprqDxVtYVULgVchJt8cqX k7LT/EgJMCUwDB6JjJ7KiZJBo62ZCLolMPjddpbZtMh5lltw14G6L3AcmedZtbgJ +pgp8XFfPW5S0DRNxqItTjEe279Os+MRHkUnWRr20C+Y0HBq9cqnY4iQmuuNW8sI TS0xyowjdFzuVdGInb2kCZ/nuKmgunc4mgS1WC1nWhg7366rj9sgVeXzjRbCAPfC RzEHsKydE00LrRMSIsXbPz1TOm34Q8+8oTFsJRN4HxGns6jTKRWzZCuCHQXcw9p9 wp1xDfOPacKj6p8z7cfuy07qTQJ0DUsIUJOjQfvhb9KxSsgRZQo=
    =uD05
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thorsten Glaser@21:1/5 to Markus Koschany on Fri Mar 12 23:20:01 2021
    On Fri, 12 Mar 2021, Markus Koschany wrote:

    If new releases of Gradle require proprietary plugins to function then we have

    I somehow doubt that. I’d ask upstream how to best build Gradle without it before resorting to drastic measures.

    bye,
    //mirabilos
    --
    Infrastrukturexperte • tarent solutions GmbH
    Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
    Telephon +49 228 54881-393 • Fax: +49 228 54881-235
    HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
    Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

    *************************************************

    Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

    *************************************************

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Raman Sarda@21:1/5 to All on Sat Mar 13 11:50:01 2021
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nG2OuYc8t3BpR3jSEYmdM9c7SNCCGJ5jh
    Content-Type: multipart/mixed;
    boundary="------------9A1E33E46C57F80718E1529F"
    Content-Language: en-US

    This is a multi-part message in MIME format. --------------9A1E33E46C57F80718E1529F
    Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable

    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.

    I had a look at the Fedora packaging and it seems they have already given up a few years ago?
    ooof! I will ask in Fedora IRC channels. Recently joined them for kernel testing week.

    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 longer
    be 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.

    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. 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.

    Packaging gradle probably will never be perfect.
    If only upstream will help us...

    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.
    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.

    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.

    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. 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.

    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

    Good start. Let's discuss this on this mailing list which is easier to follow >than IRC.
    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.

    [1]
    https://salsa.debian.org/android-tools-team/admin/-/issues/16#note_190550

    Thanks!
    Raman Sarda
    https://theloudspeaker.social

    --------------9A1E33E46C57F80718E1529F
    Content-Type: application/pgp-keys;
    name="OpenPGP_0xAB606D73399C0B52.asc"
    Content-Transfer-Encoding: quoted-printable
    Content-Disposition: attachment;
    filename="OpenPGP_0xAB606D73399C0B52.asc"

    -----BEGIN PGP PUBLIC KEY BLOCK-----

    xsBNBF0iMjYBCAC0+YjovNOpo/gIc7uPJKN2k3mXpL6aCutm2Jej2g2CjZVGb44JAKlpig5v+viF YxyMAirvq5oRhEQ4AwqEbj0Tc+uFYSZlfOVzyOrfz6DwMsySOELIzztW4KaJikMFPsmY1DWvA1Xf z4KEB/wm4H+f2a7wxbpFUj5qo17yREZyU2wZ0xoPwiB2n3HQPzlEAUmJBeZWfM02gZZYgjqeh/Ts 1hQEM2JqXM4sVI2HzmKseiZQyjzwqxDH+8N+8nkFR1hXWRIp6H0wIUjZvJ0rv2aa4ybK1cA4uJeI 56jRPNi3x7OxIEZvgaKoQgd1FZ5KoegTNVOWo/V/zrKnTadCLeizABEBAAHNKFJhbWFuIFNhcmRh IDx0aGVsb3Vkc3BlYWtlckBkaXNyb290Lm9yZz7CwHAEEwEKABoECwkIBwIVCgIWAQIZAQWCXej9 +QKeAQKbAwAKCRCrYG1zOZwLUif/B/9sEn558Vsb5tKIzqJTa+l0k7fpw9rUmIyWsgapWe+dl1y6 ECmZplj+eTcFwAfvbh2jCC06trEonPMhuEMqoprbj5tdTVUjwd4kq/Myq5SviIr0ajpYkd3AUpvt xmUViW7MtKSZrDd3IaZS1zV6mfSbRx9BUinegQraZNFAtkY0OgPEAGVGC0EGdEYxXtVNtzGngbmA 4JmL+UEXabrsavvBNtZxJaTBI1qrSr4a4pw7ykkTap0AfmKet13qX1lMZJnuN3RODKDe8EEP/Abc J3L4sARz4aS1AymNvDyxmlQhhoaoF06QcXQIBmDbuN006f8trrxRInPRN5FFgh2kEPhozSZSYW1h biBTYXJkYSA8cmFtYW5zYXJkYTIwMDBAZ21haWwuY29tPsLAcAQTAQoAGgQLCQgHAhUKAhYBAhkA BYJdaIIxAp4BApsDAAoJEKtgbXM5nAtSLxUH/1gYxNSjY0F0gdhs4JU7k1Sayd9L+BanVeUT1ykv 4H8+zHJhRe/NIDVA9A6gXKMIDl8p/nNaSlx8SzHkIVSpPEeJb20giuHqJkpKrWacM/hMZ/fUqcnQ ZKOlZ2w08nIctKSs1L1QNDBM0oh+0Fgmn+sg4XPTiqoO+7gpIIHNFGmP3tJAXuPabpJr84wXEw0t VXNxEwXcZF8budGT06N6B2LN22C6Ese+uFA/pbPx8yM7PqAv3MMgKo8lL7InRgazsmrSQ6A/C0nX BTVpTuwqT2yjPkjs+rXeN9O/le5W0W015QSDKByJ/SZZz48LvM1TLtwfNMF+aa7No04jWOsIGUbN J1JhbWFuIFNhcmRhIDx0aGVsb3Vkc3BlYWtlckBsdWJ1bnR1Lm1lPsLAcAQTAQoAGgQLCQgHAhUK AhYBAhkABYJd6P35Ap4BApsDAAoJEKtgbXM5nAtSCVEH/2JLtn57Kxjha7aaDgB51iRfMCkbFbol pMTRgMuWap4vpppz9BWqC0dOLJQJtlaw6N/CcIJQ32nlXqTmJBK9FEN9/41nhe9l5Ni1woNjrwxh bZ7jSWtxADsnoJPtYJnogrW4zftmeowjOj4uT1qsKkVNSZjp3O7YyVExBftD3s/RQdV5kSY+y+kD VNoS5NP5zsHCfPWgVVQ4/FZkAjXHS5Dprrely/CumaSaB/Gb6ZZ8Wam2st69+aGiwwQrYqcaN4KL rebfjN7ZT6udrWb5fG5l0e24DCdwnlObFYNydhwQj+rQlRqVZTIqd+UW1omd7He+6LSVfJw8GtH1 ofacQxfNJ1JhbWFuIFNhcmRhIDx0aGVsb3Vkc3BlYWtlckB1YnVudHUuY29tPsLAcAQTAQoAGgQL CQgHAhUKAhYBAhkABYJdaIIUAp4BApsDAAoJEKtgbXM5nAtSF3gIAKN8x42XqiF6VkB+DdEiggKQ I53TR5X6LBIOEDbq7VQmLJjKQnwU5bzcfCfhgpiLCthRBssjNX6xNKqS5R1149XCsn37C2RxQtil mkNcSnqVctZ9TkyMztlEtmcUry/6qLeQ9+c3Iy7bDHE+U1ebInhtDd/5hR8oIUOQqfGKJoy84SgX +j86Jm3tFQY3EI5C9cE+mn7dh47pIAzufSnJwuhmDkjR7t1JwZ3vvQLWFtrANIeM6K2dFR1GBJc8 XAXsp+3JyDTL7PdD4nVI0fuHZuRHeliGnIVWVvIHtkAuaOGILpymCws6dACNNzfi1cx8MKy7Cjk0 wnkC6r7FHE/yRJHOwE0EXSIyNgEIAPQ44Qk2Ei60mBVmYQo/e/sLzE1NZp9d7MWjsT06mJwM7DQi vp6pdpMg3sgpK7hNGTcqWTlfv0Z0ONg2eDKGScjKCQ8IIji9Oennnq2RzoUMPR+1ModVqGWvVeGh m5Fsr2I2deVXx+SHDQvdtydq16o5glbEjwomiaqWiyYj+ig8Trp7F3l6WEX0/rPpY8drtE5obmkZ E0Cenae7kk8YSjLlKJAdS/C6mMS8jyWuQiL69M4RdxfuOAlMIZzCc2fxfJ57KukAKwJ11FwSyyNd FvG5R3rUXNFL/4erjPnP/CwGZ18J483W3jLjfwvm0u0UI50pQp5mpSWRPpn4K6W6wFkAEQEAAcLA dgQYAQoAIBYhBJYWuJjFeLRUwyYCiKtgbXM5nAtSBQJdIjI2AhsMAAoJEKtgbXM5nAtSOVMH/iGF 4SBP+XeVUY76sJVBRZOpsMW4dysNaUFnqf9/NLM+kALIOa/JcjqXL++HDe08uT5FyfKEQOJ8Yzy/ +cJkJtu9HLLj+xyMFvw6sgpp6yK1PELbBITXmSNwrbs1X3/RvmYRJDgKsliQ319cBJEC7Z+1jTe2 K/oNLDgVKUz7Y5hLWmXt04H/Cuc4BetcfejIW3dbdjo4960wtt+9rBr2bItFJpNQOVkVLNud4PGn 6kvkjC9GecDUN6noGtlaetjYH7GX2vuRDos60qvcXNQ7BF8FMgdpITVzDSoXnSFkJ0XzK218yNcA ZAE0ZsCMfPAoS3KHl/7vYUhREBhP0K7XuG3OwE0EXUHVIQEIAK/wZpNI3ZtI67NiYFiTABbXVxcl 2T8SMt4X9fkI+CsKkiz19ieUteicOPXk+S6dtLKNs3/7Dnil/DLsjnfUr+EwsCKJ+E9P43EYyk0y Y0p6TjnJWJQa/rc78SMxeTNUUqfN6PBJV1jGQr2P40I1DEuDo2cCdMeLfySW7SvDwP5eXlJgcJlT sVFqeMkPt86yqVFKl63qG1tqgvrw0nBRJxL4yssFjbz3ERmSq++PfuiBR/aXDQFn6TJyd0gmTk7V WYvzpkad2BDnxHrAr/fBXlShrrKivfk3eSoOsr2VA1MDWNokeTiYdjRNB+oneMH4KiHCa69v2f7v 8ULN9B7J38sAEQEAAcLAXwQYAQoACQWCXUHVIQKbIAAKCRCrYG1zOZwLUsSzCACw7b0GnynseE34 QkNUXXDjubdBTtaDpJZK9TmnMv11hDrbMQxho8MUqdFzKwNT9F1ODXmD9ZtKnokIXKQMoQI/93w3 uW8l93jUUgN4VkflIK5x0vEO2PzP6LTWvzT1/wcAejjSKwM8m/G5V0gcTTzZ4z/3yYG6mRI9ryMM RBHdG5TYoTrmEdiP/YoiWpElDWRYB7DNlmtGqaeFuhUpM1wtyvzC8+kNCWUDzs0Z1aR6QQuTNvvF lnavGRUcSy1hW1oXrRxoAvYwdjsBdQWpEmqWhCYhcMypYybMiwgBsPhPzOaAjmQmT9Hm0o4A/1zI 6JgDoZtl+yswJPAbjwo10oP8
    =yOcB
    -----END PGP PUBLIC KEY BLOCK-----

    --------------9A1E33E46C57F80718E1529F--

    --nG2OuYc8t3BpR3jSEYmdM9c7SNCCGJ5jh--

    -----BEGIN PGP SIGNATURE-----

    wsB5BAABCAAjFiEElha4mMV4tFTDJgKIq2BtczmcC1IFAmBMmHQFAwAAAAAACgkQq2BtczmcC1L4 Awf/VwRpJ6KJlHN4xjr5ShNhjYCGFcE0T1i0tK+35QHcUsnXhjcducoMLcsI3GDkA+0ENz4m5xfA YnLeYWP2BTBId5ycOnyREZ6oyMaThLUn3146qIWW9PFPM4Eh2PSUKGhAuFt+sz/0UXt2/Z5q6/n6 JKLJDHjZptjWdUbRp3FKh79KXXQQyQYB0Sffv59Vh2SaPABa1eiUVSdLWQN5d9h68tmiPmkXGKp8 cDgvQ/y+ylc+WuFJ9YBRbE6BgiquILCxlD8dPQYVE+O/JU0Ohf3Fv/ETwYtjfWSB8sOo4elqaV8X 8FD5DPJp6Hn648xiCxJregq3R4KjdjguHNLHaYW5CA==
    =TKE1
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Emmanuel Bourg@21:1/5 to All on Sat Mar 13 13:20:01 2021
    Le 12/03/2021 à 21:59, Raman Sarda a écrit :

    Is there a way we can go about updating gradle using some another way? I
    have worked on major part of the update last summer but seems we can't
    go any further without gradle enterprise plugin.

    Are you sure this plugin is required? My understanding is that it merely provides build time improvements and some code/build reports. I guess it
    could be simply disabled.

    Emmanuel Bourg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)