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 E8FD41382C5 for ; Mon, 14 Jun 2021 07:21:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2AD72E0CCC; Mon, 14 Jun 2021 07:21:31 +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 ADC57E0CCC for ; Mon, 14 Jun 2021 07:21:30 +0000 (UTC) Subject: Re: [gentoo-soc] Week 1 Report for Big Data Infrastructure and H2O ebuilds Project To: gentoo-soc@lists.gentoo.org References: From: =?UTF-8?Q?Miroslav_=c5=a0ulc?= Message-ID: <6414e2be-6908-0df4-20bd-c50dc5c26d33@gentoo.org> Date: Mon, 14 Jun 2021 09:21:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Archives-Salt: b9c59fa3-9114-4d92-be92-e19bae34d37e X-Archives-Hash: 382d365eb69f697941e32831404d3729 hi, i'm glad that you do more work on improving java-ebuilder. i'm the original author of the idea and of the original code and i'm still interested in improvements of it. i did not have time to look into your repo yet but will try to find some time to do so. if you need some assistance or info wrt java-ebuilder or java on gentoo generally, feel free to ping me. you can by email though i rather prefer online communication. you can find me at irc.libera.chat as fordfrog. you might find me in #gentoo-java or you can /query me. though discussing java related stuff at #gentoo-java might be beneficial for others too. thank you for what you do! fordfrog Dne 14. 06. 21 v 0:40 Yuan Liao (Leo) napsal(a): > 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 >