Not very many people on today. We discussed two things...
- Including JIRA numbers in future Java SCA releases - Some clarifications on the SCA 0.90 release candidate Also, note the final closing remark from Ant. Please vote on the Java SCA 0.90 release candidate before Wednesday. Simon <kgoodson> hi, anyone got anything for the IRC chat slot? <ant_> i guess not, a lot of people aren't here <slaws> a quick question... <slaws> we don't to date note what JIRA fixes are included in releases. should we in the future? <ant_> i think it certainly doesn't hurt, other projects do that. for this release i didn't think it made so much sense as it was such a big rewrite. Does mean we need to use JIRA a bit better though <slaws> i think we should be a bit more organized with out JIRA useage <slaws> out -> our <kgoodson> i spent a lot of time putting old JIRAs right with regards to their fix version i for SDO in order to make this work <slaws> do you include a list in the release for SDO? <kgoodson> yes, and I also included a "permalink" for a query in my rleeease notes <kgoodson> but tham may have been a mistake <kgoodson> becuase people have closed off jiras since the release candidate was cut, using the beta1 as a fix version <kgoodson> so I have had to modify a couple of those in order that the permalink remains in step with the release <slaws> mmm - not sure about including the query link but good thought about getting the fix versions straight <slaws> so I'll raise this on the list and we can debate what the right course of action is <lresende> i have a question around samples in the distribution <lresende> all standalone samples should work by just doing a ant run ? <lresende> does this include the helloworld-ws-reference ? <slaws> in the sca distribution - if I remember correctly - the ws-reference sample relies on you doing an ant run in the ws-service sample also <slaws> the README describes what you need to do for each sample as it does vary <slaws> another example is samples that use a web app - you need to copy this manually to your container <lresende> k, i missed the server part of the sample <lresende> for the web it's fine :) <slaws> ok - good (for web app) - maybe there is a bug in the README <slaws> for the ws samples <lresende> also, maybe we could catch the exception on the client app, and display a better message saying we could not connect, and ask the user to verify if the server is up ... but not for the release <slaws> yes - good idea - can you register a bug for this so it doesn't get forgotten <lresende> yes... <lresende> also, TUSCANY-1294, does that affect the release ? <ant_> i don't think its a blocker, is it? i'm assuming all that happens is you get a warning in environments that validate this? <slaws> doesn;t look like a blocker for the environments that we test with, i.e. Tomcat. Did it cause failure on Geronimo? <lresende> no <lresende> unless Geronimo has any explicity way to turn validations <ant_> (also with reference to the early topic, noticing i've closed that jira fixed but with a blank fix release... :) ) <lresende> i was running with plain vanilla geronimo M5 and it worked fine <ant_> i guess that should be java-sca-next and then moved to whatever the next release is when its done <slaws> i've done it too ant :-( yeah - if we go forjava-sca-next then we can move to the final release designation <kgoodson> yes, that's what the *Mx releases have been used for in the past, but they are not very self explanatory, and now that we have moved away from milestone release naming they are even less clear <kgoodson> so I think a *next is a good name for the holding place for jira target/fix level values <ant_> sounds good to me# -->| Venkat ([EMAIL PROTECTED]) has joined #tuscany <slaws> ok - so that seems to be it for the chat today - i'll post these few notes <ant_> ...and if everyone could find some time to review and vote on the 0.90 rc before wednesday...
