I'd tend to agree with Rick, where he said that he needs to be able to work with a running user samples and a complete system to help better understand and figure out how pieces and parts fit together, and I believe this would be the expectation of somebody trying to joying the Tuscany community, in particular SCA. Current trunk code does not allow for a end-to-end working system, and the build profiles are building only a very small subset of the code when you try to build from trunk top-level giving you a false impression that all is fine and working. I think that, as Geoff said, occasionally a branch might be the right answer.
-- Luciano Resende http://people.apache.org/~lresende On 2/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
My comments inline. Rick Rineholt wrote: > I think I've asked this indirectly, but I'll be more blunt: > Would one of the proposed objectives of the branch be to eliminate the > current mix of kernel being published as snapshots and the rest of > Tuscany to use those snapshots ? I am finding the current mix confusing and difficult to work with in my Eclipse environment, even with source attached to the JARs, so I'm not particularly interested in repeating this in a branch. > > To be able at the head of this branch check out all of Tuscany SCA > (not SDO/DAS) and do a build from the top of that and expect all of > Tuscany to be running the code just compiled? > To try and to stabilize this to run most of the samples and iTest and > keep them running? Yes that's one of the main goals, build and test the integration of all the pieces in a stable environment. > > To go forth from there to add the features we said we were interested > to work on this branch? > > Then later at some point when those features that require more > involved refactoring of the kernel on the trunk have stabilized and > can run on a relatively regular basis the iTest and samples to merge > them? I think people should be able to work on code in the environment that works best for them and the community (trunk, branch or a sandbox), then merge when possible. The main goal of this branch is integration and stabilization, so I'd prefer to not use it for big new features that would destabilize it, but I'm sure that we'll need incremental improvements and fixes to the existing features in that branch to get the end to end integration working. > > If the answers to these are yes, I think that would work out better > for me and would prefer that approach. > > Thanks. > > Rick Rineholt wrote: >> I'm fine with the content that both the list that Sebastien produced >> to bring up Tuscany to an SCA 1.0 spec and the work that was >> previously discussed for the improving the kernel referenced by Jim. >> I think both sets add value for our users. However, for me the >> branch is not about what content is right, or even how it's >> implemented, but more how it would be developed. >> I find I need to be able to work with running user samples and a >> complete systems to help figure out how pieces and part fit together. >> The current split between prespec published and snapshot core, and >> using mostly an old kernel for the rest of Tuscany truly hampers that >> and makes anything outside of the kernel confusing as what is >> belonging where. >> If it must be, I prefer a branch that can give the alternative back >> to where Tuscany SCA as a whole can run without published snapshot >> kernels and kernel functionality can be added and run immediately >> with remaining Tuscany without having to republish it. I see this >> even with some of the instability we had as a reason for moving to >> the current approach still a preferable environment to work in. >> >> Simon Nash wrote: >>> A March release with basic functional improvements in a consumable >>> package >>> (kernel, selected extensions, and tools) makes sense to me. >>> >>> As well as the items suggested by Sebastien, I'm interested in adding >>> flexible ordering of elements in SCDL files as required by the SCA >>> spec. >>> >>> Having work on these items proceed in a branch so that it does not >>> conflict >>> with the restructuring and distributed deployment work going on in >>> trunk >>> would allow people to be more productive, with less interference >>> between >>> the different activities in progress. >>> >>> Simon >>> >>> Jeremy Boynes wrote: >>>> Guys, >>>> >>>> I'm a little confused here - so far we seem to have 3 different >>>> people volunteering to manage 3 different releases. We now have a >>>> very very long list of "requirements" many of which have not been >>>> discussed on the list and most of which do not have names against >>>> them or really relate to the coding that is actually going on; >>>> they also don't seem to apply to two out of the three releases. >>>> Version numbers are being assigned to milestones, we have >>>> stabilization branches and end-to-end scenarios, all without >>>> meaningful discussion on this list. >>>> >>>> I think we need to stop and figure out what we are doing as a >>>> community. Here, on this list, with everyone involved. >>>> -- >>>> Jeremy >>>> >>>> On Feb 6, 2007, at 3:58 PM, Jean-Sebastien Delfino wrote: >>>> >>>>> Jim Marino wrote: >>>>> >>>>>> Sebastien, >>>>>> >>>>>> I'm a little surprised that you have not referenced the previous >>>>>> release discussion thread or any of the work that has been >>>>>> ongoing in core over the past month and a half: >>>>>> >>>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12291.html >>>>>> >>>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13445.html >>>>>> >>>>>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12238.html >>>>>> >>>>>> Most of the work in core during this period has been aimed at >>>>>> getting a release of kernel out that supports features outlined >>>>>> in the first referenced thread. How does your proposal relate to >>>>>> that release? I'm happy to have two simultaneous release >>>>>> processes going at once and think it could even be beneficial. >>>>>> However, it would be helpful if you put your proposal in context >>>>>> so others such as myself can understand it a bit better. >>>>>> >>>>>> Jim >>>>>> >>>>>> >>>>>> On Feb 5, 2007, at 5:19 PM, Jean-Sebastien Delfino wrote: >>>>>> >>>>>>> Now that we have a list of requirements on our Wiki at http:// >>>>>>> cwiki.apache.org/confluence/display/TUSCANY/Feature+areas+and+what >>>>>>> +folks+are+working+on, and a number of people are signing up >>>>>>> for some of the corresponding work, I'd like to start a >>>>>>> discussion on the content of our next milestone. Given that our >>>>>>> last milestone was in December, I'd like to have another >>>>>>> milestone soon, by March. >>>>>>> >>>>>>> Here's the function that people have already signed up for on >>>>>>> the Wiki page + what I'm interested in for this milestone: >>>>>>> - Support for complex properties and multi valued properties >>>>>>> - Support for SCA deployment-contributions, and in particular >>>>>>> support for JAR based deployment contributions >>>>>>> - Ability to reference and resolve composites in an SCA domain >>>>>>> (would be nice to support recursive composition but I'm not >>>>>>> particularly interested in it) >>>>>>> - Ability to configure and override the configuration of >>>>>>> References, Services and Properties (again here I'd be happy if >>>>>>> this works with just one or two levels of composition) >>>>>>> - Support for wiring inside an SCA domain references to >>>>>>> services with bindings and have the wiring decide the endpoints >>>>>>> to use >>>>>>> - Support for business exceptions in end to end interactions >>>>>>> - Support for promoting services and references out of a >>>>>>> composite (without having to wire a reference to a reference or >>>>>>> a service to a service) >>>>>>> - Support for defining and configuring services and references >>>>>>> directly on components >>>>>>> - Interchangeability / mapping between Java and WSDL interfaces >>>>>>> - Ability to use, alter and write an SCDL model at deployment >>>>>>> - WSDL2Java and Java2WSDL support using the SDO databinding >>>>>>> - Core support for non-blocking invocations playing nicely with >>>>>>> bindings, and without having to send complete routing paths to >>>>>>> the services/references >>>>>>> - Databinding framework with support for conversions between >>>>>>> JAXB and SDO >>>>>>> - Working and modular build allowing to build subsets of the >>>>>>> project >>>>>>> - Services to add(/remove/query) compositions to an SCA domain >>>>>>> - Services to add(/remove/query) SCA deployment contributions >>>>>>> to an SCA domain >>>>>>> - Core support for addressing, resolving, loading artifacts >>>>>>> from SCA deployment contributions >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> --Jean-Sebastien >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> Jim, >>>>> >>>>> The idea is to bring together a number of pieces from the core >>>>> runtime, extensions like databinding and WSDL support, tools like >>>>> WSDL2Java and Java2WSDL etc. and stabilize them to get some of >>>>> the basic function that I listed in my earlier email working in >>>>> end to end scenarios. As a first step, we probably need a very >>>>> small subset of the new deployment story that is being built in >>>>> the trunk, starting with the ability to work with one SCA >>>>> composite and one JAR contribution. >>>>> >>>>> To have a stable integration by March, I think we need to start >>>>> this effort now. In order to not disrupt the wider and more >>>>> innovative work going on in the trunk I'd like to do the >>>>> integration/stabilization work in a branch, starting with the >>>>> kernel from the pre-spec-changes branch or a stable level from >>>>> last week. This will allow the trunk to continue to evolve in >>>>> parallel and at a faster pace to support things like federated >>>>> deployment, new management services, JMX support, multiparent >>>>> classloading, and the latest changes to the Java C&I APIs. >>>>> >>>>> -- >>>>> Jean-Sebastien >>>>> -- Jean-Sebastien --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
