Tuscany IRC weekly chats. Feb 5 2007

[Rick Rineholt <cr...@gmail.com>]

[11:38] <cr22rc> is there something general to talk about?
[11:39] <rfeng> venkat might have a few questions about how to run 
samples with pre-spec or trunk kernel
[11:40] <cr22rc> I'm not sure either ... still really fuzzy. I appended 
some questions on the ML but I don't think I got replies
[11:40] * jsdelfino has joined #tuscany
[11:41] <lresende> i sent a link with some steps that might be usefull 
for venkat
[11:41] <lresende> not sure if it need to be updated to reflect pre-spec 
trunk branch
[11:42] <rfeng> AFAIK, the trunk kernel is not fully ready yet to run 
samples
[11:42] <cr22rc> am I correct that the itests, samples use only pre-spec ?
[11:43] <rfeng> I assume so
[11:43] * Venkat has joined #tuscany
[11:43] <Venkat> Hi...
[11:43] <cr22rc> so the plan is to continue to drive functionality in 
snapshot to pre-spec
[11:44] <rfeng> I'm not sure if I understand your point
[11:45] <cr22rc> you work on snap-shot kernel when something is stable 
you update the pre-spec branch and republish ?
[11:45] <jsdelfino> hi, not sure what you guys are discussing now, but 
I'd like to add a question to the queue: what can we test with itest at 
the moment?
[11:46] <cr22rc> pre-spec branch AFAIK
[11:47] <rfeng> yes, the itest suite has test cases to cover SCA spec 
API, property, callback & conversation, ws binding and a few other things
[11:47] <jsdelfino> are all the test passing?
[11:47] <rfeng> no
[11:47] <cr22rc> YMMV :-)
[11:47] <jsdelfino> that was my question :) what is passing? what is not 
passing?
[11:48] <rfeng> A few spec tests were failing
[11:48] <cr22rc> Personally, I need to be able to work on Itest for the 
business excepton ... I'll only figure out what I need to do by driving 
an example.
[11:48] <cr22rc> at least the details of what needs to be done
[11:48] <Venkat> cr22rc... isn't the itest stuff using the spec 0.95
[11:49] <cr22rc> think so
[11:49] <rfeng> ATM, yes
[11:49] <Venkat> I am eager to know about running samples and debugging 
them out the current kernel in the Trunk
[11:49] * meerajk has joined #tuscany
[11:50] <rfeng> I'm not sure if the kernel in trunk is ready for running 
samples
[11:50] <rfeng> I didn't try
[11:50] <Venkat> then can somebody help with an alternative...
[11:50] <Venkat> in the earlier case with SCATestcase...
[11:51] <Venkat> i used find it very convenient to walk thro the kernel 
and figure out things..
[11:51] <Venkat> debugging from Eclipse..
[11:51] * halehM has joined #tuscany
[11:51] <Venkat> now am really struggling to move on...
[11:52] <jsdelfino> venkat are you working with the trunk? or the 
pre-spec branch?
[11:52] <Venkat> Trunk...
[11:53] <jsdelfino> would it make sense to have a version of itest 
driving tests with the trunk instead of the pre-spec branch?
[11:53] <cr22rc> I guess but then what the value of iTest in pre-spec .. 
who is really using it ?
[11:54] <rfeng> +1, but maybe wait a bit until the kernel gets stable
[11:54] <rfeng> cr22rc, we should add them to a daily build :-)
[11:55] <jsdelfino> could we copy the itest stuff depending on the 
pre-spec branch to pre-spec, and change itest in trunk to depend on the 
kernel from trunk? like raymond is doing for the databinding?
[11:56] * Amita has joined #tuscany
[11:57] <jsdelfino> so this way, people who want to work on the pre-spec 
level can continue to do it, people who want to work with the trunk have 
an itest environment to work with
[11:57] <rfeng> +1
[11:57] <Venkat> +1
[11:57] <murphdg> I was just playing with a similar thought / issue 
around building and testing in eclipse.... but I got stuck on how to 
build myself an installable version - since as I understand it, you can 
no longer be assured that sca will build cleanly... any thoughts, or 
have I misunderstood ?
[11:58] <cr22rc> we can do this ... but not sure if this is what Jeremy 
was thinking ... my understanding was the kernel incubator-snapshot 
would not be made to stay working.
[11:59] <cr22rc> just to be clear not opposing ... just point that out
[11:59] <jsdelfino> cr22rc, you said you're working on exception 
handling right?
[11:59] <cr22rc> yes trying to ... starting to write a testcase to help me
[11:59] <cr22rc> I know where you're going. :-)
[12:00] <jsdelfino> ok, do you want to do this work in the trunk? I'm 
assuming yes...
[12:00] <cr22rc> yes
[12:01] <jsdelfino> so I guess you'll need to coordinate with the other 
people working on the trunk, unit test cases working with the trunk, and 
I think that it'll be helpful to have itest working with the trunk as 
well, to test your exception handling end to end between two pojos wired 
together and a client for example
[12:02] <cr22rc> but I'm *just* pointing out a catch... the expectation 
from jeremy and jim I understood was that they could check something in 
at that kernel that *could* break things for a while.  
[12:02] <cr22rc> i.e. the trunk is unstable
[12:03] <rfeng> I guess that's fine but we need to have the itest in 
place for the trunk to really understand how broken it is
[12:03] <jsdelfino> ah, then I guess we need to find out from them how 
long it's going to be broken
[12:03] <cr22rc> sure it sounds like a good idea. As *I* said, I'm not 
opposed.
[12:04] <rfeng> and work toward fixing all the problems to get all the 
test cases pass again
[12:04] <jsdelfino> rfeng, +1 that's what I thought as well, itest will 
help us understand what's ok vs what's broken
[12:04] <cr22rc> I would be prefer the trunk to be never broken for more 
than a few days max ...
[12:05] <cr22rc> But, if that is the case and we strive for that .. why 
the complexity of having the other branch? :-)
[12:05] <jsdelfino> me too
[12:06] <rfeng> what are the major thinbgs broken so far, the java C&I 
API changes?
[12:06] <Venkat> rfeng, when you say broken.. do you mean build broken ?
[12:07] <Venkat> because I have been able to compile the kernel and the 
spec r1.0
[12:07] <rfeng> no, I mean functions
[12:07] <Venkat> but the question is 'what next'
[12:07] <jsdelfino> the pre-spec branch is for people who want to build 
extensions without having to worry about a changing trunk, at least 
that's one of the goals, if I understand correctly
[12:07] * YangZHONG has joined #tuscany
[12:07] <rfeng> yes
[12:08] <rfeng> The trunk kernel will have breaking changes (they will 
break downwstream extensions, but not the kernel itself :-)
[12:09] <jsdelfino> the latest kernel builds for me as well
[12:09] <jsdelfino> as of yesterday
[12:09] <rfeng> yes, the build is fine
[12:09] <Venkat> I guess its a question of the runtime now...
[12:09] <cr22rc> ok I think I need the axisbinding ... will that be 
broken on the trunk?
[12:09] <Venkat> if there was runtime that I could run a sample over.. 
then we could test if the kernel is having the functions
[12:10] <rfeng> We need to migrate a few samples over the latest Java 
C&I APIs if you want to test
[12:11] <jsdelfino> what about the standalone runtime? I didn't try to 
build it with the latest kernel, but it shouldn't be too difficult to 
port it if needed
[12:11] * simonnash has joined #Tuscany
[12:11] <murphdg> With this in mind, do the instructions at 
http://incubator.apache.org/tuscany/java_sca_overview.html need to be 
updated.. 'cos if I follow Checking out and building the source step I 
don't end up with a "distribution" diretory - well not currently
[12:12] <rfeng> To me the standalone runtime should be part of the new 
kernel efforts
[12:12] <jsdelfino> murphdg, yes they do, but maybe you can wait for the 
whole trunk to stabilize before doing it, unless you want to do it 
several times :)
[12:13] <rfeng> we should be able to run something in a runtime 
(standalone) beyond the unit tests w/ the kernel in trunk
[12:13] <murphdg> thanks jsdelfino... but what do you mean by yes they 
do (the instructions need updating ?)
[12:13] <jsdelfino> rfeng, yes
[12:14] <jsdelfino> murphdg, yes, I was just answering your question :)
[12:14] <lresende> r we going to get rid of the standalone distributions 
? or they are just obsolete now and will be back sometime soon ?
[12:14] <Venkat> lresende, my understand is that they are out...
[12:14] <rfeng> ?
[12:14] <Venkat> now its all the runtime
[12:15] <murphdg> so... how do I build a distribution now ?
[12:15] <lresende> so, like, they are not even going to be back as for M3 ?
[12:15] <lresende> yes, same question, what is going to be the 
"standalone distribution"
[12:15] <rfeng> but we still have the standalone runtime, right?
[12:15] <Venkat> right... in standalone assembly...
[12:16] <rfeng> ok, that's fine then
[12:16] <lresende> so, the standalone assembly is going to become the 
new "standalone distribution" ?
[12:16] <murphdg> Venkat - do you mean java/sca/runtime/standalone ?
[12:16] <jsdelfino> cr22rc, why do you need the axis binding? I'm afraid 
it's not going to work with the kernel trunk
[12:17] <Venkat> yes murphdg, that's my guess from the way it looks...
[12:17] <rfeng> I think cr22rc wanted to test the path of WS faults handling
[12:17] <cr22rc> working with raymond we really need to test the full 
business exception scenario
[12:17] <cr22rc> yes
[12:17] <rfeng> cr22rc, it could be incremental
[12:18] <cr22rc> AFAIK that's the only way to get an exception through 
the databinding ... right ?
[12:18] <rfeng> why?
[12:18] <cr22rc> right now the databinding just get's optimized away
[12:19] <rfeng> no, you can have two components talking over a remotable 
interface
[12:19] <rfeng> then the databinding will be in action :-)
[12:19] <cr22rc> I think the real issue for example JAX-B binding wired 
to SDO and then an exception
[12:19] <rfeng> look at the echo.databinding example
[12:19] <jsdelfino> rfeng, +1 it should be possible to stage the 
exception handling work, and integrate the databinding aspect when 
you're done with the databinding work, and integrate with axiom when the 
axis binding is back up
[12:20] <cr22rc> can I have two diferent databindings ?
[12:20] <rfeng> yes,
[12:20] <jsdelfino> cr22rc, yeah you could test jax-b / sdo, you 
probably don't need axiom in the middle
[12:20] <rfeng> for now, you can have the SDO on the source and JAXB on 
the target
[12:20] <cr22rc> ok ... lets discuss later
[12:20] <rfeng> sure
[12:21] <cr22rc> I did ask before ... and I understood your answer was 
it need to be through ws
[12:21] * kgoodson_ has joined #Tuscany
[12:21] <cr22rc> but ok
[12:21] <Venkat> Hi meerajk, if you are around, could you please help us 
with some info on the state of the runtimes ?
[12:21] <rfeng> sorry for the confusion, but the ws scenario will be 
supported utilmately
[12:22] <murphdg> (thx folks.. got to dash to karate... ttfn)
[12:23] * murphdg has quit IRC (Remote closed the connection)
[12:24] <Venkat> so.. can we do a check point on how we will go forward 
with itest and the trunk?
[12:24] * kgoodson has quit IRC (Read error: 104 (Connection reset by 
peer))
[12:25] <Venkat> just trying to understand if we have decided on 
something in that
[12:25] * kgoodson_ has quit IRC (Read error: 104 (Connection reset by 
peer))
[12:25] <rfeng> I suggest that we copy the current itest to the 
pre-spec-changes and then migrate the one in trunk to use the latest kernel
[12:26] <rfeng> as the 1st step
[12:27] <cr22rc> need to put this I think on the ML
[12:28] <jsdelfino> yes
[12:28] <jsdelfino> and also ask on the ML the timing for getting a 
workable trunk
[12:29] <rfeng> ok
[12:29] <jsdelfino> or if there is going to be much more big refactoring 
in the kernel in the next few days
[12:30] <cr22rc> I *assume* the databinding as sort of an extension does 
not fall with the other extension that are only stable in the pre-spec 
branch ?
[12:32] <rfeng> The databinding pieces are fairly independent. I plan to 
evolve them with the latest kernel as we go.
[12:32] <jsdelfino> ok, sounds good
[12:36] <cr22rc> sounds like we're done?

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org