Re: [gentoo-soc] Week 1 Report for Big Data Infrastructure and H2O ebuilds Project

["Yuan Liao (Leo)" <liaoyuan@gmail.com>]

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 Šulc <fordfrog@gentoo.org> wrote:
>
> 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
> >
>