[gentoo-commits] gentoo commit in xml/htdocs/proj/en/java/meeting-logs: java-project-meeting-log-20150306.txt

[James Le Cuirot (chewi)]

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... >