From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 89B391382C5 for ; Mon, 21 Jun 2021 10:14:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DC55DE0843; Mon, 21 Jun 2021 10:14:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 74FF9E0843 for ; Mon, 21 Jun 2021 10:14:50 +0000 (UTC) Received: from [2a0c:b641:69c:e781::4] (port=45008 helo=proton) by muon with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lvGx3-0003aX-Vm for gentoo-soc@lists.gentoo.org; Mon, 21 Jun 2021 10:14:46 +0000 From: Benda Xu To: gentoo-soc@lists.gentoo.org Subject: Re: [gentoo-soc] Week 2 Report for Big Data Infrastructure and H2O ebuilds Project References: Date: Mon, 21 Jun 2021 18:14:44 +0800 In-Reply-To: (Yuan Liao's message of "Sun, 20 Jun 2021 23:14:32 -0700") Message-ID: <871r8vplrf.fsf@proton.d.airelinux.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain X-Archives-Salt: 5fea2f3b-0ed2-4544-9a34-4041b6982ba9 X-Archives-Hash: 22e1a4c2bae11fa74f498224287707ca Hi Leo, "Yuan Liao (Leo)" writes: > The second week of my project has come to an end. This week started > with a wrap-up of my last week's work on java-ebuilder. Since > Tuesday, I have been working on the Kotlin ebuilds in the Spark > overlay created by Zongyu Zhang last year to improve their quality, > and bumped the ebuilds to Kotlin 1.4 and 1.5. Meanwhile, I added > another new feature for java-ebuilder that was deemed helpful in > maintenance of those Kotlin ebuilds: support for ebuild variable > expansions in MAVEN_PROVIDES and SLOT. > > The first thing I did for my project this week was to submit a pull > request that fixed a bug in java-ebuilder. I mentioned it once before > in my communication with fordfrog in this mailing list after the > previous weekly report, and I would like to thank fordfrog again for > contacting me and merging my pull request in time. I have also made a > blog post [1] on my personal website which contains a description of > how I investigated the issue's root cause, some alternative methods to > fix the bug which I considered but did not use, and a low-level > explanation of the issue. Make sure to check it out if you are > interested! After that, I wrapped up all the work pertaining to > multi-line MAVEN_PROVIDES support and merged related code into the > master branch of my java-ebuilder fork. > > Next, I made a fork [2] of the Spark overlay to improve on the Kotlin > ebuilds in it. The original Spark overlay provides two Kotlin > ebuilds: dev-lang/kotlin-bin for the Kotlin compiler and runtime, and > dev-java/kotlin-common-bin as a dummy package for the Kotlin core > libraries. The latter ebuild contains a MAVEN_PROVIDES definition > with Maven coordinates of some Kotlin artifacts, and I believe its > main purpose is to be used by other ebuilds that require the Kotlin > libraries as a dependency, especially when java-ebuilder is requested > to generate ebuilds for a Maven artifact that depends on Kotlin. I > really like the idea of separating the compiler plus runtime and the > libraries into two packages. If someone wants to use the Kotlin > libraries but does not need the Kotlin compiler, which is totally > possible thanks to interoperability between Java and Kotlin, they can > install dev-java/kotlin-common-bin only and use it as a normal Java > library. Unfortunately, in the original Spark overlay, > dev-java/kotlin-common-bin depended on dev-lang/kotlin-bin, so it had > been impossible to install the libraries only and skip the Kotlin > compiler. This week, I have successfully reversed the dependency > relationship so users can install dev-java/kotlin-common-bin without > pulling dev-lang/kotlin-bin. Then, I worked on removing bundled > dependencies shipped within the Kotlin package provided by JetBrains. > The upstream package contains a few JARs that are merely dependencies > of the Kotlin compiler rather than components of the compiler itself, > namely JetBrains' annotations library, JetBrains' fork of GNU Trove, > and KotlinX Coroutines core library. For each of them, I created a > separate ebuild and let dev-lang/kotlin-bin depend on it, so > dev-lang/kotlin-bin would be a cohesive package whose files are all > tightly coupled with the Kotlin compiler. > > In addition, I also updated the Kotlin ebuilds for Kotlin 1.4.x and > 1.5.x series since the only version provided by the original Spark > overlay is 1.3.72. During the version bump process for > dev-java/kotlin-common-bin, I noticed that all Kotlin version numbers > in the value of the ebuild's MAVEN_PROVIDES must be changed for the > new Kotlin version. This would not be a hard thing to do, but any > maintainers of this package would have to remember to do this manually > for every version bump, and it would be quite easy for humans to > forget such a small thing. However, if ${PV} could be used as a token > for the version number in MAVEN_PROVIDES, then this would not be an > issue at all, so I looked into any possibility of making java-ebuilder > to support variables like ${PV} in MAVEN_PROVIDES. It turned out that > this was very easy to implement. I also implemented similar support > for the SLOT variable, because the slot of a package often depends on > the version number too. In my opinion, support for ebuild variable > expansions in MAVEN_PROVIDES and SLOT will make it easier to maintain > complicated ebuilds that must be created by hand, and > dev-java/kotlin-common-bin is a perfect example of such kind of > ebuilds. The implementation of this feature has been pushed to the > 'ebuild-var-expansions' branch in my java-ebuilder fork. > > Thanks for reading this report and my new blog post if you happened to > read it. I am looking forward to coming back with more good news > regarding the Kotlin ebuilds next week. Nice summary. Thank your for cleaning up the kotlin base ebuilds. It sets a firm stage for us in the coming weeks. Yours, Benda