Java project meeting log for 20150306.

1 files changed, 371 insertions, 0 deletions

diff --git a/xml/htdocs/proj/en/java/meeting-logs/java-project-meeting-log-20150306.txt b/xml/htdocs/proj/en/java/meeting-logs/java-project-meeting-log-20150306.txt
new file mode 100644
index 0000000000..4456b1f9f1
--- /dev/null
+++ b/xml/htdocs/proj/en/java/meeting-logs/java-project-meeting-log-20150306.txt
@@ -0,0 +1,371 @@
+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... >