17:07:33 <sochotni> #startmeeting Java SIG -- https://fedoraproject.org/wiki/SIGs/Java
17:07:33 <zodbot> Meeting started Wed Dec  8 17:07:33 2010 UTC.  The chair is sochotni. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:07:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:08:02 <sochotni> I guess we'll defer webapps till later?
17:08:08 <akurtakov> yes
17:08:14 <sochotni> ok
17:08:31 <sochotni> #topic Maven 3
17:08:53 <sochotni> so...vanilla package is built in fedora rawhide
17:09:22 <sochotni> Most bugs related to custom resolver are being solved :-)
17:09:36 <akurtakov> I have  used it for tycho build and it seems to work
17:09:39 <sochotni> we should have custom resolver inside maven package by the end of the week
17:10:06 <sochotni> in its current state maven can't built itself just yet..
17:10:29 <akurtakov> do you depend on a number of other project's fixes ?
17:10:32 <sochotni> but most libraries already work (for example aether which is a direct dependency and maven 3 api library)
17:10:44 <sochotni> just https://bugzilla.redhat.com/buglist.cgi?quicksearch=installs+pom+with+incorrect+filename
17:11:16 <sochotni> but these won't affect all builds so it's not a big problem
17:11:35 <akurtakov> hmm, at least embedder is broken
17:11:56 <sochotni> I want people testing custom mvn3-jpp as soon as possible to catch as many bugs as we can early on
17:12:20 <sochotni> that's about it for maven3 for now
17:12:33 <sochotni> I'll send an email to java-devel once we have custom resolver built inside
17:12:45 <sochotni> dwalluck, pingou: welcome
17:13:02 <sochotni> moving on..
17:13:15 <sochotni> want to start with the webapp, or waiting for fnasser?
17:13:31 <akurtakov> let's hope fnasser will join
17:13:51 <sochotni> ok
17:13:51 <pingou> +1
17:13:56 <akurtakov> though I can put dwalluck's words in fnasser's mouth :)
17:13:57 <sochotni> #topic tomcat5->6 migration
17:14:29 <sochotni> I fixed one more package today (logback)
17:14:53 <sochotni> not sure about the rest
17:15:09 <akurtakov> we still have 11 more packages to fix
17:15:37 <nthykier> akurtakov: is eclipse one of them?
17:15:37 <sochotni> I don't think we'll make it in F-15
17:15:43 <akurtakov> nthykier: yes
17:16:13 <akurtakov> I hope to be able to finally free it from tomcat5 for F-15
17:16:39 <sochotni> there's struts, jetty too..
17:16:44 <sochotni> it's not gonna be easy
17:16:52 <akurtakov> I thought jetty got fixed
17:17:31 <sochotni> akurtakov: right, I forgot :-)
17:17:40 <sochotni> no actually...
17:17:40 <sochotni> https://bugzilla.redhat.com/show_bug.cgi?id=652020
17:17:45 <akurtakov> sochotni: http://pkgs.fedoraproject.org/gitweb/?p=jetty.git;a=commitdiff;h=e4eb8839736680eaff707c98082e88798603c40e
17:17:52 <sochotni> the bug should be closed then :-)
17:18:41 <akurtakov> done
17:18:44 <nthykier> mmm, we got struts1.2 using servlet2.5 (which is from tomcat6 as I recall) in Debian.
17:18:59 <nthykier> do you have an earlier version of struts or something to make it more complicated?
17:19:09 <akurtakov> dwalluck: you're struts maintainer, right?
17:19:15 <akurtakov> nthykier: 1.2.9
17:19:16 <sochotni> akurtakov: orion is
17:19:26 <nthykier> yeah, same version
17:19:59 <nthykier> Namely we are doing a servlet 2.4 -> 2.5 migration in Debian, so I am somewhat interesting in this as well
17:20:23 <sochotni> nthykier: any tracking bug for that endeavour?
17:20:26 <nthykier> particularly if you have patches ;)
17:20:49 <akurtakov> nthykier: https://bugzilla.redhat.com/show_bug.cgi?id=640397
17:20:59 <sochotni> nthykier: that's our tracking bug
17:21:00 <nthykier> sochotni: Not yet, we have too many reverse dependencies left to have started a narrowed down removal.
17:21:05 <dwalluck> akurtakov: If it says so. The product I was working on no longer ship struts RPMS, just zips
17:21:08 <sochotni> feel free to look at solved moves
17:21:19 <dwalluck> akurtakov: However, I think tomcat might make use of struts 1.3.x
17:21:21 <nthykier> awesome
17:21:46 <akurtakov> nthykier: but you can also look at the packages because I've been reducing tomcat5 deps for last year
17:21:52 <sochotni> nthykier: some might not be absolutely correct since they werent completely tested of course
17:22:25 <akurtakov> if it compiles it works :)
17:22:33 <nthykier> We only started recently (we still got a package depending on 2.3 >.< )
17:22:43 <sochotni> Linus's words if I am not mistaken :-)
17:23:16 <sochotni> move on?
17:23:27 <akurtakov> sure
17:23:48 <sochotni> #topic New add_maven_depmap macro
17:23:52 <sochotni> my little toy -)
17:24:00 <sochotni> ah, ok..
17:24:09 <sochotni> fnasser-away: really away?
17:24:20 <sochotni> or should we start webapps?
17:24:28 <akurtakov> fnasser-away: dwalluck: you might be interested in this topic too
17:24:51 <fnasser-away> soI am leaving, left it logging so I can read laer.  Sorry for the UTC time confusion I got another mtg in a few minutes, have tp leave
17:25:00 <sochotni> ah, ok then
17:25:12 <fnasser-away> akurtakov, I am, will check later, and talk to dwalluck
17:25:13 <akurtakov> sochotni is working on new macro to use if with maven3
17:25:14 <sochotni> #topic Java webapps installation
17:25:31 * fnasser-away is late, runs
17:25:40 <akurtakov> so there is http://dep.debian.net/deps/dep7/
17:25:59 <sochotni> so that people can leave if they are mainly interested in webapps (which dwalluck and nthykier are I guess)
17:26:22 <sochotni> yes, I've read throuh it + the man page for proposed tool to deploy the webapps
17:26:48 <akurtakov> I have raised some concerns which got somehow answereed http://lists.debian.org/debian-java/2010/12/msg00014.html
17:26:50 <sochotni> I am not much of a servlet guy, but I have my opinions how server configuration should be done :-)
17:27:27 <nthykier> This is the initial draft of how we think it could be done, so by all means feel free to raise concerns
17:27:50 <sochotni> #link http://dep.debian.net/deps/dep7/ debian draft for java webapp packaging
17:28:08 <nthykier> Optimally we can find a solution that benefits both Fedora and Debian and work on it together
17:28:12 <akurtakov> what about ear, sar and other archives
17:28:18 <sochotni> well...not sure but isn't debian using /usr/share/webapps for php applications too?
17:29:02 <sochotni> I know Gentoo is using that directory for webapps (and they have webapp-config tool http://sourceforge.net/projects/webapp-config/) too
17:29:58 <pingou> (kinda old)
17:30:33 <sochotni> akurtakov: what is actually difference between ear/sar/war?
17:30:33 <nthykier> sochotni: not what I know of, but DEP-7 proposes to use /usr/share/java/webapps/
17:30:49 <sochotni> nthykier: ah, right..
17:31:11 <akurtakov> they are all zips with different kind of metadata and layout?
17:31:17 <pingou> compiled on /usr/share ?
17:31:20 <akurtakov> dwalluck: ^^ you're hte one here
17:31:41 <akurtakov> also the deploy tool is supposed to create a war and deploy it, right?
17:31:57 <sochotni> akurtakov: I'd say re-package more like...
17:32:19 <sochotni> if the /etc/java/webapps/%{name} doesn't contain anything it will just deploy the original war
17:32:32 <nthykier> akurtakov: as I understand DEP-7 and the follow up we got; it will create some format understood by the container, so it could be a war, but also a sar or whatever
17:32:33 <dwalluck> akurtakov: Is there a question?
17:33:03 <akurtakov> we have one more problem in this case how will the deploy tool get runned when a library used in the war get updated?
17:33:10 <akurtakov> dwalluck: what is actually difference between ear/sar/war?
17:33:40 <dwalluck> akurtakov: possibly some metadata in META-INF I believe
17:34:19 <sochotni> dwalluck: but the structure is the same basically so it's just suffix that's different + content of metadata...
17:34:23 <sochotni> it's still a zip
17:34:30 <nthykier> akurtakov: Debian has support for file triggers here that would allow the tool to react to any update of libraries - so that should be possible at least on the Debian side, though this approach is less than optimal of Fedora does not have this kind of support
17:34:34 <dwalluck> akurtakov: really webapps implies .war to me, but...
17:34:35 <nthykier> for*
17:34:46 <dwalluck> akurtakov: ear is for EJB related
17:35:05 <akurtakov> nthykier: well, you won't know which container the user has deployed into
17:35:13 <akurtakov> so you can't automate this with triggers
17:35:19 <nthykier> akurtakov: the tool should record this when deploying the webapp
17:35:38 <nthykier> is it possible for a webapp to refer to a library outside the container or does the war have to contain all its dependencies?
17:35:51 <sochotni> nthykier: we would have to know which libraries are in which deployed war...
17:35:58 <dwalluck> .war will have WEB-INF but I would say this poklicy can apply to any ?ar archive of the sort
17:36:20 <akurtakov> nthykier: wars have their libs in web-inf/lib
17:36:33 <sochotni> nthykier: I guess we could inject classpath to outside of container...but IMO that wouldn't work
17:36:33 <akurtakov> which we should make symlinks to system jars
17:36:51 <sochotni> akurtakov: would that work inside zip?
17:36:55 <sochotni> I don't think so..
17:37:06 <sochotni> so we will be bundling things inside wars when deploying
17:37:16 <akurtakov> sochotni: hmm, this is a no go
17:37:46 <akurtakov> I have never thought that zip is not capable of handling symlinks
17:37:49 <akurtakov> are you sure?
17:37:50 <sochotni> java webapps can be 'exploded"
17:37:58 <sochotni> ie they don't have to be "war"ed
17:38:17 <sochotni> akurtakov: question is if the container would understand it...
17:38:18 <nthykier> sochotni: if all containers support that, then that would probably be best to solve this issue
17:38:50 <sochotni> dwalluck: ^^ that was IMO, so you input would be appreciated
17:38:58 <dwalluck> we wanted all this archives to be exploded, so as to not bundle jars inside
17:39:21 <dwalluck> if you bundle jars inside, you can't link to the system jars, you don't get updates/bugfixes/security fixes, etc.
17:39:22 <akurtakov> nthykier: well, so the given tool will just keep track of what webapp was symlinked in which containers webapps dir?
17:40:13 <nthykier> akurtakov: I think we could do that (if we cannot rely on using symlinks to keep dependencies updated e.g. for war files)
17:40:37 <sochotni> nthykier: yeah, although deploying wars is in dep7 for now...
17:40:49 <nthykier> it makes it hard to write the tool, but I think it is a solution
17:40:49 <sochotni> that would be good to reconsider due to these things...
17:41:00 <dwalluck> also it's not just metadata but say, some interfaces that these archives implement, but for our purposes I think we can consider them identical, as they are all types of webapps to be deployed in a container
17:41:49 <sochotni> ok so we'd have exploded webapps is /usr/share/webapps/%{name} directory
17:42:24 <sochotni> and tool would copy them to container + changes present in /etc/java/webapps/%{name} content on top
17:43:33 <sochotni> dep 7 says this: Approach 2 is unappealing for Debian packages since the files would need to be installed in the web application root for every possible web container to work out of the box with any web container in Debian, but the user may wish to run multiple web containers with different sets of applications.
17:43:39 <akurtakov> well, we still don't have a clear way to map webapp to servlet version
17:43:43 <sochotni> (approach 2 being the exploded thing)
17:44:10 <dwalluck> Also is the webapp container specific?
17:44:19 <dwalluck> Not usually, but this is a potential problem
17:44:51 <dwalluck> I guess that factors to servlet version, say tomcat5 vs tomcat6 on the same system, is that the use case?
17:45:00 <akurtakov> dwalluck: I think that container specific webapps should be installed in the given containers webapp dir
17:45:13 <akurtakov> dwalluck: yes
17:45:14 <nthykier> akurtakov: dwalluck: So the tool should have some dependency data to prevent it from deploying webapps into an incompatible container?
17:45:40 <akurtakov> nthykier: the problem for me is that you can't get that from normal war in most cases
17:46:04 <akurtakov> so the tool should use rpm/deb to handle this dependencies ?
17:46:07 <sochotni> isn't there some standard way to say "I need servlet api 2.5"  ?
17:46:19 <sochotni> for webapps I mean
17:46:28 <sochotni> somewhere in metadata
17:47:07 <akurtakov> sochotni: http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
17:47:37 <nthykier> akurtakov: I think using rpm/deb dependencies would be the best choice to solve that (since they already have a dependency resolver) - the tool would just have a minimum to say that container X supports or does not support servlet version Y etc.
17:48:38 <sochotni> #info using wars to deply quickly gets problematic due to updates to bundled libraries, exploded webapps are probably a way to go
17:49:06 <akurtakov> what about not having such tool, agree on fs layout, and stop containers from autorun new apps
17:49:17 <nthykier> sochotni: but it requires that the containers support it - do we know that all containers support exploded webapp?
17:49:17 <akurtakov> there are 2 possible problems:
17:49:50 <akurtakov> * can we stop containers from running new apps
17:50:02 <sochotni> dwalluck: any idea if there are containers not supporting exploded webapps?
17:50:49 <akurtakov> * does every container support multiple layout because it will need at least 2 of them - shared and container specific
17:51:01 <akurtakov> tomcat has no problems with both topics
17:51:19 <akurtakov> every container I know supports exploded webapps
17:51:47 <nthykier> akurtakov: multiple layout - as in "part of the webapp is in /usr/share/.../webapp and the other part is in /etc/.../webapp" ?
17:52:11 <dwalluck> sochotni: generally, the container explodes it anyway, on the fly
17:52:14 <sochotni> nthykier: I think akurtakov meant "one webapp is in /usr/share" and other in /var/lib/tomca6" for example
17:52:41 <akurtakov> nthykier: multiple layout as in /usr/share/../webapp and tomcat_dir/webapps/tomcat-manager -application :)
17:52:58 <sochotni> e.g. more than 1 place to look for deployed apps
17:53:03 <nthykier> ah okay - couldn't that be solved with symlinking ?
17:53:36 <akurtakov> nthykier: I'm trying to avoid this so the tomcat admin can use tomcat manager to just start/stop application
17:53:51 <akurtakov> jboss admin can use the jboss admin console to do this and etc.
17:54:07 <akurtakov> without having to go doing some symlinking
17:54:23 <sochotni> that's another point...
17:54:28 <akurtakov> note that there are also cases when tomcat admins are not system admins
17:54:46 <sochotni> two approaches: install=deply, or use specific tool for deploying per-container
17:55:10 <sochotni> that is install=deploy
17:55:31 <akurtakov> third one: install != start, use existing container's tool to start
17:55:56 <sochotni> akurtakov: what if system admin installs application but doesn't want tomcat5 admin to be able to start it but only tomcat6
17:56:05 <pingou> deploy = start ?
17:56:07 <nthykier> I think we would like to avoid install = deploy especially if it means that the webapp is deployed in all containers
17:57:19 <sochotni> I also happen to think it's not a good approach
17:57:19 <akurtakov> we can definetely stop tomcat from autostarting
17:57:32 <akurtakov> not sure about other containers
17:57:49 <akurtakov> pingou: I stopped using deploy because different people puts different meaning in it :)
17:58:06 <pingou> ok
17:58:06 <sochotni> akurtakov: as you yourself said...tomcat admins are not always system admins, what about use case with 2 different tomcat instances one that should be able to deploy/start and one that shouldn't?
17:58:14 <nthykier> What containers do we currently have ? tomcat6, jetty? (tomcat5 but we are all trying to get rid of that)
17:58:34 <akurtakov> nthykier: I do care about tomcat6/7, jetty and jboss
17:59:06 <akurtakov> sochotni: this is handled by the given instance config
17:59:51 <akurtakov> sochotni: you can even have 2 different webapps dir in one tomcat instance and autorun from one of the folder but not from the other one
18:00:13 <sochotni> akurtakov: ok, but you have to do more configuration per installed app
18:00:34 <sochotni> in case you want ACLs like that
18:01:10 <akurtakov> sochotni: no
18:01:19 <sochotni> On the other hand introducing anoter tool is not exactly great either..
18:01:28 <akurtakov> you install the exploded webapp
18:01:39 <sochotni> I don't have a stake in all of this though
18:01:48 <akurtakov> and it's available in all containers
18:02:01 <akurtakov> and it is run depending on the given containers config
18:02:20 <sochotni> akurtakov: that's the problem...
18:02:32 <akurtakov> and manageable with the containers tools
18:02:39 <sochotni> akurtakov: what if I want the jetty admin to be able to run app A but not app B
18:02:51 <sochotni> as a sysadmin
18:02:55 <akurtakov> sochotni: you set jetty not autorun
18:02:58 <sochotni> not a jetty admin
18:03:10 <akurtakov> and use jetty admin tool to start app A
18:03:45 <sochotni> once again: 2 admins: system and jetty admin. system admin doesn't want to allow jetty admin to run installed app A
18:04:12 <nthykier> app B*
18:04:18 <sochotni> he'll have to configure jetty contexts (or whatever they are called)
18:05:22 <akurtakov> sochotni: comeon if they can't talk noone can solve it by some technical magic :)
18:06:22 <akurtakov> and not letting the container admin to decide which app to run is like not allowing the system admin to install packages
18:06:28 <sochotni> akurtakov: It's not about talking to each other from my POV...more like some weird company policy
18:08:22 <sochotni> but one way or the other: I will probably never be the one administering these things...
18:09:02 <sochotni> but from my (admittedly small and skewed) admin experience...I'd prefer to have installation separated from deployment
18:09:04 <akurtakov> let's try to get some meaningful page with the issues discussed and try again on another meeting
18:09:23 <sochotni> ok...
18:09:29 <akurtakov> sochotni: btw, what do you call deployment - started in the container or available in the container?
18:09:38 <sochotni> maybe we'll get more input from others once they read logs
18:09:41 <akurtakov> available in a stopped page
18:09:43 <sochotni> available
18:09:50 <sochotni> available in a stopped stage then
18:10:29 <sochotni> #agreed to disagree for now on way to handle installation and deployment of java webapps (automatic vs. tool approach)
18:10:57 <sochotni> #topic New add_maven_depmap macro
18:11:11 <sochotni> #undo
18:11:11 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x146c7f50>
18:11:29 <sochotni> #info will continue discussion once more input is collected from interested parties
18:11:33 <sochotni> #topic New add_maven_depmap macro
18:12:01 <sochotni> I prepared new macro to handle maven depmap installation (to replace %add_to_maven_depmap macro)
18:12:12 <sochotni> proposed patch to jpackage-utils is here: https://bugzilla.redhat.com/show_bug.cgi?id=658809
18:12:39 <akurtakov> hmm, no response yet
18:12:51 <sochotni> at it's simplest form this is enough: %add_maven_depmap JPP-%{name}.pom
18:13:20 <sochotni> I guess everybody is reading the bug and patch :-)
18:14:00 <akurtakov> sochotni: hmm, can we make it put depmaps in some /var or whatever directory
18:14:14 <akurtakov> because it's not a config actually
18:14:21 <dwalluck> wouldn't you want to pass the pom file itself, then the macro takes care of naming it correctly? I assume it tries to read the groupId and artifactId from the pom itself to avoid errors
18:14:58 <akurtakov> and fix update_maven_depmaps to use both directories?
18:15:18 <sochotni> akurtakov: we could but we'd have to modify %update_maven_depmap macro as well
18:15:22 <sochotni> akurtakov: yeah
18:15:25 <akurtakov> they can even be put in /usr/share/maven/depmaps
18:15:44 <dwalluck> Why is the depmap necessary?
18:16:00 <sochotni> dwalluck: problem is that macro was a bit complicated so it's in python
18:16:04 <sochotni> to parse the pom file
18:16:23 <sochotni> but python doesn't know about rpm macros (etc $RPM_BUILD_ROOT)
18:16:44 <sochotni> so there is no way to let python macro install the pom file in the right place
18:16:48 <sochotni> plus...
18:16:59 <sochotni> sometimes you need to name it a bit differently..
18:17:09 <sochotni> the logic would get weird in some cases IMO
18:17:56 <sochotni> oh one more thing...the pom filename has to be "compatible" with jar filename if it's provided
18:18:07 <sochotni> that means correct "." and "-" usage
18:18:27 <sochotni> dwalluck: depmap is necessary in for resolution of maven artifacts to local jar files
18:18:52 <sochotni> names of local files are not (and can't be) completely standardised
18:19:22 <sochotni> sometimes we use subdirectories, sometimes not
18:19:50 <akurtakov> sochotni: but the update_maven_depmap change won't be big
18:19:58 <sochotni> #action put fragments into /usr/share/maven/depmaps
18:20:07 <sochotni> akurtakov: true, it's a small addition
18:20:09 <akurtakov> it will just have to traverse 2 directories not one
18:20:14 <akurtakov> right?
18:20:26 <sochotni> you're right, it's quite easy..
18:20:38 <sochotni> but the thing is...aren't we moving the generated depmap as well?
18:20:55 <akurtakov> sochotni: let's not do it for now
18:20:59 <sochotni> ok
18:21:21 <akurtakov> we will have just one package with weird thing as conf
18:21:29 <akurtakov> and I don't want to break maven2
18:21:33 <akurtakov> at least not yet
18:21:40 <sochotni> yup, you're right
18:21:42 <akurtakov> btw, I have to go in 5 mins
18:21:59 <sochotni> noted
18:22:34 <sochotni> dwalluck: any more questions/suggestions...I am all ears
18:22:55 <sochotni> pingou: you as well :-)
18:23:05 <sochotni> feel free to comment on the bug
18:23:10 <pingou> fine for me
18:23:18 <akurtakov> what else do we have to discuss
18:23:25 <sochotni> Java SIG tracker bug
18:23:27 <sochotni> and open floor
18:24:06 <akurtakov> my plan was going through all the bugs assigned to the java sig and trying to make some action on them
18:24:07 <sochotni> #topic Java SIG tracker bug status
18:24:09 <dwalluck> I don't think so
18:24:18 <akurtakov> but it will have to wait for better time
18:24:24 <sochotni> yeah
18:24:28 <akurtakov> in short everyone please take few bugs
18:24:33 <akurtakov> and fix them :)
18:24:46 <sochotni> I have 2 reviews from that pile..
18:24:53 <sochotni> should be closed shortly
18:25:04 <sochotni> ok...so deferred
18:25:33 <sochotni> #agreed everyone should look at FE-JAVASIG from time to time and solve a bug :-)
18:25:40 <sochotni> #topic open-floor
18:26:17 <pingou> the mailing lists seems to be doing fine
18:26:27 <sochotni> pingou: agreed, noone is complaining :-)
18:26:28 <pingou> although I don't really know how to check
18:26:41 <sochotni> the reply-to set to java-devel is OK too
18:26:49 <pingou> sochotni: I did check but do we only see commit from akurtakov and you ?
18:27:21 <sochotni> pingou: I guess that's because everyone else has been busy with other things maybe?
18:27:42 <pingou> i hope so :)
18:28:01 * akurtakov goed to topic "open the door"
18:28:10 <akurtakov> err goes
18:28:24 <sochotni> pingou: there were orion's commits as well
18:28:43 <sochotni> to apache-commons-jexl
18:28:51 <sochotni> akurtakov: bye
18:29:01 <pingou> and jeff
18:29:10 <sochotni> so all's well
18:29:10 <pingou> akurtakov: ++
18:29:10 <pingou> so i guess it is fine
18:29:24 <sochotni> pingou: thank's for setting it up btw
18:29:39 <pingou> no pb
18:30:04 <sochotni> so...
18:30:06 <sochotni> closing?
18:30:11 <pingou> yup
18:30:15 <sochotni> #endmeeting