Hi, My view is that, if the design that Sebastien is proposing is a step forward in our modularization goals then its good to get it into the trunk. I like the design and here is my +1 to move this into the trunk. IMO, moving to the trunk does not mean the kernel will have to be immediately integrated with this. I suppose we can take this incrementally evaluating and changing things (wherever required) as we go along. Since this is going to come in as a new module, it would only help in the incremental phase over.
Thanks - Venkat On 3/20/07, ant elder <[EMAIL PROTECTED]> wrote:
I agree putting it the trunk makes sense for all the reasons already mentioned. The trunk is where main development should take place unless there are a good reasons not to. Code going into trunk does not have to be finished and perfect but should be worked on in the trunk to incrementally improve. No one is going to intentionally set out to make things unstable but during active development there are going to be times when not everything works perfectly - just look at the state of the trunk right now. When requirements come up that need more guaranteed stability then they can use a branch so active development can continue in the trunk. This is what we've done in the past, eg. for all the releases and with the integration branch. The proposal is to add a new module for this code in java/sca/assembly so its not going to make anything unstable, and that allows other modules to easily start using it as the need arises. I can't see any reasons for this not to go in trunk. ...ant On 3/20/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > I think it's a good idea to move this code out of the integration > branch. I prefer to keep the integration branch for its original > purpose of providing a stable environment for developing and testing > end to end scennarios. > > I agree that it's important not to destabilize trunk by adding this > code. This could be achieved by separating it from the rest of trunk > by putting it in a separate module that is not part of the main > build profile. > > If there is potential to use this code in other parts of the trunk > code (Sebastien suggested a few possibilities), then this would be a > good reason to put it in trunk rather than a sandbox. I'm not clear > on whether this usage is something that might happen soon or is a little > further out. If this expected usage is a near-term thing, then I think > it makes sense to put the code in trunk. If there isn't any immediate > need to use it elsewhere, then it could go into a sandbox for now. > > Simon > > Jim Marino wrote: > > > > On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote: > > > >> Jean-Sebastien Delfino wrote: > >> > >>> I'd like to start a discussion on how we could componentize our SCA > >>> runtime kernel. I posted two diagrams on our Wiki at http:// > >>> cwiki.apache.org/confluence/display/TUSCANY/Componentizing+our > >>> +runtime to help start the discussion. > >>> > >>> One of the ideas is to allow for different integration strategies > >>> with app servers and other runtime environments. Some integrations > >>> may reuse the Tuscany kernel as a whole, but others will want to > >>> reuse only a subset or replace parts with specific implementations. > >>> > >>> A few examples come to mind: > >>> - swap our POJO IOC container with another one already there in the > >>> target app server; > >>> - strip out the local assembly support when building a WSDL remote- > >>> interface based (an SCA/BPEL container for example); > >>> - strip out the federated deployment / discovery / distributed > >>> wiring support when building a simple standalone runtime, or if your > >>> app server already supports that and you'd like to integrate with it; > >>> - replace the SCDL loaders if you're storing the assembly metadata > >>> in a database instead of SCDL files; > >>> - use a different handler/interceptor mechanism already in use in > >>> your app server or a more dynamic invocation mechanism to support > >>> scripting languages for example. > >>> > >>> Another scenario I have in mind is to reuse parts of the Tuscany > >>> kernel in validation tasks, codegen utilities, deployment and > >>> management tools. For example I'd like to have an Ant task that > >>> automates the generation of SDO or JAXB objects for an entire SCA > >>> contribution. This task will need access to the SCA assembly model, > >>> the SCA contribution model, maybe our Interface contract model as > >>> well, but I don't want to drag the whole kernel for that. Similar > >>> idea for deployment and management tasks. > >>> > >>> A refactored/componentized kernel will also make it easier for > >>> people to contribute to the individual pieces and exchange > >>> components between our various initiatives. > >>> > >>> For example I'd like to pull pieces of the trunk in the integration > >>> branch, and it would be much easier if the single kernel/core module > >>> was split in smaller independent modules (assembly model, SCA > >>> contribution model, loaders, assembly wiring logic, invocation > >>> framework etc...) > >>> > >>> To help explore these ideas, I'm thinking about starting some > >>> concrete work and try to pull some of the kernel code into > >>> individual modules, probably start from the bottom of the stack and > >>> have the assembly metadata and SCDL loaders in separate modules. > >>> There's a lot of code, so I could use any help if people are > >>> interested. > >>> > >>> Thoughts? > >>> > >> > >> I made some progress with an assembly model module, containing > >> interfaces representing the SCA 1.0 assembly model and a default > >> implementation of these interfaces. > >> > >> The module is currently there: http://svn.apache.org/repos/asf/ > >> incubator/tuscany/branches/sca-java-integration/sca/assembly. There's > >> additional test cases as well under http://svn.apache.org/ > >> repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl, > >> I'm planning to merge them into the assembly module soon. The > >> interfaces in assembly are different from the o.a.t.spi.model classes > >> in kernel/core. They are interfaces instead of classes, and I tried > >> to be as close as possible to the latest revision of SCA 1.0 spec. > >> I'd like your feedback and please let me know if you see any > >> inconsistencies with the SCA 1.0 spec. Next, I'd like to see if the > >> model loaders could be externalized as well in a separate module, but > >> this is going to be a little more complicated as the current loaders > >> have more dependencies, including circular dependencies with other > >> packages in kernel/core. > >> > >> This work is starting to generate significant changes and new code > >> and I don't want to risk destabilizing the integration branch with it > >> so I'd like to continue to work on this somewhere in the trunk > >> instead. I'm thinking of moving the assembly model module to trunk > >> under java/sca/assembly, available for use by our various tools, > >> plugins, as well as the kernel and services modules if they need. > >> > > As you mentioned above, the approach taken is significantly different > > than the design we have in trunk. To avoid destabilizing it, I'd > > suggest starting this in a sandbox so that we can better understand how > > it would integrate with our existing design without impacting existing > > ongoing work. > > > > Jim > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
