axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nirmal Mukhi <nmu...@us.ibm.com>
Subject [wsif] IRC chat log
Date Thu, 30 Jan 2003 16:52:14 GMT
Hi,

We had a chat at 10am EST today as planned. Here's a summary:

0. Release wrap-up
        We patted each other on the back as planned
1. Forrest source and building web site
        Forrest src will be moved to WSIF CVS and we will add an ant task 
to build it
2. GUMP failure
        Piotr plans to temporarily disable JCA sample from being built and 
is working with Sam to get the correct JARs available for GUMP so we won't 
have future failures
3. Short term plans for WSIF changes
        We came up with a TO DO list, posted below (person-by=person break 
up of tasks)
4. Working better together
        We agreed to keep each other informed using the dev list, using 
our judgement and subject to our time constraints re. how often to post, 
what to discuss, etc. The basic idea is that we should avoid source/design 
conflicts and have a general idea of what work is being done. We also 
agreed that all developers must run junit test suite before each commit to 
make sure they don't break anything. Alek/Nirmal plan to work on 
documenting/refactoring tests to make them easier to run by any developer 
(see TO DO list)

TO DO list
1. forrest task in build.xml 
   (forrest src to be put into appropriate location in WSIF CVS, perhaps 
java/doc)
2. Short term changes planned
        Nirmal 
         - making tests easy to run outside WAS (with Alek)
         - perf framework/improvements
         - allow custom factory implementations 
           (involves making default implementations extensible) (with Ant)
        Ant
         - support DIME attachments
         - enable a way for the other providers have a userspcified way to 
be 
           able to manipulate the WSIFMessage parts (mainly to get JROM 
support)
         - look at changing the AXIS provider to seperate out the WSIF 
specifc 
           code fromthe AXIS specific code
         - tidy up Java provider (already started - 2 bugzillas today) and 

           make some things more done more lazy which should help perf
         - getting othe providers to support wrapped/unwrapped style ops 
         - allow custom factory implementations (with Nirmal)
        Owen
          - Better support automatically working out xml to Java 
            mappings - try to make the conventions used configurable 
rather 
            than imposing a convention
            i.e. reduce the need for calls to mapTypes
        Jeremy
          - WSDL2Java, Java2WSDL support for other bindings (kind of 
outside 
            the WSIF project at the moment though)
        Alek
          - make is easier to run unit tests - write a developers guide 
etc. (with Nirmal)
          - document contracts between WSIF and providers

The chat transcript is below.
[10:12] <whitlock> Jeremy can't get on
[10:12] <ant> can he share your screen?
[10:12] <owenb> I think there are network problems here
[10:14] <whitlock> this is Jeremy ... I'll use Mark's machine until I'm on
[10:14] <nirmal> ok
[10:14] <nirmal> let's start then...
[10:14] <nirmal> 1. forrest
[10:15] <nirmal> or wait...0. release wrap up
[10:15] <whitlock> I'm impressed with the number of downloads
[10:15] <alek_s> pretty good interest in WSIF!
[10:15] <nirmal> Great job all! We've had a lot of downloads, now I hope 
we see corresponding traffic on axis-* and wsif-*
[10:15] *** hughesj (~hughesj@imhotep.hursley.ibm.com) has joined 
channel #wsif
[10:15] <hughesj> now talking as hughesj!
[10:15] <nirmal> ahh
[10:16] <nirmal> ok, let's talk about Forrest
[10:16] <alek_s> hi Jeremy as Jeremy :-)
[10:16] <nirmal> Frankly we have the best looking site for any open 
source project..barring maybe gimp :-)
[10:16] *** sanjiva (~sanjiva@202.124.170.41) has joined channel #wsif
[10:16] <nirmal> all thanks to Owen for a great job
[10:16] <sanjiva> hi guys .. sorry 2 b late
[10:16] <hughesj> gimp ... is that like gump
[10:16] <hughesj> :)
[10:17] <hughesj> hi Sanjiva
[10:17] <nirmal> hello
[10:17] <alek_s> hi Sanjiva
[10:17] <nirmal> ok, so it seems to me there are two issues with using 
forrest: where to keep the src and how to build the HTML automatically
[10:17] <alek_s> we are talking Forrest
[10:17] <hughesj> I think put the src in WSIF's CVS
[10:18] <hughesj> because most of it is needed for WSIF docs
[10:18] <nirmal> ok, sounds good
[10:18] <alek_s> yes
[10:18] <alek_s> and add soem ant taks to generate HTML docs for dist
[10:18] <owenb> I agree
[10:18] <nirmal> Was there some procedure for getting it built 
automatically? I thought somebody (Dims?) mentioned something?
[10:19] <hughesj> Dims mentioned something called forrestbot
[10:19] <hughesj> which is under development
[10:19] <owenb> There is no automatic Forrest building going on and so 
for the time being we will have to build the site ourselves and then 
check in the html
[10:19] <alek_s> i think currently we need to checkin site updates to 
ws-site CVS repository
[10:19] *** davanum (~dims@icarus.apache.org) has joined channel #wsif
[10:20] <owenb> Hopefully, the ws site will eventually use the "in 
development" ForrestBot
[10:20] <alek_s> hi Dims
[10:20] <nirmal> I see...why doesn't one of us take ownership for 
getting forrest to run automatically each evening - using 
ant/forrestbot/whatever?
[10:20] <nirmal> ahh, here's the man who could point us somewhere
[10:21] <nirmal> Dims, is there an established procedure for getting 
forrest src built and updating xml-site automatically?
[10:21] <owenb> I think that ForrestBot is the answer but it's not being 
used yet
[10:22] <davanum> yes
[10:22] <davanum> what's up?
[10:22] <owenb> When finished, it would allow the build for the ws site 
to extract our forrest source files from cvs and build our site, putting 
the html in the correct place on the server
[10:22] <davanum> not yet. that is long-term. Right now,  i'd advise 
running forrest on your machines and updating ws-site module
[10:23] <nirmal> ok, so we need an ant task short term
[10:23] <owenb> yes
[10:23] <nirmal> let's put that on a todo list
[10:23] <nirmal> TO DO:
[10:23] <owenb> we have to update the html in ws-site
[10:23] <nirmal> 1. forrest task in build.xml
[10:23] <owenb> targets/wsif dir
[10:23] <nirmal> right
[10:24] <alek_s> what would be the best location to Forrest docs? in 
java/doc?
[10:24] <alek_s> or maybe something seaprate for web site?
[10:25] <nirmal> I think java/doc is fine - of course when packaging 
release we first have to build html and package that...what do the 
others think?
[10:25] <owenb> ws-site not xml-stie
[10:25] <owenb> :-)
[10:25] <nirmal> right
[10:26] <nirmal> ok, shall we move on to gump issue?
[10:27] <davanum> you can do anything under ws-site/targets/wsif :)
[10:27] <nirmal> anybody read & understand Piotr's post (about 15 min 
ago)?
[10:28] <ant> post to where?
[10:28] <nirmal> axis-dev I think
[10:29] <ant> its not reach me here yet
[10:29] <nirmal> or no, that was on email to jeremy and sam ruby (I was 
on Cc list)
[10:29] <hughesj> Nirmal, he sent an email but it wasn't to axis-dev
[10:29] <nirmal> he says he plans to turn off jca sample being built
[10:30] <nirmal> that sounds ok with me until Sam Ruby updates j2ee.jar, 
then he can turn the build back on
[10:30] <hughesj> not sure why he didn't send to axis-dev
[10:30] <hughesj> Nirmal: there is *no* j2ee.jar in GUMP
[10:30] <owenb> do we really want to ship the WSIF site in distributions?
[10:30] <hughesj> only j2ee-connector.jar
[10:31] <alek_s> i did not get Piotr email - just checked my emails ...
[10:31] <nirmal> right, "update" was the wrong word, Sam has to make 
sure the correct jar is available
[10:31] <hughesj> <guess> I think Sam hasn't included the j2ee.jar 
because it's a conglomoration of APIs which have their own jars </guess>
[10:31] <owenb> which list?
[10:32] <owenb> hasn't filtered through to me yet
[10:32] <alek_s> we should remeber that it must be J2EE 1.3 and not 1.4 
to compile JCA sample
[10:32] <nirmal> Piotr sent email to Sam Ruby, Cc-ing Jeremy, Hesh and 
me, not on the list, sorry for the confusion
[10:33] <alek_s> maybe you could ask Piotr to forward this email to 
wsif-dev?
[10:33] <nirmal> yes, I will ask
[10:34] <hughesj> hang on ... he's out ... so to save confusion ... I'll 
post it now
[10:35] <nirmal> in short, I think Piotr's working to resolve this with 
Sam, and in the interim proposes leaving the JCA sample out of the 
build, which sounds ok
[10:37] <nirmal> shall we move on?
[10:37] <alek_s> sounds ok
[10:37] <nirmal> short term plans for WSIF changes:
[10:38] <nirmal> let's discuss what each of us is interested in and lay 
out simple ground rules so we don't step on each others' toes
[10:39] <nirmal> As you all know I'd like to work on two things: making 
it easier to run tests (outside WAS environment) and perf 
testing/improvements
[10:39] <nirmal> others?
[10:42] <nirmal> nobody plans on working? ;-)
[10:42] <ant> ok
[10:42] <ant> - support DIME attachments
[10:42] <ant> - enable a way for the other providers have a userspcified 
way to be able to manipulate the WSIFMessage parts (mainly to get JROM 
support)
[10:42] <ant> - look at changing the AXIS provider to seperate out the 
WSIF specifc code fromthe AXIS specific code
[10:42] <ant> - tidy up Java provider (already started - 2 bugzillas 
today) and make some things more done more lazy which should help perf
[10:42] <nirmal> sounds good
[10:42] <ant> so in the near future I'll be on the axis and java 
provider code
[10:43] <owenb> - Better support automatically working out xml to Java 
mappings - try to make the conventions used configurable rather than 
imposing a convention
[10:44] <owenb> i.e. reduce the need for calls to mapTypes
[10:45] <nirmal> ok, i'm noting all this down...others? Alek?
[10:45] <hughesj> - WSDL2Java, Java2WSDL support for other bindings 
(kind of outside the WSIF project at the moment though)
[10:45] <ant> oh,I left out also getting othe rproviders to support 
wrapped/unwrapped style ops
[10:45] <alek_s> i wopuld liek to work with Nirmal to simplify running 
automatic tests on new machine
[10:46] <alek_s> Jeremy: we could probably revisit with AXIS developers 
again idea fo making Java2WSDL, WSDL2Java into seaprate project?
[10:46] <hughesj> that would be fantastic ... do think that would end up 
as a WSIF developers guide to running the unit tests? Is that what you 
meant
[10:46] <nirmal> Jeremy: I think WSDL2Java, Java2WSDL is very important 
- we need to lobby the WS PMC to separate the "core" from Axis IMO
[10:46] <hughesj> agreed, a WebServices commons project perhaps
[10:47] <nirmal> yes
[10:47] <hughesj> Dims, did you hear that :-)
[10:47] <alek_s> Jeremy: yes - that what i would lliek to have for 
myself so i hope we write it with Nirmal
[10:47] <nirmal> then projects like Axis can add support for their own 
stub generation (and we can do similar extensions to support our bindings)
[10:47] <alek_s> Jeremy: but also refactor tests if necessary to make 
them easier to set up and run
[10:48] <nirmal> Alek did you also plan to work on modularisation - 
removing provider interdependencies etc.?
[10:49] <alek_s> AXIS could keep copy of WSDL2Java inside their 
repository to ease bundling (similarly liek Xerces keeps copy XML APIs 
in its repository even though it is on xml-commons)
[10:49] <alek_s> Nirmal: yes - but this is hardly short term - it 
requires substantial effort and commitment from everybody
[10:49] <nirmal> yes, re. WSDL2Java and Java2WSDL the issue is more of 
separating "core" API (JAX-RPC compliant tool) from project specific 
code generation
[10:50] <nirmal> ok, do you have any specific plans for that in the 
short term? If so I can add it to the TODO list
[10:50] <hughesj> can you define short term :-)
[10:50] <nirmal> I would suggest we should make a start - for example 
Ant has included "look at changing the AXIS provider to seperate out the 
WSIF specifc
[10:50] <nirmal>    code fromthe AXIS specific code
[10:50] <nirmal> which I think is a start
[10:50] <alek_s> i would liek to write down what is public WSIF API, 
what is provider API to WSIF and what aprts are core implementation
[10:51] <owenb> public API is the org.apache.wsif package
[10:52] <hughesj> Alek: I think that would be useful because there are 
extras on top of org.apache.wsif.* such as org.apache.wsif.util.WSIFUtils
[10:52] <alek_s> yes 
[10:53] <nirmal> right, I think we just need a clear picture of WSIF 
core, what is the provider API & *contract* (latter completely missing 
right now)
[10:53] <alek_s> having well defined API should make writing 
applications using WSIF easy 
[10:54] <nirmal> oh I would like to add one more thing:
[10:54] <nirmal> currently we have just one way for a user to plug in 
code: as a separate provider
[10:54] <alek_s> Nirmal: i will add to my task describing *coontract* - 
i think that is exactly what is should be
[10:54] <nirmal> I would like to complete our abstract factory 
implementation by allowing alternative WSIFServiceFactory classes to be 
plugged in
[10:55] <hughesj> Nirmal: that is a good idea ... we would need to do 
some work in all the places that rely on our current *Impl classes today
[10:56] <nirmal> yes, I remember Ant/your point about how we need to 
make WSIFServiceImpl (and other classes) extensible (right now most 
methods are private)
[10:56] <ant> yes
[10:56] <owenb> that is definitly reqiured
[10:56] <nirmal> let me put that down as well - Ant would you have the 
time to help me do that?
[10:56] <ant> sure ok
[10:56] <nirmal> ok
[10:57] <nirmal> ok, I'm summarising, hang on...
[10:57] <nirmal> anything else to add?
[10:57] <nirmal> after I post the list of tasks, lets discuss ground 
rules for working
[10:58] <ant> there's plenty of bugzillas waiting...
[10:59] <nirmal> I am planning to work on Peter Lane's problem
[10:59] <alek_s> we should be using mailing list to coordinte who is 
working on what to avoid wasted effort ...
[10:59] <nirmal> I would say feel free to pick what you like (just 
announce on the dev list that you are working on that)
[10:59] <nirmal> right
[10:59] <nirmal> i.e. ditto Alek
[10:59] <ant> peter's problem is not very easy to fix properly right now
[11:00] <nirmal> I see - are you sure it is a bug?
[11:00] <ant> yes
[11:01] <nirmal> ok, if you know something about it could you respond to 
him? or send email to the dev list with your thoughts and I can try 
investigating further...
[11:01] <nirmal> i.e. I'm keen on taking care of it or doing what we can 
to help him
[11:01] <ant> ok, I'll talk to you offline about it
[11:01] <nirmal> ok
[11:02] <nirmal> I promise to post to the dev list once Ant/I complete 
investigating the issue
[11:02] <ant> I have already sent him a patch that may get past this 
particular problem, not heard bacj yet
[11:02] <nirmal> I see, sounds good, could you Cc the dev list? (not 
sure if you did, I didn't see it)
[11:02] *** davanum is now known as dims_away
[11:02] <ant> i didn't
[11:03] <nirmal> ok, could you fwd it to the dev list? Just to keep 
everybody informed, let's try and follow that practice
[11:04] <nirmal> I began writing a sample service based on his schema 
(i.e. I wouldn't have done it had I known you were working on it)
[11:04] <nirmal> ok, here's the TO DO list:
[11:04] <nirmal> TO DO:
[11:04] *** Signoff: nirmal (Excess Flood)
[11:05] *** nirmal (~nmukhi@yktgi01e0-s1.watson.ibm.com) has joined 
channel #wsif
[11:05] <nirmal> oops, got disconnected (server thought I was flooding)
[11:05] <nirmal> to complete:
[11:05] <nirmal> Alek
[11:05] <nirmal>   - make is easier to run unit tests - write a 
developers guide etc. (with Nirmal)
[11:05] <nirmal>   - document contracts between WSIF and providers
[11:06] <nirmal> sounds excellent
[11:06] <nirmal> re. ground rules:
[11:07] <nirmal> 1. USe the dev list as much as possible to inform other 
developers of what you are working on - no rigid rules, use your 
judgement in posting things, but the goal is that nobody should be 
surprised by commits/changes
[11:07] <nirmal> does that sounds ok with all?
[11:08] <nirmal> hang on - did everybody get the *complete* todo list
[11:08] <ant> no
[11:08] <nirmal> I sent a person-by-person breakup
[11:08] <nirmal> oh ok, let me post again, a little bit at a time
[11:08] <nirmal> TO DO:
[11:08] <nirmal> 1. forrest task in build.xml
[11:08] <nirmal>    (forrest src to be put into appropriate location in 
WSIF CVS, perhaps java/doc)
[11:09] <nirmal> 2. Short term changes planned
[11:09] <nirmal> Nirmal
[11:09] <nirmal>  - making tests easy to run outside WAS (with Alek)
[11:09] <nirmal>  - perf framework/improvements
[11:09] <nirmal>  - allow custom factory implementations
[11:09] <nirmal>    (involves making default implementations extensible) 
(with Ant)
[11:09] <nirmal> Ant
[11:09] <nirmal>  - support DIME attachments
[11:09] <nirmal>  - enable a way for the other providers have a 
userspcified way to be
[11:09] <nirmal>    able to manipulate the WSIFMessage parts (mainly to 
get JROM support)
[11:09] <nirmal>  - look at changing the AXIS provider to seperate out 
the WSIF specifc
[11:09] <nirmal>    code fromthe AXIS specific code
[11:09] <nirmal>  - tidy up Java provider (already started - 2 bugzillas 
today) and
[11:09] <nirmal>    make some things more done more lazy which should 
help perf
[11:09] <nirmal>  - getting othe providers to support wrapped/unwrapped 
style ops
[11:09] <nirmal>  - allow custom factory implementations (with Nirmal)
[11:09] <nirmal> Owen
[11:09] <nirmal>   - Better support automatically working out xml to Java
[11:09] <nirmal>     mappings - try to make the conventions used 
configurable rather
[11:09] <nirmal>     than imposing a convention
[11:09] <nirmal>             i.e. reduce the need for calls to mapTypes
[11:09] <nirmal> Jeremy
[11:09] <nirmal>   - WSDL2Java, Java2WSDL support for other bindings 
(kind of outside
[11:09] <nirmal>     the WSIF project at the moment though)
[11:09] <nirmal> Alek
[11:09] <nirmal>   - make is easier to run unit tests - write a 
developers guide etc. (with Nirmal)
[11:09] <nirmal>   - document contracts between WSIF and providers
[11:09] <nirmal> ********* that is it ************
[11:09] <nirmal> everybody got it this time?
[11:10] <ant> Is mark on holiday?
[11:10] <owenb> yes
[11:11] <nirmal> ok, back to ground rules then, everybody agree with the 
goal that everybody should be informed, so that nobody is surprised by 
commits or changes, and the dev list should be used for this prupose?
[11:11] <ant> you already know I think the CVS commit log is enough for 
a lot of changes
[11:12] <ant> I don't think we have to discuss *everything* 1st
[11:12] <ant> for example
[11:12] <owenb> Inform the list if it might affect other people's work 
but I'm sure we'd all agreee that it's not necessary for every 
individual commit
[11:13] <nirmal> no, one commit doesn't imply a message to the dev list
[11:13] <ant> I've just said I'm doing stuff with the Java provider, can 
I make commits now, or do I need more discussion on dev list 1st?
[11:13] <nirmal> however, the goal is that when I see a commit, I should 
have some idea (based on previous discussion) why that happened
[11:13] <hughesj> sorry I'm being distracted
[11:14] <nirmal> right, that is good that I know you are working on the 
java provider. That is a simple change (making methodName mandatory) and 
when you commit I will understand
[11:14] <nirmal> so there's an example of where discussion is not needed
[11:14] <ant> thats not really all the changes I was talking about
[11:15] <nirmal> but for example when you change WSIFMessage so JROM 
support is possible, it is core stuff and you should keep everybody 
informed of broadly what you are planning to do, have some discussion of 
design (if you feel it is important) etc.
[11:15] <nirmal> I'm not proposing a rule to make life difficult for all 
of us, just to make sure we can work together
[11:16] <owenb> re Bugzillas - if you are working on one - make sure the 
bug is updated to say who it is assigned to - then there is no need to 
post to the list to say I'm working in bug XXXXX, it will be obvious
[11:16] <ant> yes sure for big design changes. For others I thnk if 
anyone has questions about a commit they should just ask them on dev 
list, not get upset they didn't know already
[11:18] <nirmal> ok, all I am saying is use your judgement to make sure 
that everybody is informed. If you think what you are working on 
justifies a design discussion do that. If you are changing a "p" to a 
"q" maybe you can just commit. Use your judgement. Can we agree to that?
[11:18] <alek_s> i agree
[11:18] <owenb> yes
[11:19] <alek_s> (we do not have possibility to have all commiters to 
meet together physically so we should use other means to keep informed)
[11:19] <nirmal> we just have to try and be good citizens so we can all 
develop the code we love with trust and confidence <Nirmal shuts his 
"book of quotes">
[11:21] <nirmal> Apache has rules that say committers must keep others 
informed of each commit etc. etc. We have to follow this rule *in 
spirit* so that we don't have to deal with CVS conflicts etc. etc.
[11:22] <nirmal> Also, lack of information exchange can lead to 
conflicting design/core changes and that would be catastrophic, perhaps 
a waste of weeks of developer time etc.
[11:22] <ant> I'm not arguing that we shouldn't do that, what I'd like 
is some agreement that a detailed commit log text is ample in a lot of 
cases
[11:23] <nirmal> the problem with relying on that is that you *make the 
change* and then commit. If you could post that same text *before* 
(saying this is what you plan), then just commit later it really doesn't 
waste your time very much and keeps others informed better (for e.g. 
they can comment on the proposed change prior to the commit)
[11:24] <nirmal> again of course I am *not* saying that you need to post 
about every single commit, just follow the goal of keeping others 
informed and avoiding conflicts, use your judgement about what to post, 
how much to post, etc.
[11:27] <owenb> Anything else on the agenda?
[11:27] <alek_s> i think that Nirmal shoudl post this TODO list and chat 
log to wsif-dev
[11:28] <nirmal> yes, just one more thing
[11:28] <nirmal> rule #2: Hursley runs tests each evening (they already 
do) and if tests break responsible committers have to fix the situation 
ASAP
[11:28] <alek_s> we can keep discussion during next week irc chat ...
[11:29] <ant> do we run tests each evening?
[11:29] <nirmal> Hursley does it automatically, right Mark?
[11:29] <ant> I don't think we do
[11:29] <nirmal> oh, Mark is away, can Owen/Ant/Jeremy confirm that?
[11:29] <nirmal> oh I see
[11:30] <ant> we each run them manually as we change stuff
[11:30] <nirmal> ok then - I'll try and get working on making tests easy 
to run ASAP so then each developer is responsible for running tests
[11:30] <nirmal> right
[11:30] <nirmal> everybody agree with that?
[11:30] <owenb> yes
[11:30] <ant> I think all commiters should do this before *any* commit
[11:31] <nirmal> yes
[11:31] <owenb> goes without saying
[11:31] <alek_s> i agree - just needs first to get test to run ...
[11:33] <nirmal> ok then, it looks like we have a plan of work and rough 
ground rules - I am aware that Ant feels that having to discuss 
everything constrains him, but let's all do as much as we can without 
feeling constrained, ok?
[11:34] <nirmal> anybody have anything to add, or shall we close the 
chat officially
[11:35] <nirmal> to wrap up:
[11:35] <nirmal> forrest & other to do items (on to do list posted above)
[11:35] <nirmal> working better together: we will try to keep each other 
informed when possible using our judgement, and we will run tests prior 
to commits to avoid breaking code
[11:35] <owenb> </chat>
[11:35] <alek_s> </irc> :-)



Mime
View raw message