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 9A7611382C5 for ; Sun, 13 Jun 2021 22:41:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E627FE0D89; Sun, 13 Jun 2021 22:41:09 +0000 (UTC) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 9646BE0D89 for ; Sun, 13 Jun 2021 22:41:09 +0000 (UTC) Received: by mail-vk1-xa35.google.com with SMTP id u66so3121325vkb.4 for ; Sun, 13 Jun 2021 15:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dM1hBjxRmUJ6fg2iTULzZ38E3rZ0XNaP/jCjB05lQEw=; b=a+GFLMWb9dHQdntnkiBf2Oo0RARi/d5GSKaEqenRzELtGJwEOrfhhcGsGD9YjHFYXo Auf+zTPDLL23YnCI0os2+f5RT9GM8vmJ9O5LBh5IJ+HsFGZVYsIKe2MklgFr0KcIJtrh XpoDhCQwL+AE/aw/3jHMnqVKNaRcY3qmZrInHrTans4AkFFo20lLGqdWehfV1QnnGohg 2u7GVkVn2ta2cNY73lGIxnFgyWx1AxD5d0hvOrj1KiRECtbrpWCyLZklTlcCvNO+CN+r zWBjU01ZY+eZKnFiqOU4AYEoB9TpOoQqpnUcMf1U3OWed/pwZyxOpiPvyMhULBjpvvkN GNhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dM1hBjxRmUJ6fg2iTULzZ38E3rZ0XNaP/jCjB05lQEw=; b=gTGnzilQDpja+Me/JFjOxsI1FeTqebrlmchrqRrl91qxLAPU3QGNfqyiOIVXhILAgP 025IheiDvIJ4GWAw7dRHSnalO62gIqPpckBm1Yg3vvujqzXaLrJmmU760PniFKqiFip6 aQqXAAOunmhP53O2Oia04mqkWEBofHLGCh2/TxRaqrjmNzteM6xLYQnPlrwp5uYY2E0E OetTEjdcwBlukgUOgJYmo2iWUGdmAwwb4j7q5HD8do82t0OxI8wTsUeKT66WInu/4Xn5 THuRr2XieuyBXcHzZcSApUxryT8XyWvP5DcYPzq+IbhpKeniE56HijKw7PBuZj2mrphM qV4w== X-Gm-Message-State: AOAM5304wnzivuRYkiEbE1z/sQct12toLKC3qx5sJSHGz7MDfk40OckL Les0mUlIYRnVVe2apS4I2UAhDCGBTtxQB3/KxwuXJfvYiZKOEQ== X-Google-Smtp-Source: ABdhPJwYkZNej6gcowDts8ltfUlobpwUzIY9gIoDv5vGX8TWmsq6Sf8Dku/90tIDcnqFaAK6i7r2cs93qbJ6x3ZQFq8= X-Received: by 2002:a1f:9c97:: with SMTP id f145mr14830700vke.6.1623624068479; Sun, 13 Jun 2021 15:41:08 -0700 (PDT) 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 From: "Yuan Liao (Leo)" Date: Sun, 13 Jun 2021 15:40:32 -0700 Message-ID: Subject: [gentoo-soc] Week 1 Report for Big Data Infrastructure and H2O ebuilds Project To: gentoo-soc@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 0f660a2c-b429-4f30-bfc3-fa0d63f4c7f3 X-Archives-Hash: 1b1eb4c39f269395aae10086f13220f4 Hi folks, The first week of the coding period for this year's Google Summer of Code is reaching its end, so it is time for my first weekly report. This week, I first reviewed my project proposal and chose not to make any changes to the planned project timeline, so I began by working on the first work item in my plan: a system testing framework for java-ebuilder, which I will use throughout the rest of the project. Meanwhile, I have got started on the second thing I planned to implement -- support for multi-line MAVEN_PROVIDES definition in java-ebuilder. The ultimate goal of my project is to create ebuilds for the H2O platform, and java-ebuilder is a handy tool for that purpose. As a Java library hosted on Maven Central, java-ebuilder is capable of generating ebuilds for it and all its dependencies automatically. It might just work out-of-box, but it could be improved to work better. For instance, java-ebuilder uses a MAVEN_PROVIDES variable in ebuilds to keep track of the coordinates of Maven artifacts each ebuild installs. This is a magnificent design to establish a bridge from Maven-land to Portage-land. However, if an ebuild provides multiple Maven artifacts, the value for MAVEN_PROVIDES will be longer, significantly affecting readability and maintainability of the ebuild. Wrapping the value of MAVEN_PROVIDES so it spans across multiple lines, just like how *DEPEND values are commonly written in many existing ebuilds, is the best solution, but java-ebuilder did not support this. This is why I decided to make multi-line MAVEN_PROVIDES support a part of my project. I believe this change would make the ebuilds pertaining to the H2O platform more pleasant to work with. Because this feature would require modifying java-ebuilder, I sought a way to make sure my changes to java-ebuilder would not break it or introduce any other kind of regression, so I could be confident about the changes I made to its source code. The most straightforward way to achieve this is to systematically test java-ebuilder; only, there were not any tests for it. Inspection of the source code showed that it would be cumbersome to conduct unit testing with an existing testing framework like JUnit due to the fact that a lot of methods in java-ebuilder have 'void' return type, so I decided to develop my own system testing framework that would be able to compare ebuilds generated by java-ebuilder with expected ebuilds defined by a human. This also enabled me to practice test-driven development when I implemented multi-line MAVEN_PROVIDES support since no tests could be done if there was not a framework for defining and running tests at all. When designing the system testing framework for java-ebuilder, I also took possible extended use cases into account. For example, I have integrated it with the Maven project in the java-ebuilder source tree so the tests can be triggered by the conventional Maven project test command 'mvn test', which can be very useful when someone wants to set up continuous integration for the project. I tend to plan with a top-down approach but work in a bottom-up direction, which is why my initial work might seem to be unrelated to the final goal. I believe this effort is not futile because it improves upon the tools I will use later, which will eventually help increase my productivity and the quality of my work in the future. In addition, it is beneficial to not only me but any future developers who work on java-ebuilder too. My work on java-ebuilder and the testing framework can be found in my fork of it on GitHub [1]. As of today, I consider the testing framework to be stable, with no obvious issues or bugs and nothing I would like to change or further improve on, so the testing framework has been fully merged into the master branch of my repository. Multi-line MAVEN_PROVIDES support is basically complete, but I still want to add a few additional final touches to wrap it up, so it is currently still in a separate branch called 'multiline-MAVEN_PROVIDES'. In addition, I have written a new README for java-ebuilder in Markdown to replace the original one, and documentation for the testing framework has been added to the new README. That should be a comprehensive summary of all I have done this week. Thanks for reading, and I hope I will get back with more exciting news to announce for the next weekly report. Have a good week, Leo [1]: https://github.com/Leo3418/java-ebuilder