13:03:00 <sochotnicky> #startmeeting Java SIG -- https://fedoraproject.org/wiki/SIGs/Java
13:03:00 <zodbot> Meeting started Wed May 18 13:03:00 2011 UTC.  The chair is sochotnicky. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:03:04 <sochotnicky> #meetingname java-sig
13:03:04 <zodbot> The meeting name has been set to 'java-sig'
13:03:14 <sochotnicky> akurtakov: I just use previous logs: http://meetbot.fedoraproject.org/fedora-meeting/2010-11-16/java-sig.2010-11-16-17.02.log.html
13:03:30 <sochotnicky> #chair akurtakov
13:03:31 <zodbot> Current chairs: akurtakov sochotnicky
13:03:32 <akurtakov> ok
13:03:59 <akurtakov> #topic roll-call
13:04:04 <akurtakov> so let's count
13:04:07 <akurtakov> .fas akurtakov
13:04:08 <zodbot> akurtakov: akurtakov 'Alexander Kurtakov' <akurtako@redhat.com>
13:04:13 <sochotnicky> .fas sochotni
13:04:13 <zodbot> sochotnicky: sochotni 'Stanislav Ochotnicky' <sochotni@redhat.com>
13:04:30 <cspike> .fas spike
13:04:31 <zodbot> cspike: spike143 'Dhiraj Jhangiani' <dhiraj_jhangiani@tiscali.co.uk> - spike '' <SpikeFedora@gmail.com> - manishsethi 'Manish Sethi' <manishsethi2009@gmail.com> - spikeu22 'Kyle Wallace' <spikeu_22@yahoo.com> - spiegel 'spike spiegel' <sspiegelbr@gmail.com> - spike910 'Daniel Elphinstone' <spike910@gmail.com>
13:04:38 <sochotnicky> :-)
13:04:39 <cspike> wft?
13:04:45 <sochotnicky> multiple personality disorder...
13:04:56 <cspike> just wanted to be cool :(
13:05:12 <akurtakov> ok, so cspike is actually 5-6 people :)
13:05:23 <sochotnicky> quite an attendance then
13:05:33 <cspike> that'd explain all the voices :)
13:05:39 <mbooth> Hey all
13:05:44 <sochotnicky> mbooth: heya
13:05:54 <akurtakov> #info cspike sochotni mbooth akurtakov present
13:06:01 <sochotnicky> jcapik: ?
13:06:50 <akurtakov> lets move to the first topic
13:07:00 <akurtakov> #topic guildelines changes
13:07:25 <akurtakov> sochotnicky: I guess this is smth you wan to talk about
13:07:33 <sochotnicky> yes
13:07:36 <sochotnicky> so..in short
13:07:43 <jcapik> .fas jcapik
13:07:44 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
13:07:52 <sochotnicky> there is a problem with java packages that are not only to be used in maven
13:08:26 <sochotnicky> currently we don't state Requires that are needed when used from within maven
13:08:44 <sochotnicky> i.e. package can be used succesfully with ant with fewer Requires than from maven
13:09:25 <sochotnicky> I'd like your feedback on the idea of "%{name}-maven-support" packages that would pull in those requires
13:09:34 <sochotnicky> or something similar named
13:09:35 <akurtakov> it's because the pom can contain some pluginManagement or other maven sections that require the artifact to be resolved
13:09:45 <akurtakov> just to clarify a bit
13:09:48 <sochotnicky> yes
13:10:26 <sochotnicky> not sure about the name, it's a bit long but IMO descriptive enough
13:11:03 <cspike> sochotnicky: ok, and what would the *support package contain. just the Rs and poms etc.?
13:11:15 <akurtakov> I would say just the Rs
13:11:28 <sochotnicky> cspike: ^^ yeah, I'd say only Rs
13:12:00 <sochotnicky> moving poms to -maven-support would be much more disruptive
13:12:12 <cspike> so the main package still add the group and artifact id and contains the pom file... hmm...
13:12:23 <akurtakov> it's not going to help that much
13:12:34 <sochotnicky> cspike: yes, otherwise we'd have to move things around in spec a lot more
13:12:43 <sochotnicky> akurtakov: ?
13:13:12 <akurtakov> I mean that most dependencies will be required by parent packages
13:13:32 <sochotnicky> ah, yes...but where do you put Requires on -parent package?
13:13:34 <akurtakov> and you would need to require the parent package plus a few others in rare cases
13:13:52 <sochotnicky> currently we often don't state them because that would pull in a bunch of dependencies even when using ant
13:14:16 <mbooth> So was there a BZ ticket raised for this? Seems like a lot of work for marginal gain.
13:14:20 <akurtakov> sochotnicky: yup, but people will have to learn to either add a BR on the parent or on the maven-support package
13:14:30 <cspike> sorry, but this sound like a dirty hack to me. there might be just a very few cases where the requires actually differ
13:14:42 <cspike> just look at it from the package developer point of view
13:14:44 <akurtakov> that's why I'm saying it's not help that much
13:15:03 <cspike> he still has to be aware, that his package can be used (or will be used) with maven
13:15:09 <cspike> and add all the pom stuff
13:15:18 <cspike> so he might just as well add the requires
13:15:26 <sochotnicky> cspike: true, would need even more skills from ant packages
13:15:45 <cspike> if you moven all maven stuff into a seperate package, that's a whole different story
13:15:55 <sochotnicky> gain here would be only smaller footprint when installing java things
13:16:28 <akurtakov> I would strongly oppose moving all maven to subpackage
13:16:37 <cspike> that's certainly true, but you make developing a sound java spec file a lot harder for someone who's not into it
13:16:42 <akurtakov> what would you do with e.g. plexus
13:17:05 <akurtakov> it is perfectly usable outside of maven
13:17:09 <akurtakov> but noone is doing so
13:17:11 <sochotnicky> OK, you're right and I don't feel THAT strongly about it so...
13:17:37 <sochotnicky> #agreed -maven-support subpackages declined, not gonna happen
13:17:39 <akurtakov> and having subpackage for maven stuff in them is crazy
13:18:18 <sochotnicky> so next change was that currently we don't always state all BR/R of a package because they are pulled in through other deps sometimes
13:18:23 <cspike> nah, you can still do it. i just wanted to point out that it might make the already not so trivial packaging guidelines a little more complicated
13:18:31 <cspike> how many use-cases do you have?
13:18:53 <sochotnicky> cspike: mostly packages that need R on -parent package
13:19:05 <akurtakov> sochotnicky: once we have enough rebuilds people will be able to just say BR/R: mvn(..:.)
13:19:26 <sochotnicky> akurtakov: it wouldn't solve what I wanted to solve..
13:19:28 <akurtakov> and if people got used to that having supports will be harder for people
13:19:47 <sochotnicky> ok, moving on...
13:20:07 <sochotnicky> stating all Requires/BR in spec file even if they are pulled in through deps
13:20:10 <akurtakov> I understand you what you want it's just a BR requires
13:20:25 <sochotnicky> akurtakov: no
13:20:42 <sochotnicky> hmm, perhaps you misunderstood the whole thing?
13:20:45 <akurtakov> I mean requires that are active when rpmbuild
13:21:12 <akurtakov> so we get all the maven things in
13:21:29 <akurtakov> smth like Requires(rpmbuild):
13:21:36 <sochotnicky> what if dev1 wants to use package X with maven, so he installs X
13:22:04 <sochotnicky> does mvn-rpmbuild or mvn-local and it will fail because we didn't fulfill R on X-parent package
13:22:31 <akurtakov> ah, I've been thinking only from the packager POV
13:22:49 <akurtakov> we need a packagekit plugin for that :)
13:23:08 <sochotnicky> probably...
13:23:14 <sochotnicky> ok done with this topic
13:23:57 <sochotnicky> I want the guidelines to state that all R/BR should be stated in the spec
13:24:07 <sochotnicky> even if they are pulled in from other package
13:24:13 <akurtakov> #topic list all dependencies even when pulled in by other packages
13:24:28 <sochotnicky> akurtakov: that was still in guidelines tweaks :-)
13:24:44 <sochotnicky> unfortunately you can't nest topics... :-)
13:24:46 * akurtakov is learning with the bot :)
13:25:23 <sochotnicky> now that I think about this..
13:25:46 <akurtakov> I would love to hear mbooth and cspike before saying what I think
13:26:07 <sochotnicky> it might again cause more work...
13:26:23 <mbooth> What's the rationale?
13:26:27 <sochotnicky> but packages break because dependent package no longer pulls in BR/R
13:27:28 <sochotnicky> this is usually easyfix though...
13:28:04 <cspike> sochotnicky: why would dependent packages do that? that should only happen if smth is broken...
13:28:13 <akurtakov> if we have to do that manually I don't like it :)
13:28:29 <sochotnicky> cspike: no, sometimes a new version doesn't need some BR/R
13:28:39 <sochotnicky> but thinking about it again...
13:28:44 <sochotnicky> it doesn't happen that often
13:28:45 <cspike> bottom line, you want to list all BR/Rs transparently so if a package doesn't list it's runtime requirements correctly, the dev is still able to pull all deps because they are listed in the spec file
13:28:56 <akurtakov> but I don't mind someone making a requires generator based on the pom file listing everything in dependencies section
13:28:56 <cspike> *its
13:28:57 <mbooth> akurtakov: I agree, laziness is a virtue in engineering ;-)
13:29:15 <mbooth> If it can be automated, it should be
13:29:17 <akurtakov> not marked as test, optional or provided to the packages
13:29:44 <sochotnicky> it can be done easily but this would have to be turned off for ant packages or they will start pulling in maven stuff
13:30:01 <akurtakov> sochotnicky: why?
13:30:02 <cspike> it can be automated, but be aware that dep-tree can get HUGE -> http://spike.fedorapeople.org/maven2-depmap-rawhide.png
13:30:25 <sochotnicky> akurtakov: because your ant library would suddenly have 10 more Requires
13:30:43 <akurtakov> sochotnicky: if you limit yourself to dependency section
13:30:54 <akurtakov> ignoring all the plugin and etc. we should be fine
13:31:22 <akurtakov> let's look at e.g. commons compress
13:31:24 <akurtakov> http://svn.apache.org/repos/asf/commons/proper/compress/tags/commons-compress-1.1/pom.xml
13:31:55 <akurtakov> there is a lot of crap but there is only junit in dependencies
13:32:00 <akurtakov> and it's mark as test
13:32:04 <akurtakov> so no requires generated
13:32:32 <sochotnicky> hmm, ok...it's probably worth a try
13:32:52 <sochotnicky> shouldn't be more than few python lines :-)
13:32:54 <akurtakov> or at commons configuration
13:32:56 <akurtakov> http://svn.apache.org/repos/asf/commons/proper/configuration/trunk/pom.xml
13:33:44 <akurtakov> but we skip optional test provided and etc and we are back to 3-4 deps which are manually added to the build
13:33:47 <akurtakov> err spec
13:33:56 <cspike> sorry, i don't get it. could someone describe the problem you are trying to solve here?
13:33:59 <sochotnicky> fyi this needs all packages to be rebuilt with your mvn(X) provides
13:34:31 <sochotnicky> akurtakov: because I won't be able to map mvn dep into our package name otherwise
13:34:47 <sochotnicky> cspike: making sure that package has all Requires stated
13:34:48 <akurtakov> sochotnicky: yup
13:35:19 <sochotnicky> cspike: because now we don't write them as BR/R often because we don't notice they are pulled in through some other dependency
13:35:30 <akurtakov> cspike: we(at least me) are often forgetting to add requires for new deps
13:35:43 <akurtakov> if we have them pulled in the BRs which causes runtime problems :)
13:36:34 <sochotnicky> ok, this is a good idea but needs all packages rebuilt ...
13:36:51 <akurtakov> whatever we decide it won't happen magically
13:37:10 <akurtakov> this would need rebuilds the other will need rebuilds plus spec changes
13:37:25 <sochotnicky> any volunteers for implementation? :-)
13:37:43 <akurtakov> pingou because he is not here :)
13:37:50 <sochotnicky> good idea
13:38:07 <sochotnicky> he might actually like it since he likes scripting and python too
13:38:37 <sochotnicky> #action ask pingou if he'd implement the Requires generator for packages with pom.xml
13:38:58 <akurtakov> whatever we decide implement will need to be activated afte distro rebuild
13:39:14 <akurtakov> probably at the end of F-16 if mass build happens
13:39:21 <sochotnicky> which might not happen for F-16
13:39:56 <akurtakov> we can ask releng to do one for us
13:40:06 <cspike> +1
13:40:07 <jcapik> sochotnicky: I also like scripting and python :D
13:40:08 <akurtakov> everything that depends on java :)
13:40:32 <sochotnicky> jcapik: was that a volunteer speaking? :-)
13:40:37 <akurtakov> so we have a volunteer :)
13:41:01 <jcapik> sochotnicky: If You believe I'm good enough to help here
13:41:03 <sochotnicky> #action jcapik will do the implementation for Requires generator
13:41:11 <sochotnicky> it's not that complicated...
13:41:23 <sochotnicky> you'll just have to parse an xml file
13:41:33 <sochotnicky> ok...let's move on shall we?
13:41:40 <jcapik> sochotnicky: ok ....
13:41:49 <akurtakov> I'll guide him if needed, I tested a bit with the provides geenrator
13:41:49 <sochotnicky> #topic F-16 plans
13:42:07 * mgoldmann says hi
13:42:16 <akurtakov> die maven2 die
13:42:41 <sochotnicky> mgoldmann: hi back
13:42:49 <akurtakov> everyone please remove maven2 references wherever you see them
13:43:01 <akurtakov> use mvn-rpmbuild and not mvn-jpp in your builds
13:43:36 <sochotnicky> then I'll work on moving things from /usr/share/maven2/ into ../maven
13:44:08 <akurtakov> I somehow though of this topic as an action plan how to kill it faster not whether to kill it
13:44:12 <sochotnicky> currently maven (3) requires maven2 because my resolver is looking at the pom directory within maven2 tree
13:44:51 <akurtakov> repoquery was giving me 70-80 packages that Requires maven2
13:45:03 <sochotnicky> I guess I'll take care of maven itself, and I noticed quite a few people replacing mvn-jpp with mvn-rpmbuild already for past few months
13:45:20 <akurtakov> we should aim at nothing in the repository requiring maven2
13:45:26 <akurtakov> BRs should be still ok
13:45:50 <akurtakov> i.e. maven2 not getting onto users systems
13:46:06 <akurtakov> but still used(rarely) in our build system
13:46:08 <sochotnicky> I'll do a "Provides: maven2" in maven package at some point
13:46:09 <akurtakov> anyone against?
13:46:34 <sochotnicky> I'd like a tracking bug for this...
13:46:56 <sochotnicky> with all packages with R on maven2 blocking it
13:47:26 <akurtakov> who is going to do it? volunteer?
13:47:52 <cspike> sounds like a python script to me :)
13:48:10 <sochotnicky> I'd again suggest jcapik, let him get acqainted with repoquery and bugzilla command line interface
13:48:14 <sochotnicky> cspike: won't be needed
13:48:24 <sochotnicky> it should be a few line shell script
13:48:43 <jcapik> I'll do that :]
13:49:10 <sochotnicky> jcapik: I assume you haven't used repoquery before and it's an important tool for us so...
13:49:25 <sochotnicky> I'll explain details in the office
13:49:29 <jcapik> sochotnicky: you're right ... i haven't
13:49:30 <akurtakov> repoquery --disablerepo=* --enablerepo=rawhide --whatrequires maven2
13:49:47 <sochotnicky> cheaters :-)
13:49:59 <akurtakov> 67
13:50:01 <akurtakov> not that much
13:50:29 <akurtakov> and maven-shared rebuild will reduce the number with about 10
13:51:24 <sochotnicky> #agreed jcapik will create tracking bug for removing maven2 R and bug for every package that has it
13:51:27 <akurtakov> ok so we agreed to kill it ASAP
13:51:50 <akurtakov> tomcat is smth I would have to talk about
13:52:17 <sochotnicky> right, tracking bug lists only 2 more packages
13:52:33 <sochotnicky> #link https://bugzilla.redhat.com/show_bug.cgi?id=640397 tomcat5 removal tracking bug
13:52:40 <akurtakov> yup with probably few we haven't catched
13:53:25 <akurtakov> jakarta-taglibs-standard has moved to tomcat package and we need a new package for it
13:53:58 <sochotnicky> akurtakov: ? as in: it's part of tomcat?
13:54:06 <akurtakov> sochotnicky: nope
13:54:08 <akurtakov> http://tomcat.apache.org/taglibs/
13:54:15 <akurtakov> it is under the tomcat umbrella
13:54:33 <sochotnicky> ah, right
13:55:15 <akurtakov> it would be best if this is done once they have a proper release
13:55:33 <akurtakov> the other dependant bug is struts which is orphaned
13:56:08 <sochotnicky> fyi taglibs changed quite a few things so it's not gonna be that easy...How many packages depend on it?
13:56:57 <akurtakov> just tomcat AFAIK
13:57:01 <sochotnicky> "many of the original taglibs were retired. See the Jakarta Taglibs retirement page for more on these taglib"
13:57:15 <sochotnicky> ok, if that's the case then no problem
13:57:38 <akurtakov> about tomcat 7
13:58:03 <akurtakov> there is a new contributor Ivan Afonichev that packaged it and put it for review
13:58:18 <akurtakov> I'm reviewing it but I haven't found enough time to finish it
13:58:45 <akurtakov> once we have tomcat7 I would love to see us starting to move to it's servlet and jsp apis from the tomcat6
13:59:17 <akurtakov> this is not going to be straight forward because of servlet 2 to servlet 3 change
13:59:26 <sochotnicky> so we don't repeat the history?
13:59:52 <akurtakov> it's gonna be slow
14:00:02 <sochotnicky> ....and painful I guess?
14:00:09 <akurtakov> yup
14:00:24 <akurtakov> move on?
14:00:28 <sochotnicky> yeah
14:00:36 <akurtakov> #topic Eclipse 3.7
14:01:01 <akurtakov> since yesterday we have 3.7 rc1 in rawhide thanks to zx
14:01:08 <sochotnicky> ah, cool
14:01:18 <akurtakov> we would be really thankful to anyone testing it and reporting problems
14:02:03 <akurtakov> and I would request all the plugins maintainers to start updating their plugins to the Indigo train once there are rcs available
14:02:12 <akurtakov> mbooth: this was mostly for you
14:02:13 <akurtakov> :)
14:02:28 <mbooth> Sorry, got distracted
14:03:44 <akurtakov> mbooth: testing 3.7 :)
14:03:49 <mbooth> Ok cool. I did have a problem updating EMF, but didn't have time to dig too deeply yet. I will try to do so in the coming weeks
14:04:20 <akurtakov> mbooth: btw, what about shelled release ?
14:05:17 <mbooth> Yes, I will get on it. Sorry for the delay on that.
14:05:26 <akurtakov> np:) I'm just asking
14:05:37 <akurtakov> next the sig tracker
14:05:48 <akurtakov> #topic Java SIG tracker bug
14:06:14 <sochotnicky> #link https://bugzilla.redhat.com/show_bug.cgi?id=652183 tracker bug
14:06:15 <akurtakov> mostly old bugs
14:06:25 <sochotnicky> few reviews...
14:06:34 <akurtakov> looks like newer bugs are handled faster
14:07:41 <akurtakov> nothing special and noone is working to clean them
14:07:52 <sochotnicky> akurtakov: what about your jogl?
14:08:08 <akurtakov> we have done few iterations while I had time
14:08:36 <akurtakov> and I can't find time for reviews lately
14:09:07 <sochotnicky> OK
14:09:11 <akurtakov> I hope to finish the few reviews I have assigned really soon
14:09:55 <sochotnicky> ok, so I guess there's nothing too much interesting there.
14:10:01 <akurtakov> yup
14:10:07 <akurtakov> #topic Open floor
14:10:12 <sochotnicky> except it seems build-classpath on 64bit discussion stalled a bit
14:10:55 <akurtakov> noone is interested enoug
14:11:16 <akurtakov> mgoldmann: cspike: mbooth: jcapik: do you have smth you want to discuss?
14:11:34 <mgoldmann> uhm, I think I should start talking loudly :)
14:11:35 <jcapik> akurtakov: nope
14:11:39 <mgoldmann> so, yes
14:11:43 <mbooth> Nothing immediately springs to mind :-)
14:11:57 <mgoldmann> we, from JBoss side, want to finally include JBoss AS in Fedora
14:12:06 <mbooth> Nice
14:12:13 <mgoldmann> a help with this will be greatly appreciated :)
14:12:18 * sochotnicky hears applause all around
14:12:42 <mgoldmann> for now I'm building a script that shows us what we need to do to achieve this
14:12:58 * cspike is still working on quartz
14:13:03 <mgoldmann> ie. what packages are in, what not
14:13:16 <sochotnicky> mgoldmann: would be nice to have a wiki with tasks that need to be done, similar to https://fedoraproject.org/wiki/MavenUpdate
14:13:19 <mgoldmann> the idea is to push JBoss AS 5.1 from jpackage, and later AS7
14:13:40 <sochotnicky> mgoldmann: I was actually slowly working on adding jboss-parent into fedora with all its deps
14:13:47 <akurtakov> updating jboss as 5.1 to use newer libraries might be an issue
14:14:22 * rbergeron cheers at mgoldmann
14:14:35 <mgoldmann> :)
14:14:57 <akurtakov> there is a page generated by mgoldmann's script
14:15:03 <mgoldmann> so, expect soon a link to a wiki page
14:15:09 <akurtakov> for the deps
14:15:11 <sochotnicky> mgoldmann: what TZ are you in? We might schedule our meeting a bit later next time if it would be better for you
14:15:23 <sochotnicky> good
14:15:24 <mgoldmann> https://github.com/goldmann/jboss_as_rpm/wiki/DependenciesToDo
14:15:36 <mgoldmann> but this one is not finished as akurtakov pointed out
14:15:42 <mgoldmann> some of these packages are already in Fedora
14:15:49 <mgoldmann> I'll move it to Fedora wiki
14:15:51 <sochotnicky> #link https://github.com/goldmann/jboss_as_rpm/wiki/DependenciesToDo missing JBoss deps
14:15:55 <mgoldmann> sochotnicky: I'm UTC+2
14:16:03 <sochotnicky> mgoldmann: ah, ok then...
14:16:03 <mgoldmann> ie: poland :)
14:16:18 <akurtakov> mgoldmann: cspike is still working on quartz which you need :)
14:16:40 <mgoldmann> once I have the wiki page - we can add some notes
14:17:24 <sochotnicky> mgoldmann: great
14:18:04 <mgoldmann> and yes - packaging Java is new for me, so I would need your help...
14:18:34 <mgoldmann> I think I'll have also support from JBoss side
14:18:47 <mgoldmann> we'll see, let's kick the process!
14:19:06 <sochotnicky> yup, definitely...I'll do my best to help out
14:19:53 <sochotnicky> mgoldmann: once you have a wiki page it might be nice idea to post link to fedora-java (or even fedora-devel I'd say)
14:20:15 <mgoldmann> yes, I'll have it today, and expect today a post
14:20:17 <sochotnicky> with some luck more people might chime in (no promisses though...)
14:20:56 <sochotnicky> ok, I gotta go and sleep some more because my head is hurting again..
14:21:11 * jsmith promises to help rally support
14:21:12 <sochotnicky> akurtakov: can you post minutes to java-devel?
14:21:24 <akurtakov> sure
14:21:27 <sochotnicky> #endmeeting