| 1 |
Dne 06. 07. 20 v 11:58 Zhang Zongyu napsal(a): |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
>> i just would like to bring to your attention the content of |
| 5 |
>> ~/.java-ebuilder/cache. it contains all packages that are based at least |
| 6 |
>> on one of java eclasses, and those eclasses are also listed at the end |
| 7 |
>> of each row. might help you to find all packages that are java packages, |
| 8 |
>> even outside dev-java/ category. |
| 9 |
> Thanks for the notice. Previously I believed that those categories |
| 10 |
> other than dev-java/ and java-virtuals/* are not likely to exist in |
| 11 |
> the database of Maven, so I ignored them last week. I will fill in the |
| 12 |
> blank of non-dev-java packages this week. |
| 13 |
i suppose dev-java/ should contain mostly libraries, specific tools |
| 14 |
written in java can be found in any topic category, like dev-db/ for |
| 15 |
example. |
| 16 |
>>> https://github.com/gentoo/java-ebuilder/blob/master/scripts/meta.sh |
| 17 |
>> this seems to be a really clever idea :-) |
| 18 |
> This helped me a lot. Last week, I started with the preliminary cache |
| 19 |
> generated by meta.sh. |
| 20 |
> |
| 21 |
>> generally, using `git commit -s ...` adds the required line on new |
| 22 |
>> commits. you can also rebase your commit messages ( `git rebase -i |
| 23 |
>> c3b197f0e69c06f58f982f8d8dd16c88e2d5d518`) and push the commits again |
| 24 |
>> afaik. |
| 25 |
> Sorry for the mistake I have made, and I will rebase the repository. |
| 26 |
not a problem at all, this is easily fixable :-) |
| 27 |
>> javax/xml/bind is part of jdk:8 but was dropped later and is not present |
| 28 |
>> in jdk:11 anymore which causes some packages to fail to compile against |
| 29 |
>> jdk:11 (you can easily check with something like this: `for jdk in |
| 30 |
>> icedtea:8 openjdk:8 openjdk:11; do echo; echo $jdk; for jar in $(query |
| 31 |
>> files $jdk | grep -E ".*\.jar$"); do echo $jar; unzip -l $jar | grep |
| 32 |
>> javax/xml/bind; done; done`). you have to have those jdk installed |
| 33 |
>> before running this command. |
| 34 |
> Thanks for the information. So it seems that I do not need concern |
| 35 |
> about jaxb, and I can just set the proper classpath to make use of |
| 36 |
> JAXB stuffs instead. Maybe I will need to add a variable (e.g. |
| 37 |
> JAVA_NEEDS_RUNTIME) to control it. |
| 38 |
well, imo we should behave like there is no support for jaxb in jdk/jre |
| 39 |
at all. for example, you can force a package to be compiled using jdk:8 |
| 40 |
but user might want to run it using jdk/jre:11. in that case the package |
| 41 |
will compile fine but it won't run because of missing classes. if we |
| 42 |
depend on jaxb then it will run using jdk/jre:11 and it should also run |
| 43 |
using jdk/jre:8. it's definitely preferred to be able to also compile |
| 44 |
packages using jdk:11. that would also make (one day) possible to unmask |
| 45 |
and stabilize jdk:11. |
| 46 |
>> do these work with java-pkg-simple.eclass as is in the tree or it needs |
| 47 |
>> your updated eclass? |
| 48 |
> The class is modified by me. It can be found here[1]. The major |
| 49 |
> differences are the way to process JAVA_*_CLASSPATH variables and a |
| 50 |
> new variable called "JAVA_NEEDS_TOOLS". |
| 51 |
|
| 52 |
just make sure you do not break existing packages that use this eclass. |
| 53 |
in other words, your modifications should not affect existing packages |
| 54 |
in a way that would break them, but can bring enhancements etc. you can |
| 55 |
even use if...else...fi to introduce new stuff without breaking old one. |
| 56 |
anyway, this is just a general note, not a statement about your changes |
| 57 |
in the eclass :-) |
| 58 |
|
| 59 |
wrt java-pkg-simple.eclass enhancements, you might find this bug useful |
| 60 |
aswell: https://bugs.gentoo.org/564158 |
| 61 |
|
| 62 |
>> getting the changes in the eclass into the main tree requires review and approval by devs. |
| 63 |
> Is it correct that I should trigger the review via bugs.gentoo.org? |
| 64 |
|
| 65 |
here you can find the info for eclasses: |
| 66 |
https://devmanual.gentoo.org/eclass-writing/index.html |
| 67 |
|
| 68 |
generally, https://devmanual.gentoo.org/ is a good resource for gentoo |
| 69 |
devs :-) |
| 70 |
|
| 71 |
>> also, before getting the ebuilds into the tree, i would really like to |
| 72 |
>> see an automated test to verify that the content of our jar files |
| 73 |
>> matches the content of the maven repo jar files. without this, we might |
| 74 |
>> get issues because of missing resources and maybe even other causes. |
| 75 |
> Currently, I do not have a clear way of reaching the goal... |
| 76 |
> A preliminary thought is to maintain a modified version of java-pkg-simple. |
| 77 |
> The modified eclass will automatically compare the files in postinst phase. |
| 78 |
> I will try to work out it this week. |
| 79 |
you might also consider making it a part of the official |
| 80 |
java-pkg-simple.eclass and implement it in the test phase. just make |
| 81 |
sure you apply this test only to maven based packages and not to all |
| 82 |
packages built using java-pkg-simple.eclass. |
| 83 |
>> one more note. i noticed in your overlay you have only the ebuild files |
| 84 |
>> but the rest of the required files are missing. generally, you need to |
| 85 |
>> provide metadata.xml file for each package and need to run `repoman |
| 86 |
>> manifest` for each package. also, you have to run `repoman full` and |
| 87 |
>> also can run `pkgcheck scan` for each package to catch all issues that |
| 88 |
>> can be caught this way. |
| 89 |
> Got you, I will add the missing files. |
| 90 |
> |
| 91 |
> Regards, |
| 92 |
> Zhang Zongyu |
| 93 |
> |
| 94 |
> [1] https://github.com/6-6-6/spark-overlay/blob/master/eclass/java-pkg-simple.eclass |
| 95 |
> |
| 96 |
miroslav |
Archives