| 1 |
Hi folks, |
| 2 |
|
| 3 |
The second week of my project has come to an end. This week started |
| 4 |
with a wrap-up of my last week's work on java-ebuilder. Since |
| 5 |
Tuesday, I have been working on the Kotlin ebuilds in the Spark |
| 6 |
overlay created by Zongyu Zhang last year to improve their quality, |
| 7 |
and bumped the ebuilds to Kotlin 1.4 and 1.5. Meanwhile, I added |
| 8 |
another new feature for java-ebuilder that was deemed helpful in |
| 9 |
maintenance of those Kotlin ebuilds: support for ebuild variable |
| 10 |
expansions in MAVEN_PROVIDES and SLOT. |
| 11 |
|
| 12 |
The first thing I did for my project this week was to submit a pull |
| 13 |
request that fixed a bug in java-ebuilder. I mentioned it once before |
| 14 |
in my communication with fordfrog in this mailing list after the |
| 15 |
previous weekly report, and I would like to thank fordfrog again for |
| 16 |
contacting me and merging my pull request in time. I have also made a |
| 17 |
blog post [1] on my personal website which contains a description of |
| 18 |
how I investigated the issue's root cause, some alternative methods to |
| 19 |
fix the bug which I considered but did not use, and a low-level |
| 20 |
explanation of the issue. Make sure to check it out if you are |
| 21 |
interested! After that, I wrapped up all the work pertaining to |
| 22 |
multi-line MAVEN_PROVIDES support and merged related code into the |
| 23 |
master branch of my java-ebuilder fork. |
| 24 |
|
| 25 |
Next, I made a fork [2] of the Spark overlay to improve on the Kotlin |
| 26 |
ebuilds in it. The original Spark overlay provides two Kotlin |
| 27 |
ebuilds: dev-lang/kotlin-bin for the Kotlin compiler and runtime, and |
| 28 |
dev-java/kotlin-common-bin as a dummy package for the Kotlin core |
| 29 |
libraries. The latter ebuild contains a MAVEN_PROVIDES definition |
| 30 |
with Maven coordinates of some Kotlin artifacts, and I believe its |
| 31 |
main purpose is to be used by other ebuilds that require the Kotlin |
| 32 |
libraries as a dependency, especially when java-ebuilder is requested |
| 33 |
to generate ebuilds for a Maven artifact that depends on Kotlin. I |
| 34 |
really like the idea of separating the compiler plus runtime and the |
| 35 |
libraries into two packages. If someone wants to use the Kotlin |
| 36 |
libraries but does not need the Kotlin compiler, which is totally |
| 37 |
possible thanks to interoperability between Java and Kotlin, they can |
| 38 |
install dev-java/kotlin-common-bin only and use it as a normal Java |
| 39 |
library. Unfortunately, in the original Spark overlay, |
| 40 |
dev-java/kotlin-common-bin depended on dev-lang/kotlin-bin, so it had |
| 41 |
been impossible to install the libraries only and skip the Kotlin |
| 42 |
compiler. This week, I have successfully reversed the dependency |
| 43 |
relationship so users can install dev-java/kotlin-common-bin without |
| 44 |
pulling dev-lang/kotlin-bin. Then, I worked on removing bundled |
| 45 |
dependencies shipped within the Kotlin package provided by JetBrains. |
| 46 |
The upstream package contains a few JARs that are merely dependencies |
| 47 |
of the Kotlin compiler rather than components of the compiler itself, |
| 48 |
namely JetBrains' annotations library, JetBrains' fork of GNU Trove, |
| 49 |
and KotlinX Coroutines core library. For each of them, I created a |
| 50 |
separate ebuild and let dev-lang/kotlin-bin depend on it, so |
| 51 |
dev-lang/kotlin-bin would be a cohesive package whose files are all |
| 52 |
tightly coupled with the Kotlin compiler. |
| 53 |
|
| 54 |
In addition, I also updated the Kotlin ebuilds for Kotlin 1.4.x and |
| 55 |
1.5.x series since the only version provided by the original Spark |
| 56 |
overlay is 1.3.72. During the version bump process for |
| 57 |
dev-java/kotlin-common-bin, I noticed that all Kotlin version numbers |
| 58 |
in the value of the ebuild's MAVEN_PROVIDES must be changed for the |
| 59 |
new Kotlin version. This would not be a hard thing to do, but any |
| 60 |
maintainers of this package would have to remember to do this manually |
| 61 |
for every version bump, and it would be quite easy for humans to |
| 62 |
forget such a small thing. However, if ${PV} could be used as a token |
| 63 |
for the version number in MAVEN_PROVIDES, then this would not be an |
| 64 |
issue at all, so I looked into any possibility of making java-ebuilder |
| 65 |
to support variables like ${PV} in MAVEN_PROVIDES. It turned out that |
| 66 |
this was very easy to implement. I also implemented similar support |
| 67 |
for the SLOT variable, because the slot of a package often depends on |
| 68 |
the version number too. In my opinion, support for ebuild variable |
| 69 |
expansions in MAVEN_PROVIDES and SLOT will make it easier to maintain |
| 70 |
complicated ebuilds that must be created by hand, and |
| 71 |
dev-java/kotlin-common-bin is a perfect example of such kind of |
| 72 |
ebuilds. The implementation of this feature has been pushed to the |
| 73 |
'ebuild-var-expansions' branch in my java-ebuilder fork. |
| 74 |
|
| 75 |
Thanks for reading this report and my new blog post if you happened to |
| 76 |
read it. I am looking forward to coming back with more good news |
| 77 |
regarding the Kotlin ebuilds next week. |
| 78 |
|
| 79 |
Sincerely, |
| 80 |
Leo |
| 81 |
|
| 82 |
[1]: https://leo3418.github.io/2021/06/20/java-processbuilder-stdout.html |
| 83 |
[2]: https://github.com/Leo3418/spark-overlay |
Archives