1 |
Hi folks, |
2 |
|
3 |
The first week of the coding period for this year's Google Summer of |
4 |
Code is reaching its end, so it is time for my first weekly report. |
5 |
This week, I first reviewed my project proposal and chose not to make |
6 |
any changes to the planned project timeline, so I began by working on |
7 |
the first work item in my plan: a system testing framework for |
8 |
java-ebuilder, which I will use throughout the rest of the project. |
9 |
Meanwhile, I have got started on the second thing I planned to |
10 |
implement -- support for multi-line MAVEN_PROVIDES definition in |
11 |
java-ebuilder. |
12 |
|
13 |
The ultimate goal of my project is to create ebuilds for the H2O |
14 |
platform, and java-ebuilder is a handy tool for that purpose. As a |
15 |
Java library hosted on Maven Central, java-ebuilder is capable of |
16 |
generating ebuilds for it and all its dependencies automatically. It |
17 |
might just work out-of-box, but it could be improved to work better. |
18 |
For instance, java-ebuilder uses a MAVEN_PROVIDES variable in ebuilds |
19 |
to keep track of the coordinates of Maven artifacts each ebuild |
20 |
installs. This is a magnificent design to establish a bridge from |
21 |
Maven-land to Portage-land. However, if an ebuild provides multiple |
22 |
Maven artifacts, the value for MAVEN_PROVIDES will be longer, |
23 |
significantly affecting readability and maintainability of the ebuild. |
24 |
Wrapping the value of MAVEN_PROVIDES so it spans across multiple |
25 |
lines, just like how *DEPEND values are commonly written in many |
26 |
existing ebuilds, is the best solution, but java-ebuilder did not |
27 |
support this. This is why I decided to make multi-line MAVEN_PROVIDES |
28 |
support a part of my project. I believe this change would make the |
29 |
ebuilds pertaining to the H2O platform more pleasant to work with. |
30 |
|
31 |
Because this feature would require modifying java-ebuilder, I sought a |
32 |
way to make sure my changes to java-ebuilder would not break it or |
33 |
introduce any other kind of regression, so I could be confident about |
34 |
the changes I made to its source code. The most straightforward way |
35 |
to achieve this is to systematically test java-ebuilder; only, there |
36 |
were not any tests for it. Inspection of the source code showed that |
37 |
it would be cumbersome to conduct unit testing with an existing |
38 |
testing framework like JUnit due to the fact that a lot of methods in |
39 |
java-ebuilder have 'void' return type, so I decided to develop my own |
40 |
system testing framework that would be able to compare ebuilds |
41 |
generated by java-ebuilder with expected ebuilds defined by a human. |
42 |
This also enabled me to practice test-driven development when I |
43 |
implemented multi-line MAVEN_PROVIDES support since no tests could be |
44 |
done if there was not a framework for defining and running tests at |
45 |
all. |
46 |
|
47 |
When designing the system testing framework for java-ebuilder, I also |
48 |
took possible extended use cases into account. For example, I have |
49 |
integrated it with the Maven project in the java-ebuilder source tree |
50 |
so the tests can be triggered by the conventional Maven project test |
51 |
command 'mvn test', which can be very useful when someone wants to set |
52 |
up continuous integration for the project. |
53 |
|
54 |
I tend to plan with a top-down approach but work in a bottom-up |
55 |
direction, which is why my initial work might seem to be unrelated to |
56 |
the final goal. I believe this effort is not futile because it |
57 |
improves upon the tools I will use later, which will eventually help |
58 |
increase my productivity and the quality of my work in the future. In |
59 |
addition, it is beneficial to not only me but any future developers |
60 |
who work on java-ebuilder too. |
61 |
|
62 |
My work on java-ebuilder and the testing framework can be found in my |
63 |
fork of it on GitHub [1]. As of today, I consider the testing |
64 |
framework to be stable, with no obvious issues or bugs and nothing I |
65 |
would like to change or further improve on, so the testing framework |
66 |
has been fully merged into the master branch of my repository. |
67 |
Multi-line MAVEN_PROVIDES support is basically complete, but I still |
68 |
want to add a few additional final touches to wrap it up, so it is |
69 |
currently still in a separate branch called |
70 |
'multiline-MAVEN_PROVIDES'. In addition, I have written a new README |
71 |
for java-ebuilder in Markdown to replace the original one, and |
72 |
documentation for the testing framework has been added to the new |
73 |
README. |
74 |
|
75 |
That should be a comprehensive summary of all I have done this week. |
76 |
Thanks for reading, and I hope I will get back with more exciting news |
77 |
to announce for the next weekly report. |
78 |
|
79 |
Have a good week, |
80 |
Leo |
81 |
|
82 |
[1]: https://github.com/Leo3418/java-ebuilder |