Re: [gentoo-soc] Weekly Report: Big Data Infrastructure and Maven Overlay in Week 5

["Miroslav Šulc" <fordfrog@gentoo.org>]

Dne 06. 07. 20 v 11:58 Zhang Zongyu napsal(a):
> Hello,
>
>> i just would like to bring to your attention the content of
>> ~/.java-ebuilder/cache. it contains all packages that are based at least
>> on one of java eclasses, and those eclasses are also listed at the end
>> of each row. might help you to find all packages that are java packages,
>> even outside dev-java/ category.
> Thanks for the notice. Previously I believed that those categories
> other than dev-java/ and java-virtuals/* are not likely to exist in
> the database of Maven, so I ignored them last week. I will fill in the
> blank of non-dev-java packages this week.
i suppose dev-java/ should contain mostly libraries, specific tools 
written in java can be found in any topic category, like dev-db/ for 
example.
>>>     https://github.com/gentoo/java-ebuilder/blob/master/scripts/meta.sh
>> this seems to be a really clever idea :-)
> This helped me a lot. Last week, I started with the preliminary cache
> generated by meta.sh.
>
>> generally, using `git commit -s ...` adds the required line on new
>> commits. you can also rebase your commit messages ( `git rebase -i
>> c3b197f0e69c06f58f982f8d8dd16c88e2d5d518`) and push the commits again
>> afaik.
> Sorry for the mistake I have made, and I will rebase the repository.
not a problem at all, this is easily fixable :-)
>> javax/xml/bind is part of jdk:8 but was dropped later and is not present
>> in jdk:11 anymore which causes some packages to fail to compile against
>> jdk:11 (you can easily check with something like this: `for jdk in
>> icedtea:8 openjdk:8 openjdk:11; do echo; echo $jdk; for jar in $(query
>> files $jdk | grep -E ".*\.jar$"); do echo $jar; unzip -l $jar | grep
>> javax/xml/bind; done; done`). you have to have those jdk installed
>> before running this command.
> Thanks for the information. So it seems that I do not need concern
> about jaxb, and I can just set the proper classpath to make use of
> JAXB stuffs instead. Maybe I will need to add a variable (e.g.
> JAVA_NEEDS_RUNTIME) to control it.
well, imo we should behave like there is no support for jaxb in jdk/jre 
at all. for example, you can force a package to be compiled using jdk:8 
but user might want to run it using jdk/jre:11. in that case the package 
will compile fine but it won't run because of missing classes. if we 
depend on jaxb then it will run using jdk/jre:11 and it should also run 
using jdk/jre:8. it's definitely preferred to be able to also compile 
packages using jdk:11. that would also make (one day) possible to unmask 
and stabilize jdk:11.
>> do these work with java-pkg-simple.eclass as is in the tree or it needs
>> your updated eclass?
> The class is modified by me. It can be found here[1]. The major
> differences are the way to process JAVA_*_CLASSPATH variables and a
> new variable called "JAVA_NEEDS_TOOLS".

just make sure you do not break existing packages that use this eclass. 
in other words, your modifications should not affect existing packages 
in a way that would break them, but can bring enhancements etc. you can 
even use if...else...fi to introduce new stuff without breaking old one. 
anyway, this is just a general note, not a statement about your changes 
in the eclass :-)

wrt java-pkg-simple.eclass enhancements, you might find this bug useful 
aswell: https://bugs.gentoo.org/564158

>> getting the changes in the eclass into the main tree requires review and approval by devs.
> Is it correct that I should trigger the review via bugs.gentoo.org?

here you can find the info for eclasses: 
https://devmanual.gentoo.org/eclass-writing/index.html

generally, https://devmanual.gentoo.org/ is a good resource for gentoo 
devs :-)

>> also, before getting the ebuilds into the tree, i would really like to
>> see an automated test to verify that the content of our jar files
>> matches the content of the maven repo jar files. without this, we might
>> get issues because of missing resources and maybe even other causes.
> Currently, I do not have a clear way of reaching the goal...
> A preliminary thought is to maintain a modified version of java-pkg-simple.
> The modified eclass will automatically compare the files in postinst phase.
> I will try to work out it this week.
you might also consider making it a part of the official 
java-pkg-simple.eclass and implement it in the test phase. just make 
sure you apply this test only to maven based packages and not to all 
packages built using java-pkg-simple.eclass.
>> one more note. i noticed in your overlay you have only the ebuild files
>> but the rest of the required files are missing. generally, you need to
>> provide metadata.xml file for each package and need to run `repoman
>> manifest` for each package. also, you have to run `repoman full` and
>> also can run `pkgcheck scan` for each package to catch all issues that
>> can be caught this way.
> Got you, I will add the missing files.
>
> Regards,
> Zhang Zongyu
>
> [1] https://github.com/6-6-6/spark-overlay/blob/master/eclass/java-pkg-simple.eclass
>
miroslav