chewi 15/03/06 22:34:29 Added: java-project-meeting-log-20150306.txt Log: Java project meeting log for 20150306.
Revision Changes Path 1.1 xml/htdocs/proj/en/java/meeting-logs/java-project-meeting-log-20150306.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/java/meeting-logs/java-project-meeting-log-20150306.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/java/meeting-logs/java-project-meeting-log-20150306.txt?rev=1.1&content-type=text/plain Index: java-project-meeting-log-20150306.txt =================================================================== 21:00 #gentoo-java: <@fordfrog> so first topic: Who makes the decision that to become Gentoo Java dev we require Java quizes? Can we loosen that for gnu_andrew? (fordfrog) 21:00 #gentoo-java: <+monsieurp> just for him? 21:00 #gentoo-java: <+monsieurp> :P 21:00 #gentoo-java: <@fordfrog> he's not gonna package java packages, just java 21:01 #gentoo-java: <+wltjr> I was one who pushed for quizzes back in the day, but it wasn't so much for requirement as to get familiar with the java stuff 21:01 #gentoo-java: <@Chewi> if we largely agree to loosen it for him, I'm fine with that 21:01 #gentoo-java: <+monsieurp> ok fine.. 21:01 #gentoo-java: <@Chewi> but generally, I think it should apply 21:01 #gentoo-java: <@Chewi> sorry monsieurp :P 21:01 #gentoo-java: <+wltjr> I think I might have even brought up the concept, but it was never implemented, like it wasn't part of recruiting and no policy ever said to join java team to must pass the java quiz 21:01 #gentoo-java: <@fordfrog> i'm for too to make exception for him, but just for him 21:01 #gentoo-java: * monsieurp sobs 21:02 #gentoo-java: <+wltjr> I would not be making exceptions for people 21:02 #gentoo-java: <@fordfrog> there is a different between java app package and java packager 21:02 #gentoo-java: <@Chewi> monsieurp: your accident with inherit the other day goes to show how important it is ;) 21:02 #gentoo-java: <@fordfrog> difference* 21:02 #gentoo-java: <+wltjr> I would make it the rule, its not required to take the java quiz to join the team, but its recommended 21:02 #gentoo-java: <+wltjr> fordfrog: that is true, but there is no difference between gentoo developers 21:02 #gentoo-java: <@fordfrog> wltjr, gnu_andrew works and will work just on packaging icedtea ... it's not java package 21:03 #gentoo-java: <+wltjr> technically anyone can touch any ebuild, its only in recent years they have become policy natzis, but I don't even think now you have to be part of a team or herd to touch a package or packages 21:03 #gentoo-java: <+wltjr> fordfrog: I am familiar, just saying no exceptions were ever made for me to return 21:03 #gentoo-java: <+monsieurp> Chewi: true 21:03 #gentoo-java: <+wltjr> and not just saying me, I hired a business consultant firm years ago 21:03 #gentoo-java: <+monsieurp> Chewi: nobody's perfect though 21:03 #gentoo-java: <+wltjr> they said treat everyone the same, no special treatment, even family, friends, given everyone the same fair good service 21:03 #gentoo-java: <+monsieurp> Chewi: only Brits, apparently 21:04 #gentoo-java: <+wltjr> so I would keep the quiz, and for anyone who is to be part of the team and actively work the java packages its good to do the quiz 21:04 #gentoo-java: <+wltjr> but having 3 quizzes to become a java dev, increases the work and decreases the chance of new devs 21:04 #gentoo-java: <+wltjr> I mean there is no perl quiz, and those ebuilds are pretty different 21:05 #gentoo-java: <+wltjr> same for others 21:05 #gentoo-java: <@fordfrog> wltjr, that might be true but it's not the current topic 21:05 #gentoo-java: <@Chewi> Perl is a bit simpler, you can only have one version of Perl installed 21:05 #gentoo-java: <@fordfrog> so generally we agree on that for gnu_andrew if he's gonna maintain just icedtea family 21:05 #gentoo-java: <+monsieurp> Perl ebuilds are fairly straightforward 21:05 #gentoo-java: <+wltjr> fordfrog: well your asking about the quiz requirements, I am telling you that comes from the java team, and I was the one who some what started that, and in hind sight isn't the best idea 21:06 #gentoo-java: <@Chewi> I think we're broadly in agreement anyway so let's move on 21:06 #gentoo-java: <+wltjr> fordfrog: I know your speaking of gnu_andrew, I am speaking in general, but he really isn't going to be part of the team per se, just managing 1 ebuild, so is no different than a regular gentoo dev 21:06 #gentoo-java: <+wltjr> I am just saying should not do something for gnu_andrew that would not be done for another, things should be fair treatment all around 21:06 #gentoo-java: <@Chewi> EAPIs 21:06 #gentoo-java: <@fordfrog> wltjr, yes. wrt the quizzes, if you have some idea, you can put them on the java project page or ask someone 21:06 #gentoo-java: <@fordfrog> next topic: Upgrading EAPI0/EAPI1/EAPI2 ebuilds - (mrueg) 21:07 #gentoo-java: <@Chewi> I've misplaced those numbers mrueg gave us but we're pretty bad for EAPI 1 21:07 #gentoo-java: <@fordfrog> does it technically hurt? 21:07 #gentoo-java: <@fordfrog> does it break something? 21:07 #gentoo-java: <@Chewi> this isn't our highest priority but I don't want to be the group holding everyone else back 21:07 #gentoo-java: <@Chewi> killing old EAPIs allows the PMS and implementations to be simplified 21:07 #gentoo-java: <@Chewi> which is good 21:08 #gentoo-java: <+wltjr> wow that again... well if packages were being maintained EAPI would be moot 21:08 #gentoo-java: <+wltjr> long ago we went bumping packages for EAPI changes 21:08 #gentoo-java: <@Chewi> wltjr: was about to say as much 21:08 #gentoo-java: <+wltjr> anytime you touch a package it should be updated to latest EAPI 21:08 #gentoo-java: <@Chewi> hopefully a lot of things will be bumped/chucked soon anyway 21:09 #gentoo-java: <@Chewi> we probably shouldn't bother just bumping the EAPI for ancient versions of things 21:09 #gentoo-java: <+monsieurp> how many Java ebuilds with an EAPI < 5 are in the tree at the moment? 21:09 #gentoo-java: <@fordfrog> so we have two options, either we update affected packages (just eapi) or we let it happen some day through bumps 21:09 #gentoo-java: <+wltjr> this is interesting -> ? 21:09 #gentoo-java: <+wltjr> 2008-02-12.log:15:12 <@Betelgeuse> gnu_andrew: Did you look at the quizes? 21:09 #gentoo-java: <@Chewi> lol 21:09 #gentoo-java: <@fordfrog> omg :-D 21:09 #gentoo-java: <@Chewi> http://dev.gentoo.org/~mrueg/eapi/eapi1.txt 21:09 #gentoo-java: <+wltjr> 2008-05-22.log:18:40 < gnu_andrew> I need to complete the quiz right? 21:09 #gentoo-java: <+wltjr> I have history of this stuff I keep trying to tell you all :) 21:10 #gentoo-java: <@fordfrog> matrix never forgets ;-) 21:10 #gentoo-java: <+wltjr> looking for when the java quiz idea came about 21:10 #gentoo-java: <+monsieurp> dev-java 42 21:10 #gentoo-java: <+monsieurp> fuck 21:10 #gentoo-java: <+monsieurp> ! 21:10 #gentoo-java: <+monsieurp> that's a lot 21:10 #gentoo-java: <@Chewi> as I mentioned before 21:10 #gentoo-java: <+wltjr> java has been hurting since 2008, why does this surprise people I have been saying it for years 21:11 #gentoo-java: <@Chewi> we're the highest for EAPI 0, 1 and 2 :( 21:11 #gentoo-java: <@Chewi> 42 is actually the lowest of those three lol 21:11 #gentoo-java: <+wltjr> why I am not to pleased with those who were dev when i were that are not doing much, fordfrog is one of the few that maintained packages then and is still now... current stuff 21:11 #gentoo-java: <+wltjr> general java ebuilds have been neglected 21:11 #gentoo-java: <+monsieurp> so what's your plan, Chewi? how do you wanna go about tackling them? 21:11 #gentoo-java: <+wltjr> and even when I was bumping ecj I got nit picked on my contributions and they put a lower EAPI into tree or something 21:12 #gentoo-java: <@Chewi> I would say don't worry about EAPI 0 or 2 for now 21:12 #gentoo-java: <@Chewi> plenty of other offenders in those groups 21:12 #gentoo-java: <@fordfrog> well, we have the two choices, i suggest we try to bump the eapis (without ebuild bump) and if we find out it's impossible, we will go the "let it happen" way, opinions? 21:12 #gentoo-java: <@Chewi> but we should knock some of those EAPI 1s on the head because there aren't many others in that group 21:12 #gentoo-java: <+wltjr> I would start with packages that are current, can be bumped and updated 21:12 #gentoo-java: <+wltjr> I would then remove packages that are dead, jikes, and others sevletapi 21:13 #gentoo-java: <+wltjr> I would then update the rest that might not have changed 21:13 #gentoo-java: <+wltjr> going after straight EAPI does not make sense, its lowest priority really of the java issues 21:13 #gentoo-java: <@fordfrog> that's a lot of work for such a small team... 21:13 #gentoo-java: <@Chewi> hold on, let me see what some of these packages are < DISCONNECTED, SORRY! ;) > 21:15 #gentoo-java: < Chewi_> back :) 21:15 #gentoo-java: <+monsieurp> Chewi_: geez 21:15 #gentoo-java: <+wltjr> I believe there are packages in tree that are not deps of any other, so not sure those are priority to go after 21:15 #gentoo-java: < Chewi_> right I've got the list of EAPI 1 packages 21:15 #gentoo-java: < Chewi_> fairly random mix but some stuff we need to keep around 21:16 #gentoo-java: <+monsieurp> care to share it? 21:16 #gentoo-java: <+wltjr> fordfrog: I am not optomistic, I have waited 7+ years, I think progress will be made, but everyone has jobs and a real life, this is allot of work 21:16 #gentoo-java: < Chewi_> qgrep -H "EAPI=1"; qgrep -H "EAPI=\"1" 21:16 #gentoo-java: <+wltjr> not to be negative nancy, but let me put it this way 21:16 #gentoo-java: < mrueg> Chewi_: you can also use http://dev.gentoo.org/~mrueg/eapi/eapi-per-cat.py 21:16 #gentoo-java: < Chewi_> dev-java/java-dep-check, dev-java/commons-lang/commons-lang-2.6.ebuild probably need to stay, for example 21:16 #gentoo-java: < mrueg> it'll print out eapi1 ones. 21:16 #gentoo-java: <+wltjr> serlvetapi never got removed when we had many active devs, nor did all ebuilds get updated to current EAPI, its a difficult goal even when you have many active devs, more so when you dont 21:17 #gentoo-java: <+wltjr> fordfrog: I think at some point the amount of packages will have to be trimmed down to an amount that can be maintained etc 21:17 #gentoo-java: <+wltjr> things like resin which there is no maintainer, might have to be removed from tree, to an overlay till a maintainer shows 21:17 #gentoo-java: < Chewi_> I guess all we can say for now is we acknowledge the problem, the number will go down, but it's not priority #1 21:18 #gentoo-java: <@fordfrog> ok, so we let it be, right? 21:18 #gentoo-java: <+monsieurp> Chewi_: ok 21:18 #gentoo-java: < Chewi_> ok 21:18 #gentoo-java: <@fordfrog> next topic: Almost every project uses Maven now but Maven doesn't play well with Portage. What to do about that? (Chewi) 21:18 #gentoo-java: <+monsieurp> if we can bump a package or two when time permits, just do it (like closing down old bugs, basically) 21:18 #gentoo-java: * Chewi_ takes a deep breath 21:19 #gentoo-java: <+wltjr> problem is bumping some packages require bumping deps, and you quickly get into allot of work 21:19 #gentoo-java: <@fordfrog> Chewi, stop playing and give us your idea on the topic ;-) 21:19 #gentoo-java: <@Chewi> I think most of you are familiar with my plan now 21:19 #gentoo-java: <@Chewi> it's not concrete yet but 21:19 #gentoo-java: <@Chewi> I'm not a fan of running Maven directly. building it alone is a nightmare with little to gain. 21:20 #gentoo-java: <@Chewi> trying to tame the binary version seems tricky 21:20 #gentoo-java: <@Chewi> Red Hat are spending many paid man hours of it 21:20 #gentoo-java: <@fordfrog> we just need to build the packages, we do not need to use maven for that 21:20 #gentoo-java: <@Chewi> exactly 21:21 #gentoo-java: <+monsieurp> Chewi: are they getting somewhere? (RH) 21:21 #gentoo-java: <@Chewi> monsieurp: I only know what zxiiro told us but it sounds like they're only just about coping 21:21 #gentoo-java: <+monsieurp> okay.. 21:21 #gentoo-java: <@Chewi> I have now demonstrated many times that java-pkg-simple does an admirable job but a new eclass built for the purpose would do even better 21:21 #gentoo-java: <+wltjr> I don't think redhat or most others have any duplicate jar policies so they can get away with much 21:22 #gentoo-java: <@Chewi> if you haven't noticed, Maven has standardised a lot of things that Ant left open 21:22 #gentoo-java: <@fordfrog> there are generally two levels of maven packages, simple ones, that contain just deps and maybe something more. and complicated once 21:22 #gentoo-java: <@Chewi> like the directory structure of a project 21:23 #gentoo-java: <@Chewi> even running the tests follows quite a strict pattern 21:23 #gentoo-java: <@fordfrog> so, maybe a dumb idea, we could make a simple parser that maps the deps to our packages and scan for source and target and build the package based on that ... but maybe i'm wrong 21:23 #gentoo-java: <@Chewi> so you should need to specify very little in the ebuilds 21:23 #gentoo-java: <@Chewi> fordfrog: already got something like that in mind 21:23 #gentoo-java: <@fordfrog> Chewi, that'd be cool 21:23 #gentoo-java: <+wltjr> I would be curious what kiorky's thoughts on such would be 21:23 #gentoo-java: <@Chewi> I would like to build a tool that can read a pom.xml and generate a rough ebuild 21:24 #gentoo-java: <+monsieurp> which is why you mentioned python the other day 21:24 #gentoo-java: <@Chewi> it could even generate a rough DEPEND list if we include the Maven artifact ID in metadata.xml 21:24 #gentoo-java: <@fordfrog> Chewi, i suggest it would instead generate the ebuild methods that could be overriden if needed 21:24 #gentoo-java: <+monsieurp> +1 21:24 #gentoo-java: <@fordfrog> so not a tool that statically generates the ebuild but instead dynamically based on the pom 21:25 #gentoo-java: <+wltjr> a maven eclass 21:25 #gentoo-java: <@fordfrog> yes 21:25 #gentoo-java: <+monsieurp> fordfrog: and fill the blanks if needed, as you've said 21:25 #gentoo-java: <+monsieurp> I like this idea 21:25 #gentoo-java: <@Chewi> fordfrog: I don't think there'll need to be much method stuff to be honest 21:25 #gentoo-java: <+wltjr> replicated, again I think kiorky might have good input there if we can solicit such from him 21:25 #gentoo-java: <+monsieurp> a skeleton ebuild 21:25 #gentoo-java: <@Chewi> if you look at most java-pkg-simple ebuilds, there are often no functions at all 21:25 #gentoo-java: <@fordfrog> in such case, if that would work, the ebuilds would be really simple for maven packages 21:25 #gentoo-java: <@Chewi> it's only the test stuff that it doesn't deal with 21:26 #gentoo-java: <@Chewi> storing the artifact ID in metadata.xml (there's already an ideal tag for this) would make the turnaround much quicker for adding new packages 21:27 #gentoo-java: <@Chewi> you wouldn't have to spend so long figuring out what the hell provides a certain dep 21:27 #gentoo-java: <@Chewi> which can be tricky sometimes 21:27 #gentoo-java: <@fordfrog> yes, we would need some database for mapping 21:27 #gentoo-java: <@fordfrog> or "database" :-) 21:27 #gentoo-java: <+wltjr> Chewi: just have to make sure it doesn't violate any policies on metadata.xml, not sure if you can put other stuff in there 21:27 #gentoo-java: <@Chewi> it wouldn't need to be exact, just enough to get you 90% of the way there 21:28 #gentoo-java: <@fordfrog> well, my idea was to automate this 21:28 #gentoo-java: <@Chewi> wltjr: I checked the DTD, we'd need a small adjustment made 21:28 #gentoo-java: <+wltjr> Chewi: yeah but you might have to submit such as a glep not sure, its a pretty strict format of whats allowed and not 21:28 #gentoo-java: <@Chewi> fordfrog: you always need to specify deps in an ebuild anyway, it can't come from the pom.xml at build time 21:28 #gentoo-java: <+wltjr> http://devmanual.gentoo.org/ebuild-writing/misc-files/metadata/ 21:28 #gentoo-java: <+monsieurp> Chewi: which programming language do you wanna use for this task? 21:28 #gentoo-java: <@Chewi> wltjr: yeah it's not a change I was going to make lightly, I'll find out who to speak to 21:29 #gentoo-java: <@Chewi> monsieurp: probably Python 21:29 #gentoo-java: <+wltjr> Chewi: even though a small adjustment I think it would end up being a global adjustment, and I think such requires a glep I could be wrong 21:29 #gentoo-java: <@fordfrog> Chewi, i thought it is possible, like it works already for some flags for example 21:30 #gentoo-java: <+monsieurp> Chewi: cool! :) I can help then. 21:30 #gentoo-java: <@Chewi> <!-- specify a type of package identification tracker --> 21:30 #gentoo-java: <@Chewi> <!ELEMENT remote-id (#PCDATA)> 21:30 #gentoo-java: <@Chewi> <!ATTLIST remote-id type (bitbucket|cpan|cpan-module|cpe|cran|ctan|freecode|freshmeat|github|gitorious|google-code|launchpad|pear|pecl|pypi|rubyforge|rubygems|sourceforge|sourceforge-jp|vim) #REQUIRED> 21:30 #gentoo-java: <+wltjr> I would try to do less python, but that is just me, I dislike java stuff depending on python, I know portage is, but even that would be nice to have the stuff in other 21:30 #gentoo-java: <@Chewi> that's from the DTD 21:30 #gentoo-java: <@Chewi> we just need an extra type in there 21:30 #gentoo-java: <+monsieurp> wltjr: I was going to suggest doing it in Java since Java has top-notch support for XML data 21:30 #gentoo-java: <+wltjr> Chewi: https://wiki.gentoo.org/wiki/GLEP:34 21:31 #gentoo-java: <+monsieurp> wltjr: and, well, we're dealing with Java stuff 21:31 #gentoo-java: <@Chewi> what I thought would also be cool is if we could avoid repeating ourselves like we've had to do with EANT_GENTOO_CLASSPATH 21:31 #gentoo-java: <+wltjr> monsieurp: you could, but there is no support for such and not sure if that would be acceptable or not 21:31 #gentoo-java: <@Chewi> it should be possible to go through DEPEND and work out what should go in the classpath 21:31 #gentoo-java: <+wltjr> monsieurp: offhand might get into circular deps 21:32 #gentoo-java: <@Chewi> circular deps were a concern 21:32 #gentoo-java: <@Chewi> not sure I could stomach writing much Java 21:32 #gentoo-java: <+monsieurp> thing is, most portage libraries are written in Python 21:32 #gentoo-java: <+monsieurp> so.. you don't have much choice 21:32 #gentoo-java: <@Chewi> and while we might lose some Java integration, we could gain some Portage integration and do some clever tricks there 21:32 #gentoo-java: <+wltjr> I would say C, C++, Bash, or Python 21:33 #gentoo-java: <+monsieurp> please no, not bash 21:33 #gentoo-java: <@Chewi> and we can always shell out to Java if we have too 21:33 #gentoo-java: <+wltjr> Chewi: I think you will have to make a glep for such, that glep talks about the same thing you want to do, update dtd file 21:33 #gentoo-java: <+monsieurp> if we have to parse an XML stream, Bash is *not* the right tool for the task. 21:33 #gentoo-java: <@Chewi> I don't want to rely heavily on Bash because I know from prior experience (Eclipse stuff) that working with XML in Bash is pure hell :) 21:33 #gentoo-java: <+wltjr> rule of thumb, anything that effects all of gentoo, glep 21:34 #gentoo-java: <+monsieurp> Chewi: +1 21:34 #gentoo-java: <@Chewi> wltjr: it's cool, I'll do whatever needs to be done 21:34 #gentoo-java: <+wltjr> I am a big fan of libxml, if I ever rewrite the xml rewriter I would use that 21:34 #gentoo-java: <@Chewi> but this is early days 21:34 #gentoo-java: <@Chewi> I'll prototype this baby up ASAP and see how it goes 21:34 #gentoo-java: <+wltjr> I did stuff with it for tomcat long ago, terrd, parsed tomcats old xml status into rrdtool format 21:34 #gentoo-java: <@fordfrog> guys, we are going too deep on technical stuff i guess, lets agree on the packaging concept 21:35 #gentoo-java: <@Chewi> fordfrog: I just wanted some feedback on my rough ideas 21:35 #gentoo-java: <@Chewi> sounds positive :) 21:35 #gentoo-java: <+monsieurp> fordfrog: yes true, time is ticking 21:35 #gentoo-java: <@fordfrog> Chewi, can we move now on? 21:35 #gentoo-java: <@Chewi> I'll keep you guys posted on it anyway 21:35 #gentoo-java: <@Chewi> so yeah 21:36 #gentoo-java: <+monsieurp> +1 for your idea Chewi, sounds good, you have our blessing :P 21:36 #gentoo-java: <@fordfrog> next topic: Java has no preprocessor, hence build-time dependencies are rarely optional. This has become a major burden. Maybe Soot can help? (Chewi) 21:36 #gentoo-java: <@Chewi> ercpe misunderstood this one 21:36 #gentoo-java: <+monsieurp> what is it that you meant 21:36 #gentoo-java: <@fordfrog> i do not understand it either. can you shed some light on it? 21:36 #gentoo-java: <@Chewi> I've mentioned this before but I'll show you a perfect example 21:37 #gentoo-java: <+wltjr> I think itext could be an example 21:37 #gentoo-java: <+wltjr> it does not need the bc stuff most times to run, but it does to compile 21:37 #gentoo-java: <@Chewi> https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/pom.xml;h=470a02a02113f92dfcb2610973f6b98a481fdc0c;hb=HEAD 21:38 #gentoo-java: <@Chewi> I had to package this 21:38 #gentoo-java: <@Chewi> it was hell 21:38 #gentoo-java: <@Chewi> there is only one mandatory run time dependency 21:38 #gentoo-java: <@Chewi> and tons of optional ones 21:38 #gentoo-java: <@Chewi> but 21:38 #gentoo-java: <+wltjr> you need all to compile 21:38 #gentoo-java: <@Chewi> exactly 21:39 #gentoo-java: <@Chewi> this is really starting to hurt us 21:39 #gentoo-java: <@fordfrog> Chewi, what's your suggestion? 21:39 #gentoo-java: <@Chewi> although I wouldn't say it's a bad thing for free software, Maven has made the problem worse 21:39 #gentoo-java: <+wltjr> I don't see a way around that really, have to modify code in all projects and even then not sure you could change it that way 21:39 #gentoo-java: <@Chewi> it's a slightly off the wall idea but there might be a way... 21:40 #gentoo-java: <@Chewi> Soot can compile java source in several forms, including regular classes but it has a clever trick 21:40 #gentoo-java: <+wltjr> even if you change imports, and put the stuff else where and do not directly import, it still has to compile, and will need to reference the stuff to compile, no equivalent of header files in java 21:40 #gentoo-java: <@Chewi> Soot can create stubs on the fly where classes are missing 21:41 #gentoo-java: <+monsieurp> does it really work? 21:41 #gentoo-java: <@Chewi> I'm not sure 21:41 #gentoo-java: <+monsieurp> how are these deps resolved then at execution time? 21:41 #gentoo-java: <@Chewi> I did try it for log4j but it uses some Java source features that are too new 21:41 #gentoo-java: <@Chewi> monsieurp: it's normal to simply leave out optional runtime deps in Java 21:41 #gentoo-java: <+wltjr> not sure that would work, not a bad idea 21:42 #gentoo-java: <@fordfrog> so i guess we need more info before we can decide on that... 21:42 #gentoo-java: <@Chewi> there is talk of Soot updating its dependencies to deal with newer Java 21:42 #gentoo-java: <@Chewi> maybe I was just unlucky with log4j 21:42 #gentoo-java: <+wltjr> I think its a problem not specific to java really, more coding style, other languages could have compile time dependencies not used at runtime, but you can't make them optional because of code 21:42 #gentoo-java: <@Chewi> I think the last release was quite old too 21:42 #gentoo-java: <@Chewi> might have better luck with git master 21:43 #gentoo-java: <@Chewi> wltjr: it's due to the lack of Java preprocessor 21:43 #gentoo-java: <+zxiiro> yeah redhat has full time staff maintaining maven stuff. They also have scripts that they created to automate the work and using xmvn to ensure they they are only using redhat compiled sources 21:43 #gentoo-java: <@Chewi> no #ifdef 21:43 #gentoo-java: <+wltjr> Chewi: it might not be something that can be resolved, and why deps become a major issue in java packaging in gentoo 21:43 #gentoo-java: <+zxiiro> sorry for being late to the party :) 21:43 #gentoo-java: <+wltjr> you want to package A, but it requires the rest of the alphabet... so you have to package that stuff first and none is used runtime... 21:44 #gentoo-java: <@Chewi> so I'm not saying this will definitely work but I wanted to make you guys aware 21:44 #gentoo-java: <+wltjr> zxiiro: do they have any policies on not duplicating jars in a system? 21:44 #gentoo-java: <@fordfrog> guys, 15 mins left 21:44 #gentoo-java: <@Chewi> I'll experiment more when I get a chance 21:44 #gentoo-java: <@Chewi> moving on 21:44 #gentoo-java: <@fordfrog> next topic: Increased use of third party libraries is slowly but surely dragging us into jar hell with version conflicts. Can we apply USE-style dependencies to the package.env format to avoid this? (Chewi) 21:44 #gentoo-java: <+wltjr> Chewi: I think if you look, you will find the same issue in other packages in other langauges 21:44 #gentoo-java: <+zxiiro> wltjr: yeah I think xmvn helps them with that somehow but honestly I haven't looked into it deeply enough to know for sure 21:44 #gentoo-java: <@Chewi> this point is slightly related to the last one 21:45 #gentoo-java: <+zxiiro> if we want a similar system as them there's 2 things we need to bootstrap, Maven, and then Xmvn 21:45 #gentoo-java: <+monsieurp> so it means introducing java-specific use flags? 21:45 #gentoo-java: <+zxiiro> once we have those we can compile everythign else and guarentee we're only building sources we compile 21:45 #gentoo-java: <@Chewi> zxiiro: stay on topic please :P 21:45 #gentoo-java: <+monsieurp> zxiiro: let's discuss maven after the meeting 21:45 #gentoo-java: <@Chewi> if we can deal with optional run time deps then regular USE flags come into play but... 21:46 #gentoo-java: <@Chewi> even if we don't, Java-specific USE flags can still help 21:46 #gentoo-java: <@Chewi> I had an interesting case with minecraft-server 21:46 #gentoo-java: <@Chewi> it directly depended on log4j 2 21:46 #gentoo-java: <+wltjr> java specific use flags? 21:46 #gentoo-java: <+monsieurp> Minecraft! bloody hell. 21:46 #gentoo-java: <@Chewi> but a subdependency "optionally" depended on log4j 1 21:46 #gentoo-java: <@Chewi> so both versions got pulled in at once 21:46 #gentoo-java: <@fordfrog> osgi frameworks support several versions of single library during runtime afaik... but i guess it's unrelated :-) 21:47 #gentoo-java: <@Chewi> luckily it doesn't explode but it does produce a warning 21:47 #gentoo-java: <@Chewi> in other situations, this could get worse 21:47 #gentoo-java: <+wltjr> Chewi: did you look how it was brought in? how the classpath was built was it by an eclass or java-config 21:47 #gentoo-java: <@Chewi> wltjr: yes I know why it was, forget exactly which package it was 21:47 #gentoo-java: <+wltjr> that goes in line with what i was talking about last night 21:47 #gentoo-java: <@Chewi> it's not that the dependency was wrong but 21:48 #gentoo-java: <@Chewi> log4j 1 isn't strictly required, it's only optional, and ideally it would only be pulled in if it's actually required 21:48 #gentoo-java: <+monsieurp> well.. if you do need all jars at compile time even though half of them are optional 21:48 #gentoo-java: <+wltjr> Chewi: I am curious how the depency classpath was produced, I get that a sub depencency depending on log4j 1 21:48 #gentoo-java: <+monsieurp> (as you've just explained) 21:48 #gentoo-java: <+monsieurp> how do you want to create a modular system then? 21:48 #gentoo-java: <@Chewi> this isn't really about compile time 21:48 #gentoo-java: <+monsieurp> I don't get it 21:49 #gentoo-java: <+wltjr> its a classpath issue it goes inline with what I was talking about last night 21:49 #gentoo-java: <+wltjr> package A depends on 1 jar from say ant-core, package B is a depdend of package A, and package B pulls in all ant-core jars 21:49 #gentoo-java: <+monsieurp> wltjr: ok, go on 21:49 #gentoo-java: <+wltjr> so package A ends up with all ant-core jars, but it only needs 1 21:49 #gentoo-java: <@Chewi> wltjr: that's less of a problem but it's similar, yes 21:50 #gentoo-java: <+monsieurp> hm I see. 21:50 #gentoo-java: <+wltjr> just like Chewi package needs log4j 2, but log4j 1 ends up on classpath as a dep of a dep 21:50 #gentoo-java: <@Chewi> so I did look into whether this would be feasible 21:50 #gentoo-java: <+monsieurp> in theory, it looks great but in practice, it's kinda useless right? 21:50 #gentoo-java: <@Chewi> the DEPEND string in package.env could be extended to support it 21:50 #gentoo-java: <@Chewi> I looked over the Python and had some rough ideas 21:50 #gentoo-java: <@fordfrog> maven has a feature that when you define dep, you can prevent its dep to create the chain 21:50 #gentoo-java: <+wltjr> but its not a run time dep, but a compile time, package B is compiled, it does not need log4j 1 anymore unless that code is used, which since its a dep of one that uses log4j 2, it does not use the logging aspects of the library/dependency that pulls in log4j 1 21:51 #gentoo-java: <+monsieurp> cause you end up with all jars on your system anyway. 21:51 #gentoo-java: <+wltjr> I think you need 2 depends in package.env 21:51 #gentoo-java: <+wltjr> OR 21:51 #gentoo-java: <+wltjr> well not sure, even if you have a RDEP and DEP in package.env, you run into the same issues with deps 21:52 #gentoo-java: <+monsieurp> time is ticking 21:52 #gentoo-java: <+wltjr> A doesnt need Z, but B does, so when you add B to the classpath of A, you get Z but you don't want Z 21:52 #gentoo-java: <+monsieurp> we should maybe hold a sort of "design" meeting and brainstorm ideas about how we could implement such system 21:52 #gentoo-java: < kiorky> how many times would we have this discussion again ? :) 21:52 #gentoo-java: <@Chewi> to wrap up, this is one of my lesser priorities, but again, making you guys aware. 21:52 #gentoo-java: <@fordfrog> ok, next topic: gcc-4.9.2 has gone stable so we need to add gcj-jdk-4.9.2 to match. sera and TomWij previously dealt with this so someone new needs to step up. Should be straightforward. (Chewi) 21:52 #gentoo-java: <+monsieurp> kiorky: meeting done in 8 minutes, you can enlighten us then 21:53 #gentoo-java: < kiorky> monsieurp: just got the hillight, coming back from a run 21:53 #gentoo-java: <+wltjr> kiorky: well this is more about creating a eclass to build maven stuff without needing maven per say, parsing the pom.xml, etc though you might have some ideas on the eclass, might join in with zxiiro after meeting on that 21:53 #gentoo-java: < kiorky> i have to read back the conversation 21:53 #gentoo-java: <+wltjr> kiorky: the final work for all the conversations :) 21:53 #gentoo-java: <@Chewi> so who's gonna volunteer? you can see how much crap I've got to do already. ;) 21:54 #gentoo-java: <+monsieurp> how hard is it? 21:54 #gentoo-java: <+wltjr> recruit more help... 21:54 #gentoo-java: <@fordfrog> Chewi, well, i am not new, but you are :-P 21:54 #gentoo-java: <+monsieurp> I can't do it alone. 21:54 #gentoo-java: <@fordfrog> as you wrote "...someone new..." :-P 21:54 #gentoo-java: <+wltjr> for real you all will not be able to do all this, you will get burned out and stuck in one area and it will tank the rest 21:54 #gentoo-java: <@Chewi> not hard, looks like gcj-jdk hardly changes between versions 21:54 #gentoo-java: <+monsieurp> for once, wltjr is right 21:54 #gentoo-java: <@fordfrog> i can do only java so i could do only blind bumps... 21:54 #gentoo-java: <@Chewi> fordfrog: :P 21:54 #gentoo-java: <+monsieurp> it's too much for the 5 of us 21:54 #gentoo-java: <+wltjr> its just time, everyone has limited time, and there are numerous tasks 21:54 #gentoo-java: <+wltjr> this is why I get upset at recruiting 21:55 #gentoo-java: < kiorky> i still think that maven in tree, from sources is too perpendicular 21:55 #gentoo-java: <+wltjr> I have watched this problem grow and grow and the numbers are never there to address the issue 21:55 #gentoo-java: < kiorky> and that any hacky pom to raw javac way will fail 21:55 #gentoo-java: < kiorky> either we maven, either we do without 21:55 #gentoo-java: <@fordfrog> guys, this is about resources so we can't solve it now, lets move on 21:55 #gentoo-java: <@fordfrog> next topic: apicheck has never been packaged and it also seems to struggle with modern Java. It depends on japitools, which hasn't been updated since 2006. Maybe this could be replaced with japi-checker. (Chewi) 21:55 #gentoo-java: <@Chewi> bleh, I'll do it if I have to 21:55 #gentoo-java: <+wltjr> kiorky: more than likely so not sure we can go with zxiiro suggestion of bootstrap maven itself and then use the tool 21:56 #gentoo-java: < kiorky> wltjr: the work i did was _only_ to bootstrap maven 21:56 #gentoo-java: < kiorky> i hope maven dependencies sanitized with time 21:56 #gentoo-java: <+wltjr> might need to talk to Betelgeuse about that one if he will comment, I think that is something he implemented 21:56 #gentoo-java: < kiorky> as it's 7 years old 21:56 #gentoo-java: <@Chewi> I'm happy to look into fixing apicheck but I raised the point to make you all aware that it's currently broken 21:56 #gentoo-java: < kiorky> sincerly i doubt 21:56 #gentoo-java: < kiorky> ^^ 21:56 #gentoo-java: <+wltjr> kiorky: oh wow.... so we should not even attempt that then... 21:56 #gentoo-java: <@fordfrog> guys, just last 5 minutes on topic, then talk about anything you want to 21:57 #gentoo-java: < kiorky> wltjr: if someone can afford the charge, it is still doable 21:57 #gentoo-java: <@Chewi> so if you're using apicheck, check the output carefully 21:57 #gentoo-java: < kiorky> not difficult 21:57 #gentoo-java: < kiorky> just a huge of initial work 21:57 #gentoo-java: <+wltjr> getting recruiters on board to get the java team some help... but its not really a problem specific to just the java team :) 21:57 #gentoo-java: < kiorky> and a medium to maintain 21:57 #gentoo-java: <@fordfrog> ok, so i guess we're done! 21:57 #gentoo-java: <@Chewi> ASM 4 and 5 are 100% compatible even though apicheck claimed otherwise 21:57 #gentoo-java: <+monsieurp> I'm not familiar with apicheck 21:57 #gentoo-java: <+monsieurp> what is it? 21:57 #gentoo-java: <+wltjr> kiorky: given the state of general ebuilds and the amount that are EAPI < 4 or 5, its a massive task I doubt will ever be done 21:57 #gentoo-java: <@Chewi> monsieurp: it's very important to determine how new versions should be slotted 21:58 #gentoo-java: < kiorky> (and sorry to break your meeting :() 21:58 #gentoo-java: <@Chewi> but for some crazy reason, it's not packaged 21:58 #gentoo-java: <@Chewi> I will add it to javatoolkit 21:58 #gentoo-java: <+monsieurp> ?? 21:58 #gentoo-java: <+wltjr> who wrote it? 21:58 #gentoo-java: <+monsieurp> yeah who wrote it? 21:58 #gentoo-java: <+wltjr> they should have packaged it, and I think I have an idea :) 21:58 #gentoo-java: <@Chewi> I don't know, maybe Betelgeuse 21:58 #gentoo-java: <+monsieurp> I've never heard of this tool before 21:58 #gentoo-java: < kiorky> wltjr: you mean various ebuilds in tree, or just the ebuilds i wrote ? 21:59 #gentoo-java: <+wltjr> I have seen it, I am familiar I think it runs on all, its hooked into eclass 21:59 #gentoo-java: <+monsieurp> kiorky: ebuilds in tree 21:59 #gentoo-java: <+wltjr> kiorky: general ones in tree, java is hurting bad, but so are aspects of gentoo in general 21:59 #gentoo-java: <@Chewi> I think it used to live in some old svn repo that was killed off < GRUMBLE, MAVEN, GRUMBLE... >
