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

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

[Yuan Liao (Leo)]

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

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

[Miroslav Šulc]

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
>

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

[Yuan Liao (Leo)]

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
> >
>

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

[Benda Xu]

Hi fordfrog,

Miroslav Šulc <fordfrog@gentoo.org> writes:

> 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!

Thank you for offering help.  I am eager to see java-ebuilder continue
to shine after this years GSOC.

I would like to invite you as as co-mentor of this years' project.

@Leo, fordfrog was the mentor of the predecessor java-ebuilder project
last year.  I believe we will have a good time together bringing this
project forward.

Yours,
Benda

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

[Miroslav Šulc]

hi, i would be definitely glad if i could help. i'm still interested in 
java-ebuilder development and overall health of java packages in gentoo. 
that's where i can help. i know nothing about kotlin and similar though, 
but i guess that's not a problem. so if you want, i'd be glad to 
co-mentor this project.

best regards.

fordfrog


Dne 21. 06. 21 v 11:34 Benda Xu napsal(a):
> Hi fordfrog,
>
> Miroslav Šulc <fordfrog@gentoo.org> writes:
>
>> 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!
> Thank you for offering help.  I am eager to see java-ebuilder continue
> to shine after this years GSOC.
>
> I would like to invite you as as co-mentor of this years' project.
>
> @Leo, fordfrog was the mentor of the predecessor java-ebuilder project
> last year.  I believe we will have a good time together bringing this
> project forward.
>
> Yours,
> Benda

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

[Yuan Liao (Leo)]

Hi fordfrog,

> hi, i would be definitely glad if i could help. i'm still interested in
> java-ebuilder development and overall health of java packages in gentoo.
> that's where i can help. i know nothing about kotlin and similar though,
> but i guess that's not a problem. so if you want, i'd be glad to
> co-mentor this project.

Thanks, that would be great!  Sorry for not following up the previous
discussion in time.  I am happy to bring the discussion over to IRC
since you said you would prefer it, but to ensure I won't miss any
message from you, please permit me some time to set up an IRC client
on my Raspberry Pi server.  I've installed an IRC client on my desktop
computer that I have been occasionally using, but I cannot receive any
messages when it is closed.  Benda told me he has been running an IRC
client on a server, which is an elegant solution to my problem.  I
will contact you via IRC after it is set up.

Best regards,
Leo

On Mon, Jun 21, 2021 at 3:43 AM Miroslav Šulc <fordfrog@gentoo.org> wrote:
>
> hi, i would be definitely glad if i could help. i'm still interested in
> java-ebuilder development and overall health of java packages in gentoo.
> that's where i can help. i know nothing about kotlin and similar though,
> but i guess that's not a problem. so if you want, i'd be glad to
> co-mentor this project.
>
> best regards.
>
> fordfrog
>
>
> Dne 21. 06. 21 v 11:34 Benda Xu napsal(a):
> > Hi fordfrog,
> >
> > Miroslav Šulc <fordfrog@gentoo.org> writes:
> >
> >> 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!
> > Thank you for offering help.  I am eager to see java-ebuilder continue
> > to shine after this years GSOC.
> >
> > I would like to invite you as as co-mentor of this years' project.
> >
> > @Leo, fordfrog was the mentor of the predecessor java-ebuilder project
> > last year.  I believe we will have a good time together bringing this
> > project forward.
> >
> > Yours,
> > Benda
>