You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsif-dev@ws.apache.org by Nirmal Mukhi <nm...@us.ibm.com> on 2003/01/30 17:52:14 UTC
[wsif] IRC chat log
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> :-)