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 64A411382C5 for ; Mon, 14 Jun 2021 17:15:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8E2B1E0BF4; Mon, 14 Jun 2021 17:15:08 +0000 (UTC) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 45E27E0BF4 for ; Mon, 14 Jun 2021 17:15:08 +0000 (UTC) Received: by mail-vs1-xe2a.google.com with SMTP id z7so8206623vso.3 for ; Mon, 14 Jun 2021 10:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=8JY0Q1GUyiHH2vK13U6I8noXX6MsHY8idIeAHCkGpXA=; b=usVnR4h0AsJHeGAX8eDEt1lcDnSC1prme1iI0GdsTM256nkGkMVHjzY2ctF+9jXzEN LTd5AEaUtKioZIuWveGXsbki6nehuunArVEb9o0AAhmaKCkAVRjzkhMyaQMEd4c9BPN0 oRcDLIqEa522I9cexpJQAVXPvUjENJmeiVnPiOdrXvONkhafQ1NhcF9iISTYZwScUnzj g2QZy6MdrfLvKkQNHkqJGg2nG+gCpI1WJ8fj8WTHxqiPlow/TfhJ8Cor4ucgM+MFLnHM 4njMKMfqCPcNvkoxdrIG4RhkcAyMfuFsVsWruFYW1G/2Tj/A8MsJdlRDPoX/Gs8QKKKk BjAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=8JY0Q1GUyiHH2vK13U6I8noXX6MsHY8idIeAHCkGpXA=; b=aFSxJSUwAceqJch8hfGYAUX4r6Cuxd7jUm9VpcN1qEATgyTjAZU/bUvb2NkvSvPUjk VgU7oEnZwfferDQrfaWfmbTd94PX8K9MkObWkaLCg7P4GgLZZUlWrhRirMMqKrK6R3ID DTNBYQuNdZugdLK1/EEMVLPJix3jq3sdqTEbDGxtuHHFHYnuP8wtT1Su47xfyW8+kyil jzD5MZjM40scrE72JH2KNtgkEkyUSWcSZUzYIAk8AzMTlEfJo8VEcvltD1y2l2HcRrfl Nd7QhahwuSL/G57kr6qR3YoIIm7ypImsV4WwNeeeALEDCTjrWluDBNSegGqzP3oOHnw9 pqxw== X-Gm-Message-State: AOAM530G8pWJ9uIrzFfULXOkkMCF5WlZ3tk1jvNOzy5tM4n2dpRGa0Oy eTnMq6zdzE5RzN230+4BHYiz1BfU2S+1v2uzL6bBy99PEb96IA== X-Google-Smtp-Source: ABdhPJzTl0aaFc6K+cbP3/61auNrco0xj8CssMbGql2FQiUaF2RQuyyIPJ+qLjuV7LIsOdQfXPkPTxpiI8+a9oMBGOI= X-Received: by 2002:a05:6102:482:: with SMTP id n2mr345866vsa.60.1623690906987; Mon, 14 Jun 2021 10:15:06 -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 References: <6414e2be-6908-0df4-20bd-c50dc5c26d33@gentoo.org> In-Reply-To: <6414e2be-6908-0df4-20bd-c50dc5c26d33@gentoo.org> From: "Yuan Liao (Leo)" Date: Mon, 14 Jun 2021 10:14:31 -0700 Message-ID: Subject: Re: [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" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 359f6a91-14e2-4dbe-87bf-f694858b5490 X-Archives-Hash: 3b636a819e4877068c0ad5cf82addb8c Hi fordfrog, Thanks for reaching out and your offer to help! In fact, I have just fixed an issue in java-ebuilder and talked about it with Benda, and he suggested that I submit a pull request for it. I have already opened it [1], and a description of the issue can be found there. I think it should fix the problem, but I am interested in seeing if the issue is always reproducible given the conditions that trigger it and having another pair of eyes to look at the patch itself. If you could do a sanity check on the pull request, I would appreciate it! Thanks in advance, Leo [1]: https://github.com/gentoo/java-ebuilder/pull/10 On Mon, Jun 14, 2021 at 12:21 AM Miroslav =C5=A0ulc w= rote: > > 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 > > >