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

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

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