17:02:30 <akurtakov_> #startmeeting Java SIG -- https://fedoraproject.org/wiki/SIGs/Java
17:02:30 <zodbot> Meeting started Tue Oct 19 17:02:30 2010 UTC.  The chair is akurtakov_. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:50 <akurtakov_> so who is here ?
17:02:51 <sochotni> ggraz: came to join us for Java SIG meeting?
17:03:00 <sochotni> #topic roll-call
17:03:01 <ggraz> yup
17:03:03 <cspike> heyho, I'm here
17:03:14 <mbooth> Evenin'
17:03:17 <sochotni> akurtakov_: that is command for you only btw :-)
17:03:32 <sochotni> ggraz: great, welcome
17:03:38 * sochotni too
17:03:38 <akurtakov_> #topic roll-call
17:04:00 <sochotni> #info akurtakov_ cspike ggraz mbooth sochotni present
17:04:25 <akurtakov_> #info akurtakov_ cspike ggraz mbooth sochotni present
17:04:40 <sochotni> info is for non-admins too so mine was recorded...
17:04:43 <sochotni> #undo
17:04:53 <akurtakov_> sochotni: can I make you an admin
17:04:58 <sochotni> akurtakov_: yup :-)
17:05:06 <sochotni> but you can learn :-)
17:05:11 <akurtakov_> #chair sochotni
17:05:11 <zodbot> Current chairs: akurtakov_ sochotni
17:05:16 <sochotni> ok, then
17:05:24 <akurtakov_> ok, so let's start
17:05:33 <akurtakov_> #topic maven 3 status
17:05:51 <sochotni> As you probably noticed we already have dependencies in Fedora
17:06:04 <cspike> congrats on this, sochotni, great work!
17:06:07 <sochotni> there are also srpms/rpms
17:06:26 <akurtakov_> sochotni: are they public?
17:06:37 <sochotni> http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm
17:06:45 <sochotni> #link http://sochotni.fedorapeople.org/maven-3.0-1.fc13.src.rpm maven 3 source rpm
17:06:58 <cspike> https://fedoraproject.org/wiki/MavenUpdate#Maven_3 may be helpful, too
17:07:01 <sochotni> #link http://sochotni.fedorapeople.org/maven-3.0-1.fc15.noarch.rpm maven 3 binary rpm
17:07:13 <sochotni> cspike: right, that actually contains both links
17:07:32 <sochotni> I am currently working out how to make our /usr/share/java work with new Maven
17:07:37 <sochotni> the architecture changed a bit
17:08:02 <sochotni> but just few minutes ago I finally managed to be enlightened (I think so at least)
17:08:32 <akurtakov_> so the question should we wait for the system repo work to arrive or we should import vanilla maven?
17:08:39 <sochotni> I'll create a git repo with our custom maven resolver and push it somewhere so you can see when I start working on it
17:09:03 <sochotni> akurtakov_: depends I guess...maven-3 rpm can be installed in parallel with maven2
17:09:36 <sochotni> so noone would get hurt if we got it in...but it might be good idea to re-review it once new repository layout arrives
17:09:58 <akurtakov_> at least for me it will be quite usefull to use maven-3 for tycho
17:10:05 <akurtakov_> even if it's not working system repo
17:10:22 <sochotni> ok, at least we get a bit of testing...
17:10:25 <akurtakov_> but I agree totally that we need to review the repo work
17:10:33 <akurtakov_> what do others think?
17:11:16 <sochotni> cspike, mbooth: any thoughts on putting up maven-3 spec for review now?
17:11:30 <akurtakov_> ggraz: you too :)
17:11:30 <mbooth> I am not offended by this :-)
17:11:53 <cspike> i don't see strong reasons to wait
17:12:15 <sochotni> ok
17:12:25 <sochotni> #action sochotni will put maven 3 spec for review
17:12:56 <sochotni> #action sochotni will create public git repo with custom resolver so others can see/review
17:13:25 <akurtakov_> sochotni: so you're going to create a new aether provider, right?
17:13:30 <sochotni> akurtakov_: yes
17:14:10 <sochotni> as small part of it as necessary...hopefully standard classes will do the work for the most part
17:14:45 <sochotni> #info new resolver should be basically re-implemented maven-aether-provider
17:14:51 <sochotni> ok, next topic?
17:15:04 <sochotni> #topic Java packages monitoring
17:15:27 <sochotni> #link https://fedoraproject.org/wiki/SIGs/Java/Monitored_packages Wiki to collect Java packages for monitoring
17:15:29 <akurtakov_> we are missing apache-commons
17:15:44 <cspike> i'll add them asap
17:15:54 <akurtakov_> and all ant deps
17:16:41 <sochotni> there are a lot of packages missing, I just added all maven packages and plexus...plus few others I am maintaining
17:17:08 <sochotni> I'd like you all to go through your packages and see if you want it added
17:17:24 <sochotni> shouldn't take too long
17:17:25 <ggraz> should we edit this page: http://fedoraproject.org/wiki/Package_SCM_admin_requests ; adding a Java SIG pseudo user for InitialCC ?
17:17:44 <cspike> that's probably a good idea
17:17:55 <akurtakov_> do we have a pseudo user now ?
17:18:03 <sochotni> akurtakov_: not yet
17:18:23 <akurtakov_> so we should edit it once we have the pseudo user
17:18:48 <akurtakov_> does anyone have an idea what is the procedure?
17:18:50 <ggraz> is that a real FAS account or just a forward email address
17:18:59 <sochotni> ok, any volunteers for creating infra ticket?
17:19:20 <akurtakov_> I'll do it
17:19:26 <sochotni> #link https://fedorahosted.org/fedora-infrastructure/ infra ticketing system
17:19:44 <sochotni> #action akurtakov_ will file infra ticket asking for java pseudo user
17:19:53 <sochotni> well...java-sig I guess
17:20:11 <sochotni> ggraz: it's a special user
17:20:25 <sochotni> kind of weird
17:21:04 <akurtakov_> and it will forward to java-devel ?
17:22:08 <ggraz> mmh that would generate a lot of traffic on the ml
17:22:09 <sochotni> akurtakov_: we can ask where we want it...
17:22:22 <sochotni> ggraz: but that traffic is easily filtered IMO
17:22:46 <sochotni> otherwise we have to create another mailing list I guess
17:22:46 <mbooth> How do other sigs deal with the mail?
17:23:09 <sochotni> I know perl has one ml for all development (including commits from 1000+ packages)
17:23:16 <akurtakov_> i18n have a bugs mailing list and they forward to it
17:23:19 <sochotni> but no idea about others
17:23:54 <sochotni> I personally don't care much either way...
17:24:08 <sochotni> it's just gonna be more work initially
17:24:12 <akurtakov_> well we have 5-6 mails a week on java-devel
17:24:25 <akurtakov_> I don't think we need a new mailing list
17:24:51 <akurtakov_> not to mention that this way we can keep people more informed about what happens
17:25:18 <ggraz> agreed, -java-devel is fine
17:25:20 <sochotni> it will be easy for us to filter the noise so...I also think java-devel is the right answer
17:25:25 <mbooth> Sounds fine to me
17:25:47 <sochotni> if it gets unbearable for some reason...we can always change it later
17:26:08 <sochotni> #info java-sig user will forward to java-devel mailing list
17:26:45 <sochotni> ok, so next?
17:26:54 <akurtakov_> #topic New packaging guidelines
17:27:06 <akurtakov_> I've done basic editing
17:27:15 <sochotni> #link https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate Draft
17:27:22 <akurtakov_> changing the most obvious/wrong parts
17:27:39 <sochotni> I have added a bit of explaining for %add_to_maven_depmap quirks
17:27:51 <akurtakov_> I still don't feel like it's ready yet but now is the time for others to review and raise their concerns
17:28:24 <sochotni> I have an issue with linking to https://fedoraproject.org/wiki/Packaging/GCJGuidelines
17:28:43 <sochotni> Draft points to it from place where it says GCJ is discouraged
17:29:06 <akurtakov_> I think we will have to change first gcj paragraph
17:29:08 <sochotni> but those guidelines say you have to build it
17:29:13 <sochotni> yup
17:30:02 <cspike> btw, is 'install javadoc:javadoc' generally deprecated or just in multi-module projects?
17:30:17 <akurtakov_> and add a bit note that one have to redo the gcj aot compilation entirely so it doesn't mandate having gcj installed when someone wants to use other vm
17:30:19 <sochotni> cspike: current javadoc:aggregate is basically a workaround
17:30:38 <sochotni> but a nice one :-)
17:30:43 <akurtakov_> hmm, I've seen logs that javadoc:javadoc is deprecated in some logs
17:30:58 <akurtakov_> but I would like to see what happens in Maven 3
17:31:00 <cspike> akurtakov_: yeah, think i have notived that, too. that's why i asked
17:31:12 <sochotni> akurtakov_: really? OK, might be
17:31:31 <akurtakov_> #action akurtakov_ to add javadoc:aggregate to guidelines
17:32:11 <ggraz> is the JPP maven depmap quirk still relevant with maven3? if not, i think we should merge parts of http://fedoraproject.org/wiki/Java/JPPMavenReadme into the main guidelines
17:32:46 <sochotni> ggraz: I think we'll need it still
17:32:48 <akurtakov_> ggraz: we are still not sure, we may manage to keep the current format
17:32:51 <sochotni> in one form or the other
17:33:21 <sochotni> but I'd like some properties renamed at least
17:34:26 <akurtakov_> sochotni: sure, we may merge what's relevant when we know the maven3 format
17:34:36 <sochotni> also: how do you feel about having ant projects install pom files/depmaps?
17:34:48 <sochotni> I'd like to see it in guidelines at least as "SHOULD"
17:34:53 <sochotni> if there is a pom.xml of course
17:35:19 <ggraz> sochotni: when a pom file is available, i'm for a MUST
17:35:38 <akurtakov_> #action akurtakov_ add to guidelines that ant packages that have pom files MUST install them
17:35:52 <mbooth> Is it acceptable to use a pom from the maven central repo when one is needed but isn't supplied?
17:36:05 <sochotni> mbooth: I was about to ask that too..
17:36:13 <sochotni> I think that should be allowed
17:36:20 <mbooth> Me too
17:36:27 <akurtakov_> mbooth: it is but this puts additional burden on the packager so we may keep it as should
17:36:56 <sochotni> akurtakov_: yeah, I also think that MUST if there is pom, SHOULD otherwise
17:36:57 <akurtakov_> if there is no pom consider using the one from maven central, ok ?
17:37:15 <mbooth> Sounds fair
17:37:40 <akurtakov_> #action akurtakov_ f there is no pom consider using the one from maven central addition to guidelines
17:38:18 <sochotni> %add_to_maven_depmap package-groupId package-artifactId %{version} JPP maven-archiver
17:38:37 <sochotni> fixing maven-archiver :-)
17:38:47 <sochotni> (no need for action, doing it now)
17:39:18 <ggraz> i'd suggest to put as a MUST for maven packages, to %global define groupId and artifactId on specfile head
17:39:19 <sochotni> I'd like a section that explains difference between JPP.XXX-YY and JPP-XXX
17:40:26 <akurtakov_> sochotni: http://fedoraproject.org/wiki/Java/JPPMavenReadme#POM_file_names ?
17:40:28 <mbooth> sochotni: I always have to look that up :-)
17:40:54 <sochotni> akurtakov_: damn, never seen that...
17:41:02 <sochotni> so really...move to main guidelines?
17:41:09 <akurtakov_> JPPMavenReadme should die I agree
17:41:34 <sochotni> there is basically nothing ordinary user should know, but everything a packager should
17:42:05 <akurtakov_> yep, I'll look at it and merge relevant parts
17:42:45 <akurtakov_> also explaining when a depmap can be used and when not
17:42:54 <sochotni> akurtakov_: right!
17:43:09 <akurtakov_> sochotni: I'll add things as actions so I can do them later this week
17:43:30 <sochotni> whatever works for you
17:43:42 <sochotni> but I'd like everyone to subscribe to watch changes on that page
17:43:42 <akurtakov_> #action akurtakov_ merge parts from JPPMavenReadme and explain when usage of depmap is reasonable and when one have to patch the pom.xml file
17:44:03 <sochotni> and perhaps review it whole at least once
17:44:10 <sochotni> see if you'd like something added
17:44:29 <sochotni> akurtakov_: you might want to go through current template...maybe there might be some ideas for guidelines as well
17:44:45 <ggraz> btw, i think the pom naming convention should be fixed
17:44:55 <akurtakov_> ggraz: what do you mean?
17:45:27 <ggraz> %{_javadir}/plexus/ant-factory.jar should be JPP.plexus.ant-factory.pom not JPP.plexus-ant-factory.pom
17:45:48 <akurtakov_> ggraz: does it work in both ways ?
17:46:49 <ggraz> the pom filename is not used by resolver afaik, just the fragment depmaps in /etc/maven/fragment
17:47:25 <sochotni> ggraz: it is for parent poms...or so I think from many times I was bitten by deps in those poms
17:47:29 <akurtakov_> ggraz: hmm, I'm pretty sure that maven plugins that install their pom with dot doesn't work
17:47:48 <ggraz> how could it determine if the subdir is "plexus" or "plexus-ant" in the sample above?
17:48:22 <sochotni> ggraz: good point...I think it only uses part to nearest dash
17:48:32 <sochotni> so directories with dash in name don't work
17:48:38 <sochotni> or so I'd guess
17:49:41 <sochotni> hmm, but yet...animal-sniffer works
17:49:56 <sochotni> but that is from fragment in /etc
17:50:42 <sochotni> ggraz: I am not agains renaming...but backward compatibility will be...interesting to preserve
17:50:50 <sochotni> at least I think so
17:51:01 <akurtakov_> well, this can change with maven3
17:51:26 <akurtakov_> and we may even consider moving depmaps to /var
17:51:28 <ggraz> sochotni: true, i'll possibly report with more precision next meeting
17:51:48 <sochotni> akurtakov_: I wanted to do it...no more ugly rpmlint warnings
17:51:59 <akurtakov_> yep, it's needed
17:52:06 <ggraz> +1 move depmaps to /var/maven
17:52:08 <sochotni> and FHS correct...
17:52:29 <akurtakov_> we will have them duplicated for some time
17:52:46 <akurtakov_> or we can do this once maven 3 obsoletes maven2
17:53:22 <sochotni> we'll work out the details when the time comes..
17:53:32 <akurtakov_> yep
17:53:33 <sochotni> but yes, move to /usr/var is needed
17:54:05 <sochotni> we are nearing end of our time slot
17:54:39 <cspike> sochotni: there's no meeting starting at 1800UTC afaik
17:54:40 <sochotni> so I'd skip last point (no big work on SIG wiki due to no time)
17:54:45 <sochotni> cspike: really?
17:54:56 <cspike> http://fedoraproject.org/wiki/Fedora_meeting_channel
17:55:04 <sochotni> Development SIG?
17:55:12 <akurtakov_> dead
17:55:21 <cspike> yup, they're dead
17:55:23 <sochotni> ah, ok them...I'll delete them from channel page
17:56:27 <akurtakov_> so do we other things to discuss
17:56:40 <sochotni> there was update of Java SIG wiki
17:56:57 <sochotni> I did small cleanups, but not overhaul we need
17:57:11 <sochotni> cspike: I guess you had no time as well?
17:57:16 <cspike> that's on my agenda
17:57:20 <cspike> had the flu :(
17:57:27 <sochotni> #topic Update Java SIG wiki
17:57:35 <sochotni> cspike: hope you're better
17:57:55 <cspike> yeah, thanks :)
17:58:02 <sochotni> but yeah, if anyone has ideas how to-be-packagers can help out...come on
17:58:15 <akurtakov_> #topic open-floor
17:58:40 <akurtakov_> we have a few things to finish
17:58:48 <akurtakov_> JakartaPackageRename
17:58:51 <akurtakov_> cspike: ?
17:58:57 <cspike> yup
17:59:02 <cspike> two reviews left
17:59:12 <cspike> http://fedoraproject.org/wiki/JakartaCommonsRename
17:59:24 <cspike> i just built commons-cli, so it should hit rawhide soon. anyone know how to contact jmrodi
17:59:32 <cspike> he has to orphan jakarta-*
17:59:37 <akurtakov_> cspike: are you taking care of killing old packages and opening releng tickets?
17:59:45 <akurtakov_> to block them
17:59:55 <sochotni> jmrodri has been unresponsive to me too
18:00:02 <sochotni> I've tried emailing him several times
18:00:15 <cspike> akurtakov_: i think, i need commit access to orphan the packages correctly, right?
18:00:23 <akurtakov_> cspike: I think so
18:00:27 <sochotni> cspike: I think you actually have to own them
18:00:48 <akurtakov_> actually we have to deprecate not to orphan
18:00:53 <sochotni> I remember I couldn't retire packages even when I had ACL approval rights
18:01:11 <cspike> http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
18:01:34 <akurtakov_> yep
18:01:42 <akurtakov_> so we are quite close to finishing this
18:01:51 <cspike> i can open the releng tickets. anyone know, how to do the rest?
18:02:04 <cspike> without owning the package, of course
18:02:09 <mbooth> I think fnasser has to orphan some commons packages still also
18:02:22 <akurtakov_> mbooth: which one?
18:02:36 <akurtakov_> I'll make sure to ping him about this
18:02:43 <cspike> wasn't there a tracker bug somewhere in bz?
18:02:59 <sochotni> cspike: yes but only for open reviews
18:03:23 <sochotni> if there was no open review for apache- package then there is nothing you'll see in the tracking bug
18:03:46 <cspike> right
18:04:09 <akurtakov_> the other task in the works is moving away from tomcat5
18:04:37 <akurtakov_> I had only one of my package and it's fixed
18:04:52 <mbooth> If fnasser could orphan the packages in this list: http://lists.fedoraproject.org/pipermail/java-devel/2010-September/003923.html
18:04:57 <mbooth> I can finish them off
18:04:57 <sochotni> cspike: which was jmrodri's package?
18:05:04 <cspike> commons-cli
18:05:32 <sochotni> #action sochotni try to contact jmrodri and fnasser about orphaning their jakarta packages
18:05:39 <sochotni> fnasser won't be a problem
18:06:06 <sochotni> and I'll use magic to contact jmrodri
18:06:14 <ggraz> cspike: will you open bugs against maven2-common-poms to remove freshly packaged apache-commons poms?
18:06:39 <ggraz> or should i take care of it?
18:06:45 <cspike> actually...
18:07:08 <cspike> i think we agreed to do a new apache-commons-parent-poms (or something like that) package
18:07:34 <akurtakov_> yep, and this means one less pom/depmap in commons pom
18:08:01 <cspike> ggraz: but as soon as this is done, i can file bugs to remove the old stuff from maven2-common-poms, sure
18:08:26 <akurtakov_> ggraz: while we are on commons-poms can you review it's contents to remove maven stuff when it's properly packaged
18:08:38 <sochotni> but that's for parent poms, we still need to remove normal poms from maven2-common-poms
18:08:48 <ggraz> exactly
18:09:15 <sochotni> those tasks are separate
18:09:32 <cspike> sochotni: the 'normal' poms should be included in the new apache-commons packages anyway, right?
18:09:40 <sochotni> cspike: yup
18:09:49 <ggraz> sochotni: there should be just *one* parent pom right?
18:10:00 <akurtakov_> cspike: yes, and currently they are shipped in maven2-common-poms too
18:10:06 <sochotni> ggraz: I guess (cspike?)
18:10:08 <akurtakov_> and should be removed from there
18:10:41 <cspike> ok, they should be removed from maven2-common-poms, but there are still apache-commons* packages that don't provide a pom file upstream
18:11:10 <sochotni> on an unrelated note...could you put your agenda on the wiki meeting page next time so we know what we did/didn't manage to do?
18:11:29 <cspike> sure :)
18:12:00 <cspike> ok, so what to do with those packages? include the pom file into the new apache-common-poms (like the parent pom)
18:12:06 <cspike> or leave them in maven2-common-poms?
18:12:18 <cspike> opinions?
18:12:24 <akurtakov_> mbooth: pcheung said that she had already orphaned them?
18:12:31 <akurtakov_> so it's fnasser only?
18:12:40 <mbooth> He has, just waiting on fnasser
18:13:08 <akurtakov_> cspike: maven2-common-poms should die eventually
18:13:27 <sochotni> so...move to separate package
18:13:28 <ggraz> mmh; id prefer an apache-parent pom package, and let die maven2-common-poms
18:13:43 <sochotni> yup
18:13:45 <cspike> ok, sounds good to me
18:14:07 <akurtakov_> so one apache-parent containing both apache-parent and apache-commons-parent?
18:14:15 <ggraz> then possibly the apache-commons-parent will containt just one pom in the future
18:15:44 <cspike> we could try to get rid of all the common poms at least for apache-commons
18:15:48 <ggraz> well actually i'm changing my mind
18:16:06 <ggraz> if maven2-common-poms is a bad thing (and it definitely is) why duplicate the issue?
18:16:16 <cspike> yeah, absolutely
18:16:39 <akurtakov_> ggraz: the idea to have parent poms is to make them have proper requires
18:16:54 <sochotni> as stated in their pom.xml
18:17:00 <ggraz> sure, i'm referring to module poms not packaged upstream
18:17:10 <akurtakov_> and we can greatly reduce packages BR sections
18:17:15 <cspike> akurtakov_: no, the parent poms is a good thing, basically, but not a separate package with common-poms just for apache-commons
18:17:58 <cspike> so i guess, i'll have to make up a pom file even for those apache-commons that don't provide one upstream and are built with ant or something...
18:18:28 <akurtakov_> cspike: well, you will have to require every single java package under the sun if you have to do proper requires for maven2-common-poms
18:18:46 <akurtakov_> that's why it doesn't require anything and we have to add so many duplicate BRs
18:18:52 <sochotni> I think you all just misunderstand each other...
18:19:12 <ggraz> akurtakov_: i see no reason to make apache-parent BR its modules; the specfile BR section will be shorter but the build will pull in a lot of unneded deps
18:19:30 <akurtakov_> ggraz: not modules
18:19:41 <sochotni> like I said...misunderstanding
18:19:48 <akurtakov_> but dependenciesManagement section
18:20:10 <akurtakov_> and plugins that are configured in the parent pom
18:20:29 <akurtakov_> because they will be checked at build time
18:20:45 <sochotni> commons-parent has certain dependencies in pom that have to be duplicated in every commons package using that pom, if we have separate package that has all those deps in !Requires! those separate commons will be more simple
18:20:48 <ggraz> ...
18:20:54 <ggraz> nevermind, i'm in sync now
18:21:33 <akurtakov_> ggraz: do you think we have to make a separate package now?
18:21:56 <ggraz> yep
18:22:17 <akurtakov_> cool, looks like I'm not good in explanations :)
18:22:21 <cspike> ok, that's one problem fixed now... what about those apache-commons that don't provide a pom file? leave them in maven2-common-poms for now until upstream fixes?
18:22:52 <akurtakov_> cspike: it would be best to put the pom in the package itself
18:23:02 <akurtakov_> getting the pom from maven central
18:23:07 <akurtakov_> and using it
18:24:17 <cspike> akurtakov_: ok, doesn't look nice in the spec file, but is feasible
18:24:42 <akurtakov_> I have to run ttyl guys
18:24:50 <sochotni> guys, I'd say we all have more than enough to do for next two weeks..
18:25:29 <cspike> ok, lets end it here
18:25:51 <sochotni> #endmeeting