13:05:53 <sochotni> #startmeeting Java SIG -- https://fedoraproject.org/wiki/SIGs/Java
13:05:53 <zodbot> Meeting started Wed Jun  1 13:05:53 2011 UTC.  The chair is sochotni. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:05:59 <sochotni> #meetingname java-sig
13:05:59 <zodbot> The meeting name has been set to 'java-sig'
13:06:20 <sochotni> anyone wants to try co-chairing?
13:06:32 <sochotni> it's good to practice in case I won't be around next time :-)
13:06:46 <sochotni> #topic roll-call
13:06:51 <akurtakov> not me:) I'm not in a good shape
13:06:54 <sochotni> So let's see who's around
13:06:56 * mgoldmann says hi
13:06:56 <jcapik> .fas jcapik
13:06:57 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
13:06:59 <sochotni> .fas sochotni
13:07:01 <zodbot> sochotni: sochotni 'Stanislav Ochotnicky' <sochotni@redhat.com>
13:07:12 * cspike is here
13:07:15 <akurtakov> .fas akurtakov
13:07:15 <zodbot> akurtakov: akurtakov 'Alexander Kurtakov' <akurtako@redhat.com>
13:07:32 <overholt> .fas overholt
13:07:33 <zodbot> overholt: overholt 'Andrew Overholt' <overholt@redhat.com>
13:08:30 <sochotni> #info cspike jcapik akurtakov sochotni overholt mgoldmann nthykier attending (probably more silent listeners :-) 0
13:08:50 <sochotni> #topic new add_maven_depmap macro
13:09:20 <sochotni> We've been using jpackage's add_to_maven_depmap macro for some time, but it can be a bit inflexible..
13:09:44 <sochotni> some time ago I created improved macro using python script to parse pom files to simplify things and eliminate possible errors
13:09:50 <sochotni> #link https://bugzilla.redhat.com/show_bug.cgi?id=658809
13:10:35 <sochotni> I'd like to find a way to finally start using it in Fedora
13:10:53 <sochotni> I'll finish up documentation inside python script a bit so it can be easily understood
13:11:11 <sochotni> then there are few options
13:11:32 * akurtakov really wants to see it pushed to F14, F15 and rawhide and change guidelines right after F13 ie EOLed
13:12:00 <sochotni> create a separate package (fedora-java or something) and add this macro there
13:12:13 <sochotni> together with javadoc scriptlet that alex created (presented later)
13:13:12 <sochotni> it could be added to jpackage-utils I guess...although maintainers have quite a lot of their hands and I don't want to step on anyone's toes by comitting into their packages
13:14:02 <akurtakov> I'm in favour of creating git repo for fedora scripts, macros and etc
13:14:12 <akurtakov> and ship it as additional tarball in jpackage-utils
13:14:32 <akurtakov> this will allow jpackage-utils maintainers upstream to pull what they want easily
13:14:55 <akurtakov> and we would not be forced to move things between packages if/when they merge smth
13:16:12 <akurtakov> anyone ?
13:16:35 <cspike> i like the idea of a git repo for fedora stuff
13:16:39 <sochotni> for those not 'in the know'...new macro would let us do "%add_maven_depmap JPP-xbean.pom" for parent poms (no need to state group/artifactid)
13:16:46 <cspike> and +1 for putting it into jpackage-utils
13:16:49 <overholt> dbhole is not going to care if you touch jpackage-utils in Fedora
13:16:59 <sochotni> and also "%add_maven_depmap JPP.xbean-xbean-reflect.pom xbean/xbean-reflect.jar"
13:17:31 <sochotni> overholt: OK, I'll consider it as my shooting range then :-)
13:17:41 <overholt> :)
13:17:54 <sochotni> so...I'll ask for fedorahosted project
13:18:08 <akurtakov> I know dbhole wouldn't care but we need a better way to keep development than random patches to srpm
13:18:16 <akurtakov> sochotni: +1
13:18:35 <sochotni> #action sochotni ask for java-scripts fedorahosted project
13:18:44 <sochotni> actually...anyone has good name for it?
13:19:10 <akurtakov> there is http://pkgs.fedoraproject.org/gitweb/?p=fontpackages.git;a=summary
13:19:27 <akurtakov> so if we try to be consistent it should be javapackages :)
13:19:38 <sochotni> akurtakov: OK, fine with me
13:20:09 <cspike> btw, is there a fedorahosted project for the custom maven resolver?
13:20:31 <akurtakov> cspike: you mean the provides generator?
13:20:37 <sochotni> cspike: hmm, no there isn't...I was keeping it in maven repo on fedorapeople
13:20:51 <akurtakov> ah sorry
13:20:52 <sochotni> it is not up to date...should push it there
13:21:52 <sochotni> original idea was to create separate project, but it's not possible so...
13:22:37 <sochotni> i.e. I was hoping we'd be able to extend maven without patching it...but that's a no-go so unfortunately no reason to create separate package I guess.
13:22:54 <akurtakov> yup
13:23:26 <sochotni> each change to maven patches/resolver is a new revision in git so it's relatively easy to track
13:23:36 <sochotni> "new revision in maven package git"
13:23:48 <sochotni> anyway...related topic is...
13:23:54 <sochotni> #topic javadoc scriptlet
13:24:34 <akurtakov> ok, it's me here
13:24:39 <sochotni> akurtakov: yup
13:24:58 <akurtakov> http://fpaste.org/Rd6J/
13:25:01 <akurtakov> that's in short
13:25:17 <akurtakov> I want to add this as a macro and advertise/change guidelines
13:25:34 <mgoldmann> hey, less things to type!
13:25:34 <akurtakov> so the only place we have to deal with javadoc is in install section
13:25:48 <akurtakov> everything else setup by a single macro call
13:26:01 * mgoldmann likes it
13:26:19 <akurtakov> there are even side effects of standardize summaries/descriptions and etc.
13:26:29 <sochotni> I like anything that simplifies packaging :-)
13:26:53 <cspike> akurtakov: can i alter the files in javadocdir (eg add the license)?
13:27:10 <cspike> while using the macro, of course
13:27:21 <akurtakov> cspike: nope, that's a problem
13:27:25 <sochotni> ah right...that's a problem
13:27:34 <sochotni> can't be like that...
13:28:08 <akurtakov> I have never thought about that
13:28:14 <jcapik> as I usually copy the spec file from older packages, it isn't more typing for me ....
13:28:28 <cspike> +1 on that
13:28:29 <jcapik> and sometimes I use %{short_name}
13:28:35 <sochotni> I have jnovy here with me...I'll ask him once he solves other issues :-)
13:28:42 <cspike> it's neat, but it's actually not a time saver at all
13:28:43 <sochotni> akurtakov: fyi defattr is not needed anymore
13:28:58 <akurtakov> sochotni: really? I missed that
13:29:16 <akurtakov> if people like the idea I'll try adding parameter for additional files
13:31:12 <jcapik> akurtakov: Yep .... additional parameter would be nice ....
13:32:36 <cspike> again, i hate to be the nitpicker, but try not to be over-elegant here. it's basically a solution for no problem. it shortens the spec file a bit, but you actually hide what may be important for someone who's not into java packaging like we are
13:33:22 <akurtakov> ok, if there is no 100% consensus I'll stop
13:33:40 * akurtakov just wants to read one spec without scrolling :)
13:33:44 <sochotni> akurtakov: won't be needed probably
13:33:59 <sochotni> jnovy suggested we can use file lists in %files section
13:34:05 <jcapik> akurtakov: I like the idea of macro ....
13:34:08 <sochotni> i.e. %files javadoc -l licenses
13:34:22 <jcapik> akurtakov: but it should be optional
13:34:22 <cspike> and probably notice etc.
13:34:36 <jcapik> akurtakov: not put as a MUST in the guidelines
13:34:37 <sochotni> and in licenses file we'll have all kinds of license filenames we can think of :-)
13:35:07 <sochotni> jcapik: it's worse to cause inconsistencies
13:35:14 <cspike> and there are some projects where upstream doesn't provide a license file...
13:35:20 <sochotni> packaging overhead just gets bigger not lower
13:35:36 <jcapik> sochotni: there are still some inconsistencies between older and newer packages
13:35:41 <sochotni> cspike: that won't hurt us, files listed in filelist that don't exist aren't included
13:35:47 <jcapik> sochotni: I wouldn't say it's a problem
13:35:59 <akurtakov> I'm withdrawing it :)
13:36:00 <sochotni> jcapik: yes because we changed the guidelines, but we are thinking long-term
13:36:04 <akurtakov> let's move on
13:36:10 <cspike> akurtakov: man, i really feel bad now :(
13:36:38 <akurtakov> cspike: there is nothing to feel  bad for
13:36:41 <sochotni> akurtakov: I'll help you refine it...
13:36:48 <akurtakov> that's what these meetings are for
13:36:51 <sochotni> it's gonna be usable
13:36:56 <cspike> i already had concers with sochotni's subpackage idea two week ago and now i'm the bad guy again :(
13:37:13 <sochotni> cspike: haha, I am glad you ARE taking stand!
13:37:37 <sochotni> we'll refine the script with akurtakov and make it even better
13:37:41 <sochotni> next time!
13:37:42 <cspike> sochotni: nah, you hate me now, admit it :(
13:37:56 <cspike> nah, just kidding, let's move on :)
13:38:09 <sochotni> #info javadoc scriptlet needs to handle license files on its own (probably filelists) - improve !
13:38:31 <sochotni> #topic handling of so libraries inside jars (jansi-native)
13:38:50 <sochotni> this is mine turf once again...
13:38:58 <sochotni> this came up during review https://bugzilla.redhat.com/show_bug.cgi?id=708836
13:39:23 <sochotni> hawtjni library creates native library from java sources using annotations
13:39:57 <sochotni> in this case it created jansi-native.jar and jansi-native-linux{32,64}.jar
13:40:15 <sochotni> jansi-native.jar is pure java jar
13:40:48 <sochotni> -linuxX.jar contains single *so file inside META-INF as a resource that hawtjni loads during runtime
13:41:01 <sochotni> i.e. it's enough to get the jar with native part on classpath and it will work
13:42:17 <akurtakov> this may look a bit confusing but it's way cleaner than the other LD_LIBRARY_PATH and etc. solutinos for loading native parts
13:42:41 <akurtakov> what I'm proposing is finally redefining _jnidir to be _libdir/java
13:42:53 <akurtakov> and make it act a lot more like _datadir/java
13:42:55 <sochotni> yeah, I like it too...but the question of packaging it stands...do we put it inside %{_javadir} or %{_libdir}/%{_jnidir} ?
13:43:28 <akurtakov> +1 for _jnidir once it's redefined
13:44:28 <akurtakov> and changes to maven resolver to look into _jnidir are done too
13:44:55 <sochotni> changing the resolver is not an issue
13:45:05 <cspike> sochotni: do you have any trouble calling the native lib _outside_ the jar
13:45:19 <cspike> sochotni: i mean, why is the so actually inside the jar file?
13:45:50 <sochotni> cspike: it's how hawtjni works (similar to SWT code generator apparently)
13:46:21 <akurtakov> cspike: because this way you allow the classloader to freely load it because it always knows the exact path to the resource
13:46:21 <sochotni> and for problems concerning native libs outside of jars... see https://bugzilla.redhat.com/show_bug.cgi?id=665576
13:46:43 <cspike> i was just looking at http://fedoraproject.org/wiki/Packaging/Java#Packaging_JAR_files_that_use_JNI
13:47:00 <sochotni> cspike: yeah, that is current state but it's not good.
13:47:01 <cspike> but that obviously only applies to objects outside the jar :(
13:47:16 <sochotni> we haven't fixed those guidelines yet
13:47:41 <cspike> ok, now we're on the same page
13:48:01 <akurtakov> cspike: note the part about patching
13:48:09 <akurtakov> we should be able to skip it this way
13:48:20 <akurtakov> at least for projects that use this aproach
13:49:32 <sochotni> overholt: that's another bug in jpackage-utils that we need to cooperate on...
13:49:52 <overholt> sochotni: you mean you and dbhole, right?  :)
13:50:10 <sochotni> overholt: yeah, but he's not here so I addressed you :-D
13:50:19 <overholt> sochotni: I'll tell him in person when I see him
13:50:30 <akurtakov> or someone else with jpackage cvs commit rights :)
13:50:40 <sochotni> we just have to bite the bullet while we haven't branched f16 yet
13:51:05 <akurtakov> I totally agree
13:51:07 <sochotni> and we'll fix all problems that arise..it can't be that hard and it's finally gonna be logical
13:51:34 <akurtakov> especially with the number of java packages growing exponentaly lately
13:51:37 <sochotni> I'll follow what has been agreed upon in that bug and create a patch for jpackage I guess
13:52:27 <sochotni> OK...so mgoldmann will install into %{_jnidir} and I'll fix maven to use jnidirs for resolving artifacts
13:52:45 <sochotni> and also fix %{_jnidir} definition
13:52:52 <akurtakov> agreed
13:53:48 <sochotni> there shouldn't be that many packages affected
13:54:16 <sochotni> #action sochotni prepare patch with fix for jpackage-utils %{_jnidir} definition
13:54:40 <sochotni> #agreed mgoldmann will install jansi-native jar containing native library into %{_jnidir}
13:54:57 <sochotni> #topic osgi provides generator
13:55:06 <sochotni> akurtakov: yours I guess?
13:55:32 <akurtakov> yup
13:55:48 <akurtakov> so I added a new provides generator in jpackage-utils already http://pkgs.fedoraproject.org/gitweb/?p=jpackage-utils.git;a=summary
13:56:10 <akurtakov> nothing is using these provides yet and I'm still clarifying their usage
13:56:42 <akurtakov> every osgi bundle will have a provide in the form of osgi(Bundle-SymbolicName) = Bundle-Version
13:56:59 <sochotni> akurtakov: any example build?
13:58:01 <akurtakov> http://koji.fedoraproject.org/koji/taskinfo?taskID=3102163
13:58:28 <akurtakov> this is a scratch build so you would need to manually inspect the provides
13:58:55 <akurtakov> but this is the package with biggest number of osgi bundles in it that's why I use it for testing
13:59:06 <overholt> you can see them in the tail:  http://koji.fedoraproject.org/koji/getfile?taskID=3102163&name=build.log&offset=-4000
13:59:12 <overholt> osgi(org.eclipse.pde.api.tools.source) = 1.0.300
13:59:16 <overholt> etc.
13:59:43 <akurtakov> the idea is that when someone needs an osgi bundle he/she can just Require: osgi(org.eclipse.pde.api.tools.source) = 1.0.300
13:59:58 <akurtakov> instead of having to find out which package ships this bundle exactly
14:00:24 <akurtakov> this shouldn't be of much interest outside of the eclipse/felix usages
14:00:51 <sochotni> so similar to what you recently created for maven..nice
14:01:08 <sochotni> it's gonna be especially cool in the long run
14:01:26 <sochotni> (i.e. after package rebuild)
14:01:39 <akurtakov> yes, for people familiar with osgi it has some limitations but that's what we can get when marrying two packaging systems
14:02:10 <bckurera> APAC?
14:02:15 <akurtakov> this opens possibilities like installing missing dependencies when doing plugin developemtn
14:02:38 <sochotni> bckurera: currently Java SIG...maybe we are getting into your time slot?
14:02:58 <bckurera> ohh Sorry for the mistake
14:03:07 <akurtakov> let's be quick
14:03:11 <bckurera> you all can carry on as this meeting is not a scheduled one
14:03:16 <sochotni> akurtakov: agreed
14:03:20 <bckurera> thanks and really sorry guys
14:03:29 <KageSenshi> bckurera, theres #fedora-apac :)
14:03:38 <sochotni> bckurera: you can use #fedora-meeting-1
14:03:52 <bckurera> sure thanks folks sorry again
14:03:55 <akurtakov> so this will show up after more eclipse rebuilds and some code written
14:04:08 <sochotni> ok, nothing to add here I guess?
14:04:09 <akurtakov> and it will be added to javapackages git once it's created
14:04:18 <sochotni> when the time comes we'll start using it :-)
14:04:34 <akurtakov> the only one I expected to say smth was mbooth but he is missing today
14:04:49 <sochotni> #topic JBoss AS inclusion status
14:05:01 <akurtakov> mgoldmann: your turn
14:05:12 <mgoldmann> yah
14:05:21 <mgoldmann> so, this slowly moves forward
14:05:36 <mgoldmann> I decided to package jboss-parent first
14:05:51 <mgoldmann> and now I'm trying to get rid of all it's dependencies
14:06:01 <sochotni> I'd say you are creating new packages and responding to reviews faster than we can handle them :-)
14:06:12 <mgoldmann> current progress is here: https://fedoraproject.org/wiki/JBossAS7
14:06:34 <mgoldmann> well, yes, but when I see at the long list of packages that need to be included - it's still slow
14:06:52 <harish> bckurera: meeting on?
14:06:54 <akurtakov> what about a possibility for two threads of reviews ?
14:07:04 <sochotni> mgoldmann: what about the "slimming/modularising" down of jboss?
14:07:05 <jsmith> Even though it's slow going, we appreciate all the work you're putting into it, mgoldmann :-)
14:07:07 <sochotni> i.e. http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002181.html
14:07:31 <akurtakov> mgoldmann: I mean having smth not depending on others for review
14:07:35 <sochotni> harish: moved to either #fedora-apac or #fedora-meeting-1 I guess
14:07:39 <akurtakov> or things are too tight
14:07:39 <kalpurush> harish,  pls join #fedora-meeting-1 , we r all there
14:07:47 <bckurera> we will be having on
14:07:52 <bckurera> #fedora-meeting-1
14:08:10 <bckurera> sorry guys please contrinue :D
14:09:02 <mgoldmann> sochotni: yes, this is a good idea I think
14:09:15 <mgoldmann> but we need more input from AS 7 devs on this I think
14:09:25 <mgoldmann> as they wanted to enable modularization
14:09:32 <mgoldmann> a real one this time :)
14:10:19 <sochotni> mgoldmann: while we are waiting for their input it might be good idea to start packaging hibernate becasue that's gonna stay I guess?
14:10:35 <sochotni> that would really mean two parallel review streams
14:11:51 <mgoldmann> hibernate is really seam dependency
14:11:59 <mgoldmann> and in some part of arquillian
14:12:26 <sochotni> well it was a suggestion :-)
14:12:30 <mgoldmann> I'm pretty busy with pacakging jboss-parent which pretty much required for all JBoss bits
14:12:36 <sochotni> yeah, true
14:13:11 <mgoldmann> if someone would take hibernate- sure!
14:13:25 <mgoldmann> speaking of hibernate..
14:13:41 <mgoldmann> https://bugzilla.redhat.com/show_bug.cgi?id=706832
14:14:00 <mgoldmann> emmanuel commite the licence file to master now
14:14:03 <mgoldmann> commited*
14:14:12 <mgoldmann> https://github.com/hibernate/hibernate-commons-annotations/commit/a11c44cd65dadcedaf8981379b94a2c4e31428d1
14:14:48 <mgoldmann> and he doesn't want to release a release jsut because of that file, can we move fwd with the review and use LGPLv2.1?
14:15:39 <jcapik> mgoldmann: I'm ok with that
14:15:46 <akurtakov> mgoldmann: yup, what we have been doing by now is just adding a clarification in the spec pointing to the commit
14:15:55 <mgoldmann> ok
14:16:38 <akurtakov> mgoldmann: anything else you want to say or we can move on?
14:17:05 <mgoldmann> if anyone is interested in helping on this - please take a jar to package
14:17:06 <mgoldmann> :)
14:17:13 <akurtakov> we should really try limitting meetings to 1 hour
14:17:26 <sochotni> akurtakov: agreed
14:17:46 <akurtakov> let's skip the sig bug topic
14:17:51 <sochotni> just a note...I believe that is LGPLv2.1+
14:18:05 <sochotni> #topic open floor
14:18:27 * overholt has nothing to discuss
14:19:02 * mgoldmann just wants to thank sochotni and akurtakov for help!
14:19:03 * akurtakov too
14:19:19 * sochotni is done too
14:19:27 <cspike> let's call it a day
14:19:32 <sochotni> agreed...
14:19:36 <sochotni> #endmeeting