Hi, I have populated the table with the active modules we have in trunk. In the "Note" column, I also captured some TODOs for a cleaner kernel.
Thanks, Raymond From: Raymond Feng Sent: Tuesday, December 02, 2008 2:58 PM To: [email protected] Subject: Re: What to do next for the Tuscany Java SCA 2.x stream Hi, I created the following wiki page to track the Tuscany SPI packages contributed by the various modules. http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SPIs Thanks, Raymond From: Simon Laws Sent: Tuesday, December 02, 2008 9:21 AM To: [email protected] Subject: Re: What to do next for the Tuscany Java SCA 2.x stream On Tue, Dec 2, 2008 at 6:43 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: Hi, I propose that we use the following two perspectives to drive the Tuscany Java SCA 2.x stream. 1) Runtime architecture: Clean up the core set of modules as documented at [1] * Enforce the modularity and make sure cross-module code dependencies go through proper set of SPIs * Rationalize the core-spi which is the contract between the core and extensions (implementations and bindings). 2) SCA functionality: Provide a consistent SCA domain story for deployment (See [2], [3] and [4]). * Use scenarios to better understand how multiple contributions are installed to a SCA domain, how cross-contribution artifact references are resolved, how nodes are configured to represent runtime capabilities and how nodes run SCA composite applications. * Decompose the basic services related to SCA domain management and provide SPIs for these atomic operations. [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/OASIS+Development+Stream [2] http://markmail.org/message/afae3zayzmpq6rx7?q=multiple+contributions+and+the+domain-level+composite&page=1&refer=qttcfwwun33gausl [3] http://www.ibm.com/developerworks/opensource/library/ws-sca-tuscany/index.html [4] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Distributed+Runtime Thanks, Raymond Thanks Raymond Picking up on the thread title "what to do next". It's good to set ourselves some short term targets without worrying about the full shopping list that was developing on the themes thread [1]. - I propose we define "next" as what we think we can achieve before we each go on leave for Christmas - I agree It's important to progress both functional and non-functional objectives but there will be some overlap. Without one we can't prove the other. - For me, these are the things that should come "Next" before we start to bring up lots of extensions SPI (1 - non-funtional) ** Define the SPI (collect the SPI actions that have appeared on the wiki and various threads). - I would include tidying up the providers/endpoint/builders (SL1) ** Package the SPI (I thinks this is your Enforce the modularity and make sure cross-module code dependencies go through proper set of SPIs) Thin slice through "soup to nuts" Tuscany delivery story (1 - non functional) (SL4) ** developing core ** developing extension ** developing samples/demos ** building an releasing a distribution, how do we do this much more quickly than we do now ** using a distribution Runtime usability story (2 functional) (SL2) ** Domain/Node - points above are comprehensive. How to adopt OASIS spec features (2 functional) (SL3) ** what features have changed ** how to extend the infrastructure, XSD, processors, runtime, tests ** how to do compliance testing ** how to improve our documentation I've listed my order of interst in these things. What do others have on their mind? I think we should start a roadmap page to record these things so that everyone can keep track of what people have in mind. Should also include what's going on in 1.x. I'll go create one once when we have the output from this discussion Regards Simon [1] http://www.mail-archive.com/[email protected]/msg03700.html
