[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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
