From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 87AB5138359 for ; Mon, 6 Jul 2020 10:28:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B08B5E08DD; Mon, 6 Jul 2020 10:28:16 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7E5F5E08DD for ; Mon, 6 Jul 2020 10:28:16 +0000 (UTC) Subject: Re: [gentoo-soc] Weekly Report: Big Data Infrastructure and Maven Overlay in Week 5 To: gentoo-soc@lists.gentoo.org References: <87v9j1sb3b.fsf@robot.e.airelinux.org> From: =?UTF-8?Q?Miroslav_=c5=a0ulc?= Message-ID: <21de811d-4955-8c24-076d-1ba7a2455a94@gentoo.org> Date: Mon, 6 Jul 2020 12:28:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Archives-Salt: 81dde5ae-9cb5-44c3-b364-8e04be02194a X-Archives-Hash: 299e9851438b5366bd3900ddbc370f1b 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