Here's the chat log from yesterdays weekly chat. The only topic talked about was the up coming release.
...ant [11:33] <ant_> hey. Are we chatting today? [11:34] <ant_> How about talking about the release? [11:34] <jsdelfino> sounds good [11:35] <ant_> Any comments or additions or deletions to whats on the wiki: [11:35] <ant_> http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Next+Release+Contents [11:36] <jsdelfino> well I guess we're going to have to add to your "already in the trunk and will be included in the release section" [11:38] <ant_> I guess thyat section could really be moved to the RELEASE_NOTES file in SVN and the wiki page just be used to track the outstanding work [11:39] <jsdelfino> yes [11:40] <ant_> everyone feel free to use CTR to update the RELEASE_NOTES as you see fit :) [11:40] <kgoodson> CTR? [11:40] <ant_> which fyi is here: https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/distribution/src/main/release/ [11:41] <ant_> Commit-Then-Review [11:41] <ant_> As opposed to Review-then-commit - just go ahead and updated it [11:42] <ant_> How about we go through each item on the wiki page and see if we need to get it done? IN/OUT etc? [11:43] <jsdelfino> good idea [11:43] <ant_> There's already been a lot done on "tidy up runtime after all the recent rewrite/refactors" already committed right? [11:43] <ant_> Composite component wiring and promotion hierarchy? [11:44] <jsdelfino> I think this one is important, and I'm working on it... [11:44] <ant_> ok [11:44] <ant_> Package/Class naming consistency across modules [11:45] <jsdelfino> at least for the spis? [11:45] <ant_> I asked on the ML about changing the package name from org.apache.tuscany to org.apache.tuscany.sca, should we do that? [11:45] <jsdelfino> also you proposed to name o.a.t.sca, which sounds good to me [11:46] <halehM> what would be the benefit of doing this now rather than later (besides the SPIs) [11:46] <jsdelfino> I think we should do it at least for the spis [11:46] <ant_> i agree for the SPI's [11:46] <slaws> make sense - how big a job is it for SPIs? [11:47] <ant_> if its just the core-spi module not so big [11:47] <halehM> how do you distinguish between tuscany SCA for Java or C++? [11:48] <Venkat> org.apache.tuscany.sca is good ... and lets just stick to SPIs for now.. just apprehensive about a complete overhaul at this stage [11:48] <jsdelfino> +1 [11:48] <ant_> Venkat, +1. It does seem like quite a lot of work. maybe people can do individual modules over time [11:49] <ant_> halehM, i'm not sure we need to as people would usually keep them completly seperate [11:50] <halehM> how will these package name changes impact users? If it is not major, or none, it makes sense to do it over time [11:50] <ant_> does anyone want to volunteer to rename the core-spi package? [11:50] <Venkat> I can [11:51] <ant_> the uses should only be using the API and SPI, so if we get that right now then what happens with the rest of the modules should be transparrent [11:51] <ant_> thanks Venkat [11:51] <ant_> Was there anything else as part of "Package/Class naming consistency across modules"? [11:51] <jsdelfino> thanks, we'll need to coordinate to make sure that nobody has pending changes when you refactor, to avoid a merge nightmare [11:52] <Venkat> ok... I'll take care... I prob. have a timezone advantage... ;-) [11:52] <ant_> ok, what about "Package dependencies"? [11:52] <jsdelfino> yeah, maybe send an email to the list some time before you do it, to give people a change to svn commit everything they have [11:53] <Venkat> sure... [11:54] <jsdelfino> package dependencies have been mostly cleaned up by the modularization work we did the last few weeks, but I think we need a little more cleanup of the core runtime and java impl this week [11:55] <ant_> and "Setting data bindings on interfaces" and "Type scoping and contexts"? (i'm not sure where this list of runtime work came from) [11:56] <jsdelfino> not sure either, rfeng can probably give us more background on "setting data bindings on interfaces" [11:56] <slaws> Looks like it was from topics that have been on the ML [11:56] <jsdelfino> I think that the type scoping and contexts is related to the discussion about the SDO ContextHelper discussion [11:57] <ant_> ok lets skip these for now, and also skip over the "define a clear set of runtime and extension APIs" [11:57] <ant_> what about "logging stratergy" and "report major errors"? If we don't do anything more here could we go with whats here today? [11:57] <jsdelfino> Frank had proposed something on the ML to resolve the SDO context issue, but it probably can't make that release as it would require another release of SDO [11:58] <jsdelfino> logging strategy, yes, specially if we use aspectj to add logging externally [11:58] <jsdelfino> report major errors, I'd say we can't release what we have now [11:59] <rfeng> hi [11:59] <ant_> ok, do we have volunteers working to improve this then? [11:59] <jsdelfino> we need to report major errors in SCA assemblies in a meaningful way [11:59] <slaws> agreed - this started specifically from the lack of reporting of missing extensions [11:59] <jsdelfino> I volunteer to improve the error reporting in the assembly model, in particular compositeutil [11:59] <halehM> the discussion on mailing list seemed to mix logging with monitoring. Are you talking about logging here? [12:00] <jsdelfino> but would need help on contribution and the core runtime [12:01] <ant_> i think this was specifcally about logging. monitoring i think we can leave for now? [12:01] <jsdelfino> logging, we have 2 proposals, use slf4j directly, or use aspectj [12:01] <jsdelfino> or a combination of the two, that would be a 3rd proposal [12:01] <ant_> when you said "if we use aspectj to add logging externally" are you suggesting getting an aspect going to include in the release? [12:02] <jsdelfino> not sure, as a starting point, I'm suggesting documenting how to weave logging in using aspectj in our wiki [12:03] <jsdelfino> so, we don't have to package it in our release, it's external [12:03] <slaws> there was argument against using aspectJ on the ML so would not commit to it for release [12:03] <jsdelfino> right, that's... external [12:03] <rfeng> jsdefino, good point [12:03] <ant_> cool ok, that sounds good to me as its as good as to ignore for the release then :) [12:03] <jsdelfino> yes :) [12:03] <rfeng> for this release, we could document how to use apsects for L&T in Tuscany [12:04] <ant_> right [12:04] <ant_> "manage lifecycle" [12:04] <ant_> ? [12:04] <slaws> but there are still some specific errors we need to test for somehow [12:04] <jsdelfino> it wouldn't even have to be in the release package, just on the wiki [12:04] <ant_> slaws, what do you mean? [12:04] <slaws> that make tuscany difficult to use if they are not reported [12:05] <slaws> my specific example was if you don;t have the right extensions on the classpath [12:05] <rfeng> meaningful exception? [12:05] <ant_> ok, but i assumed those are the type of things that jsdelfino said he was workingon now? [12:05] <slaws> ah - ok - that's fine [12:05] <jsdelfino> +1, like I said earlier, we can't release without improving the error reporting for major errors [12:05] <jsdelfino> yes [12:05] <slaws> sorry [12:06] <ant_> (and asking for help in a few places ... :) ) [12:06] <jsdelfino> exactly, contribution service and the core runtime [12:06] <slaws> yes - saw that but though you had moved one to defering it [12:06] <ant_> so the "manage lifecycle" item? I think that was from the problems with the axis2 binding which all seem to be fixed now? [12:07] <jsdelfino> this is related to the spis I think [12:07] <jsdelfino> implementation and binding extensions should be able to implement start/stop methods [12:07] <jsdelfino> and we should call them [12:08] <jsdelfino> the axis2 binding could stay as-is for now, or implement that spi, but it's not really necessary at this point [12:08] <jsdelfino> as it works [12:08] <rfeng> yes, I asked for review for the interfaces [12:08] <ant_> ok, lets leave this to the SPI item discussion then [12:09] <rfeng> back to the setting data bindings on interfaces and scope [12:09] <ant_> ok? [12:09] <lresende> jsdelfino: i can help on the contribution [12:10] <rfeng> we mostly introspect the data type, but in some cases, we need to know the default databinding for the interface/operation [12:10] <rfeng> it's achieved using the @DataBinding annotation [12:10] <rfeng> and the SDO type scoping is not fully flushed out yet [12:11] <jsdelfino> is this annotation going to disappear later? [12:11] <jsdelfino> if/when SDO provides enough metadata in their generated code? [12:12] <rfeng> I'm not quite sure at this moment, to deal with Java-WSDL correctly, we need to know the databinding for the java interface in some cases [12:12] <ant_> is there more development of either of those that needs to be done before we can release? (assuming doc can happen during/after the RCs) [12:13] <rfeng> ant_, is it a general question? [12:13] <lresende> jsdelfino: do you have specific scenarios for error reporting on the contribution service ? [12:13] <ant_> rfeng, i meant specifically for the SDO scoping or databinding annotation stuff [12:14] <ant_> is there work that *must* be done there before we can cut a release? [12:14] <rfeng> ok, I was thinking of using the contribution service to introspect SDOs to remove the need of import.sdo [12:15] <ant_> that sounds useful [12:15] <slaws> how difficult is that - as that would be really good to get in [12:15] <jsdelfino> ah I think that one is important, as we probably don't want to expose an import.sdo extension in this release and remove it just afterwards... this affects the application programming model [12:15] <ant_> ok, i'll add that to the wiki list then [12:16] <ant_> "Tomcat and Jetty http"? I guess they are both there and work, is there more to do other than doc? do we need samples that show using either? [12:16] <rfeng> now that the spi is passing in the artifact URI and we can derive the class name from it [12:18] <ant_> I'll take silence as no more work for http :) [12:18] <ant_> "work on a Domain concept"? Thats looking like next release to me? [12:19] <jsdelfino> tomcat and jetty, I think there's just one thing [12:19] <lresende> there has been some discussion on http applications, not sure if we would need a maven war plugin to help building the client war with necessary dependencies to start tuscany and consume a service for example... [12:19] <jsdelfino> decide which port to start an http connector on when a servlet is added to the server, just a minor change [12:20] <ant_> lresende, right, and thats also related to the next two item on the wiki list [12:20] <lresende> if RC is this week, Domain will be over the fence... might not be ready... [12:21] <ant_> jsdelfino, ok, there's also a hardcoded base URL in the axis2 binding that i doidn't know what to do with [12:21] <jsdelfino> yes, some of it may be there in the code, but I wouldn't recommend exposing/documenting any of it, since it won't be mature enough [12:22] <slaws> ant_ where does this runtime configuration type of info come from? [12:22] <jsdelfino> ok, we'll have to look at both your URL issue and the selection of the http port then [12:22] <jsdelfino> runtime configuration type of info? are you talking about urls and ports? [12:23] <slaws> ok - y - sounds like need to decide [12:23] <jsdelfino> I'd say a combination of the binding URI and the component URI [12:23] <ant_> in theory you can do something like <binding.ws uri=" http://foo.com:9876/myService"; /> [12:24] <slaws> maybe a bit strange that it's in the SCDL but one for the list [12:24] <ant_> so what about "better integration with App Servers" and "web app support including tomcat deep integration"? [12:24] <jsdelfino> yes, that's what I had in mind, when the binding registers a servlet, we should get the 9876 and starts the http connector on that port [12:25] <ant_> jsdelfino, +1 [12:25] <lresende> we should have more discussions on what "better integration with App Servers" really means [12:25] <ant_> do we need at least a sample that uses the maven war plugin to build a webapp sample? [12:25] <lresende> there seems to be different views and requirements on this area [12:26] <jsdelfino> I'd say we need to understand the requirements first [12:26] <lresende> i really think we should have a maven war plugin and a webapp sample [12:26] <lresende> basically on the side of a client app [12:26] <jsdelfino> first understand why we need a WAR file [12:26] <jsdelfino> to run an SCA client? to expose a a component as a web service? to run a JSP inside a composite? [12:26] <lresende> war file is the way you build j2ee applications, right ? if you want to build web apps that consume tuscany components, what's the other options ? [12:27] <ant_> so this sounds like it needs more discussion on the list then. lets leave it for from here now as we're running out of time [12:27] <lresende> ant_ +1 [12:27] <ant_> Next is "Java components" i guess thats going but will need some updates fro the new SPIs [12:28] <jsdelfino> yes I'd suggest we continue the already started discussion on the list [12:28] <ant_> same with script components and axis2 binding [12:28] <jsdelfino> yes [12:29] <ant_> "what samples?" are we more or less happy with the current samples? [12:30] <slaws> well web app samples have just been mentioned so that should go on the possibles list [12:30] <jsdelfino> we can probably exclude the conversational samples [12:30] <jsdelfino> and, yes, include a web app sample [12:30] <lresende> if we get a webapp story going, i think we need a simple webapp, maybe a webCalculator... and i'd like to finish the client side of the das-service sample, that needs the war plugin [12:31] <ant_> and I'd like to a sample using at least one of the script languages [12:31] <jsdelfino> lresende, you keep talking about a war plugin... I don't think we need a Tuscany war plugin until we decide what an SCA app in a war looks like, and even before that until we understand what we want the war for :) [12:32] <lresende> jsdelfino: k, we can have the discussion on the list... to get a better understanding.. [12:33] <ant_> just using the maven war plugin and bundling up the tuscany jars in th ewar lib directory should work fine anyway right? [12:33] <jsdelfino> yes [12:33] <ant_> ok [12:33] <ant_> "decide on distributions" [12:33] <jsdelfino> and if it doesn't that just means that we need to revise our war story, cause we're making this way too complicated [12:34] <jsdelfino> ant, the distributions you proposed looked really good to me [12:34] <ant_> I've posted an example of this. there was a post just now from Ignacio saying the ws samples don't work for him but they work for me, could anyone else try? [12:35] <slaws> i can give it a spin - haven't looked at it yet [12:35] <ant_> there's a problem building the src distro as the parent pom and buildtools are outside of the sca project, but i'll post to the list about that [12:35] <ant_> slaws, thx [12:35] <jsdelfino> one thing I forgot to mention after reviewing your distro strawman [12:36] <jsdelfino> we should make sure that somebody can load one of the samples and run it in both Eclipse and Idea in just a few minutes [12:36] <ant_> ok, i've not tried that at all [12:37] <lresende> r we also going to distrubute sample binaries ? [12:37] <jsdelfino> yeah, I can help and try with Eclipse, if somebody else is using Idea it would be good to try that as well [12:37] <ant_> oh, so with the samples again, I guess we need Ant build scripts [12:37] <ant_> lresende, it does right now and i think thats good to do [12:38] <jsdelfino> yes, +1 for the sample bins [12:38] <lresende> yes, i like that, but haven't looked into your distro strawman yet [12:38] <slaws> ant_ - a non maven build solution for samples would be useful [12:38] <ant_> do we want mvn as well or just Ant? [12:39] <jsdelfino> what's the work required to have a mvn build for the samples? don't we already have it? [12:39] <jsdelfino> I think we could keep the mvn build, but document the ant one [12:40] <slaws> if we have two we need to decide whether we maintain two or just fix up ant for releases [12:40] <ant_> ok. i guess we just need to make sure the sample mvn's work in the build distro with an empty local repo [12:41] <ant_> would anyone like to volunteer to create an Ant script for one of the samples? [12:42] <jsdelfino> anyone? it shouldn't be too hard, we even had this in M1... [12:42] <slaws> didn't someone already create some for a previous release that we can lift [12:42] <halehM> Maybe someone on the mailing list who is not on the IRC? [12:42] <halehM> post on mailing list? [12:43] <ant_> ok, lets skip that one for now then [12:43] <ant_> ok, we skipped over the "define a clear set of runtime and extension APIs" item which is about the SPI work [12:43] <slaws> maybe - i can give it a go if you like [12:44] <ant_> rfeng, posted some interfaces to review. whats the status of that and getting the core to work with them? [12:44] <ant_> slaws, ok thx [12:45] <ant_> (we over time now but we've covered most things on the wiki list. I'll update it with whats been said here) [12:46] <rfeng> I'm in the middle of the working out the invocation chain based on the new SPIs, please let me know if you have questions on the SPIs [12:47] <jsdelfino> I think we need to reconcile these SPIs and the SPIs you had in sandbox/SPI [12:47] <halehM> can we talk about docs or something to discuss later? [12:47] <jsdelfino> so that's some work for this week, important for the release I think [12:48] <halehM> can you dump whatever info you have for extension guide into the link and I'll clean it up and make it presentable. [12:48] <ant_> halehM, sure, i guess i placed a slightly lower priority on that as it doesn't prevent making dsitribution RCs [12:49] <ant_> most of the extension gude will probably need to wait till the SPIs are a bit more completed [12:50] <ant_> do we need to discuss the SPI work more here or just take it to the ML? I guess its agreed they need to get done for the release right? [12:51] <jsdelfino> +1 on getting them done for the release [12:51] <jsdelfino> and discuss the tech details on the ML [12:52] <ant_> ok, the last on the wiki list was documentation, do we need to include anything more than javadoc and sample readme's in the distributions? or will everything else just be on the wiki? [12:54] <jsdelfino> I'd say javadoc for apis and spis, READMEs for samples, README, INSTALL and RELEASE_NOTES at the root? [12:54] <venkatakrishnan> +1 jsdelfino... rest of the doc could be out of the wiki [12:55] <jsdelfino> and a BUILD or INSTALL in the source distro [12:55] <jsdelfino> yes, all the other docs can be on the wiki [12:55] <venkatakrishnan> we could mention a pointer to the wiki in Release Notes [12:55] <ant_> whats the diff btw README and RELEASE_NOTES in the root? [12:57] <venkatakrishnan> I'd imagine README to contain info on how to get started and move on with the release ... [12:57] <venkatakrishnan> and RELEASE NOTEs... more of a list of things that are supported, not supported, know issues etc.. [12:57] <jsdelfino> yes, we can also combine the two in one file [12:58] <venkatakrishnan> yes... that would make things simpler [12:58] <ant_> ok, i'll put files for README and INSTALL but maybe people could help add some contents, and then nearer teh end we can see how much text is where and see what we coudl merge [12:59] <jsdelfino> sounds good [12:59] <ant_> I think we're mostly done, is there anything else anyone wants to discuss? [13:00] <jsdelfino> I have to disc for a moment, but will be back on the IRC later, ttyl [13:02] <ant_> ok. thanks everyone...
