Tuscany Weekly IRC chat log - April 09 2007

[Luciano Resende <lu...@gmail.com>]

<rfeng> hi
<Venkat> Hi Raymond...
<lresende> hi all
<Venkat> oh .. hi luciano..
* jsdelfino has joined #tuscany
<jsdelfino> hi all
<Venkat> Hi..
<Venkat> I guess its holiday in the UK and may not be able to see Ant
<Venkat> or Simon Nash for that matter
<jsdelfino> yes, simon laws is probably on vacation as well
<lresende> i think we can start, any specific topics people want to discuss
?
<jsdelfino> what about the build? are you guys happy with the new build
structure?
<rfeng> one minor thing, we dump out the models in some of the test cases
<Venkat> I am happy with the modularization overall... and haven't had
problems with the build
<Venkat> yes.. I observed that
<lresende> also, should we also update the java/pom.xml to reflect the
changes on the sca build
<jsdelfino> yes, I can fix this problem with the test cases if u want
<jsdelfino> lresende, yes, good point
<lresende> and the question would be, in java/pom.xml, should we have 3
profiles only, or 4, being one the "complete bild" and witch one would be
the default ?
<jsdelfino> we currently have 4 right?
<jsdelfino> and the default one builds everything
<lresende> default was building nothing
<Venkat> I guess the current setup is ok... isn't it
<lresende> k, i can fix the java/pom.xml then
<jsdelfino> yes it looks ok to me, except that the default profile needs to
be fixed to not build sampleapps, samples, and distribution, which are
broken I guess
<Venkat> and whats the approach to samples...  do we have samples inside
each module or do we have them all in 'samples'
<Venkat> and hope we will simply do away with 'sampleapps'
<jsdelfino> all in sca/samples
<Venkat> and just have one thing - 'samples'
<Venkat> ok
<Venkat> that sounds fine by me.
<jsdelfino> I copied all the samples that were in good enough shape to
sca/samples, although they need work and are not building yet
<jsdelfino> under java/sampleapps, we still have a das.pojo.service sample,
shouldn't this one go under das/samples?
<lresende> i can move that one...
<jsdelfino> what does this sample do?
<jsdelfino> ok
<lresende> it's a das component that expose a das service and a client that
consumes it
<jsdelfino> ah ok
<jsdelfino> btw I had sent an email to the dev-list indicating that I was
going to remove the duplicate/old copies of the modules that are now
integrated in the top-down build, and move the others to contrib, sometime
later today
<jsdelfino> is that going to break anything?
<rfeng> sounds good to keep them in contrib, we might want to copy some code
from these modules over time
<jsdelfino> yes
<lresende> does it make sense to maybe create a branch, and leave things on
the branch... this way we keep a clean trunk ?
<lresende> something like a backup branch
<lresende> or contrib branch
<jsdelfino> are there any modules under the trunk that should be moved to
sca/modules instead of contrib because some of you are planning to work on
them soon?
* halehM has joined #tuscany
<lresende> i'll move the contribution-installer
<Venkat> yes.. I think a branch would seem better because things under
contrib are stuffs that we plan to evolve into the main stream.. isnt it
<Venkat> whereas this is something we want to archive and use in future for
reference or copying over some reusable parts
<lresende> we could use an old revision to create the branch
<halehM> hi. I just came into this conversation now. Why do we need to
branch?!
<lresende> we were just discussing if we should keep a contrib directory, or
create a contrib branch where the contrib modules will reside
<lresende> a contrib branch would make the trunk code cleaner
<jsdelfino> why couldn't this contrib work be done in the trunk? if we want
to evolve them in the main stream at some point?
<jsdelfino> so I guess the question is:
<jsdelfino> - java/sca/contrib
<jsdelfino> or
<jsdelfino> - branches/contrib/java/sca?
<Venkat> java/sca/contrib
<rfeng> I prefer to leave them in the trunk to avoid confusions
<halehM> +1 rfeng
<jsdelfino> I'm afraid that if we move these contrib modules to a branch
then we're going to forget them there, people won't go to a branch to find
them
<lresende> k, good point
<jsdelfino> so +1 from me for java/sca/contrib as well
<lresende> +1
<jsdelfino> so, any other modules that should be moved to java/sca/modules
instead of java/sca/contrib before I do the cleanup?
<Venkat> nothing that I can think of
<jsdelfino> ok, I'll do the cleanup sometime this afternoon or evening then
<jsdelfino> Venkat, on another subject, I just responded to your questions
about artifactProcessors and resolvers on the dev list
<Venkat> I shall look that up... but then I have been able to follow quite a
bit by debugging from SCARuntimeTestCase (thanks to Luciano)
<jsdelfino> cool, if we are done for now with the build discussion, are
there any other topics? any questions around artifact processors, resolvers,
or our new extensibility story?
<Venkat> yes... :)
<Venkat> from the SCARuntimeTestcase I understood that 'implementation
extension processor' was registered thro an activator..
<Venkat> I am trying to understand how we will get to do this from say the
assembly-xml...
<Venkat> is it ok to add a dependency on interface-java-xml or
implementation-java-xml
<jsdelfino> no :)
<Venkat> hmm.. thought as much :)... so this will be strung up by the
runtime only .. right
<jsdelfino> assembly-xml is generic, we may end up with many other
interface-*-xml or implementation-*-xml, we can't depend on all o fthem,
otherwise it's not extensible
<Venkat> yes thats right...
<jsdelfino> well, I guess we can have two different use cases:
<jsdelfino> a) we bring up an SCA runtime and need a way to find and
activate runtime extensions
<jsdelfino> b) somebody uses our metadata layer (which we called scdl4j) and
needs to use some metadata extensions (to load the corresponding scdl
extensions)
<jsdelfino> for (a) we have runtime module activators, they are found by the
runtime, and responsible for registering all extensions that they
contribute, runtime extensions and the underlying metadata extensions
<jsdelfino> this is what raymond did with the crud extension in the sca
runtime test case
<Venkat> yes.. I figured that out
<jsdelfino> for (b) there are no runtime module activators, so you decide in
your code which metadata extensions you want to use, and you populate the
ArtifactProcessorRegistry with these extensions yourself
<jsdelfino> on one hand, for (b) we don't provide an automatic discovery
mechanism for you - bad :), on the other hand we don't impose an automatic
discovery mechanism that would get in the way of what you may want to do -
good :)
<jsdelfino> it's very similar to what WSDL4J is doing, they have a registry,
you populate it yourself with the extensions you want, they also have a
PopulatedExtensionRegistry containing the most common extensions, we could
do that too maybe...
<Venkat> so in assembly-xml the ReadAllTestCase does not use any of the
extension processors... if I wished to include that as well.. then I guess
the best place to do that would be in an iTest .. right
<jsdelfino> yes
<Venkat> ok.
<Venkat> another question...
<jsdelfino> or java-implementation-xml if you wanted to test this one
<Venkat> right..
<jsdelfino> for assembly-xml, you can probably come up with a fake test
implementation type if you want to test the loading of implementations
<Venkat> yes.. I understand.. like what Raymond has done.. right
<jsdelfino> yes
<Venkat> the other question is...
<Venkat> in the CompositeUtil.init... I observe that when there is
componentType service that is not defined in the component... you add it to
a list of 'problems'... mustn't it be that we create a componentservice
around this componentType service...
<Venkat> the same with references as well...
<Venkat> shall I go an change them... i.e. if there is comp. service and no
corresponding compType service then throw expection...
<jsdelfino> let me check what I did :)
<Venkat> (jsdelfino.. I don't mean to pick on these.. am only trying to
understand if there is a different understanding)
<jsdelfino> sure, let me paste the code in question...
<jsdelfino> is that it: http://rafb.net/p/gZjrWI44.html
<Venkat> yes.. thats right
<jsdelfino> so if this is the code that we're talking about, I'm adding to a
list of "problems" the component services and component references that are
declared on a component, if there was no corresponding service or reference
defined on the component's componentType
* bertlamb_ has quit IRC ("Trillian (http://www.ceruleanstudios.com")
<jsdelfino> because this is an error, the componentType is a description of
the component's implementation, and it's an error to declare a service on
the component, which is not implemented
<jsdelfino> does that make sense?
<Venkat> right...
<Venkat> so what do we do with the 'problems'... should there be some
exception thrown at the end...
<jsdelfino> now w.r.t the problems list, I thought it would be a good idea
to gather all the problems of that kind first
<jsdelfino> and defer the decision to throw an exception, or continue with
warnings, to a later point
<jsdelfino> if we throw an exception right away then:
<jsdelfino> - we can't run an even slightly broken app, and this is really
not convenient at development/debug time, because you can't run a slightly
broken app, you can't debug it, so you can never fix its problems...
<Venkat> yes.. I am fine with consolidating problems and then summarizing
them... especially now that we are doing this in well defined phases...
<jsdelfino> - also we can't gather all the problems, it's like if a compiler
would always just give you the first error and stop, instead of giving you
the complete list
<Venkat> so maybe we return the problems list to the caller and let it deal
with it ?
<jsdelfino> so the idea is (1) gather the problems first, (2) decide how to
handle them, but later, probably in the runtime layer instead of here
<jsdelfino> yep
<jsdelfino> the method takes a list of problems we just add to it
<jsdelfino> at some point, we may want to make the problem descriptions
richer, like with:
<jsdelfino> - a description of the problem
<jsdelfino> - the model object that caused the problem
<jsdelfino> - a severity
<jsdelfino> - suggestions on how to fix it
<Venkat> yes.. sounds perfect..
<jsdelfino> :) maybe this is going overboard, I guess we don't need all of
that now :)
<jsdelfino> but at least we have the structure in place if somebody wants to
do all that
<Venkat> yes.. for now we can simply list the names of the artifacts that
had problems.. and it should be easy to look up the composites for them...
<jsdelfino> I think this can help consumability of our runtime, in the long
run
<Venkat> right but the problm is that if there is no list passed to the
method then it creates the list... and that will not be avialble to the
caller down the stack
<Venkat> we should prob. make the method return 'problems'
<jsdelfino> if the caller didn't pass a list, then that's because he was not
interested in the list
<Venkat> oh I see... thats another view point :)
<jsdelfino> and returning problems will force us to add lists to lists and
copy problems around as soon as we start nesting these utils...
<jsdelfino> actually... this list of problems should probably be on the
ArtifactProcessor.resolve() and wire() methods...
<Venkat> and then we move all of what is in composite util to wire
method....
<Venkat> I think you had already mentioned this on the ML
<Venkat> ok.. I am done for now... :)...
<Venkat> thanks for all the patience
<jsdelfino> yes, we could do that, or leave it in assembly to allow people
who want to use assembly without assembly-xml to still benefit from the
logic in CompositeUtil, I don't have any strong opinions in favor of one or
the other
<jsdelfino> no pb, trying to explain this actually helps me understand it
better as well... :)
<Venkat> ok
<Venkat> :)
<Venkat> ok... anything else for discussions... sorry folks I stole all the
time...
<jsdelfino> nothing else from me, but I'm happy to stay on the chat
<jsdelfino> rfeng, I have a question for you
<jsdelfino> is the introspection of Java interfaces already connected with
the JavaInterfaceProcessor? and if not, how is the introspection triggered?
* Venkat has quit IRC (Read error: 110 (Connection timed out))

-- 
Luciano Resende
http://people.apache.org/~lresende