<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