+1 to that. I'm just pointing out issues to help with making the decision: the longer its left the more we lose the regular release drumbeat benefits, the harder it gets to pull together for maybe not so much benefit, and if its going to be left till January then in a lot of respects its better to also wait till then before making the RCs.
...ant On Nov 13, 2007 6:36 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > +1 on Simon Laws's proposal. Let's try get the contents ready in December > and the RM can decide when to start the release process. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Simon Laws" <[EMAIL PROTECTED]> > To: <[email protected]>; <[EMAIL PROTECTED]> > Sent: Tuesday, November 13, 2007 9:35 AM > Subject: Re: [DISCUSS] Java SCA Release 1.1 was: Re: Re: [DISCUSS] Tuscany > SCA Roadmap and next releases > > > > On Nov 13, 2007 4:53 PM, ant elder <[EMAIL PROTECTED]> wrote: > > > >> On Nov 13, 2007 4:31 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > >> > >> > > >> > ant elder wrote: > >> > > >> > > On Nov 13, 2007 11:02 AM, Simon Laws <[EMAIL PROTECTED]> > >> wrote: > >> > > > >> > > > >> > >>On Nov 9, 2007 7:05 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > >> > >> > >> > >> > >> > >>>+1 for Simon Laws as the release manager. > >> > >>> > >> > >>>+1 on Simon Nash's proposal to have an early-January 1.1 release. > >> > >>> > >> > >>>I would like to get some basic transaction support into the > >> 1.1release. > >> > >>> > >> > >>>Thanks, > >> > >>>Raymond > >> > >>> > >> > >>>----- Original Message ----- > >> > >>>From: "Simon Nash" <[EMAIL PROTECTED]> > >> > >>>To: <[email protected]> > >> > >>>Sent: Friday, November 09, 2007 4:07 AM > >> > >>>Subject: Re: [DISCUSS] Java SCA Release 1.1 was: Re: Re: [DISCUSS] > >> > >> > >> > >>Tuscany > >> > >> > >> > >>>SCA Roadmap and next releases > >> > >>> > >> > >>> > >> > >>> > >> > >>>>+1 for Simon as RM. > >> > >>>> > >> > >>>>I added a few things to the list that I'd like to get done for > 1.1. > >> > >>>> > >> > >>>>I think the distribution/packaging changes for better modularity > >> > >>>>and > >> > >>>>daployability are very important and I'd like to see these in 1.1 > . > >> > >>>>I think it's more realistic to aim for an early January release > >> > >>>>date > >> > >>>>rather than trying to get something out in December just before > the > >> > >>>>holidays. Also, December releases tend not to get immediate > pickup > >> > >>>>and adoption because of people being out for the holidays. > >> > >>>> > >> > >>>> Simon > >> > >>>> > >> > >>>>ant elder wrote: > >> > >>>> > >> > >>>>>On Nov 5, 2007 3:54 PM, Simon Laws <[EMAIL PROTECTED]> > >> wrote: > >> > >>>>> > >> > >>>>> > >> > >>>>> > >> > >>>>>>On 10/23/07, wang feng <[EMAIL PROTECTED]> wrote: > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>>hi Jean-Sebastien, > >> > >>>>>>> > >> > >>>>>>>Please see my comments below. > >> > >>>>>>> > >> > >>>>>>>Thanks, > >> > >>>>>>>wangfeng > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>>On 2007-10-20, Jean-Sebastien Delfino <[EMAIL PROTECTED]> > >> wrote: > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>>>wang feng wrote: > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>>>Hi all, > >> > >>>>>>>>> > >> > >>>>>>>>>We have used Tuscany 1.0 in our product and found some > >> > >>>>>>>>>features > >> > is > >> > >>>>>>> > >> > >>>>>>>important to us. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>>>Thanks a lot for contributing here and helping us understand > >> what > >> > >>> > >> > >>>you'd > >> > >>> > >> > >>>>>>>>like to see in Tuscany! > >> > >>>>>>>> > >> > >>>>>>>>I have a few questions to make sure I understand what you're > >> > >> > >> > >>looking > >> > >> > >> > >>>>>>for. > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>>>>- Support hot deployable on contribution and composite. > >> > >>>>>>>>>This should be have a recursive algorithm to update the > >> > correlated > >> > >>>>>>> > >> > >>>>>>>component when it has been referenced. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>>>Can you give a brief description of the type of hot > deployment > >> > that > >> > >>>>>>>>you're trying to support? It does not have to be very > detailed > >> but > >> > >>>>>> > >> > >>>>>>maybe > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>>>just an outline or an example showing what your contributions > >> and > >> > >>>>>>>>composites look like and the steps that you'd like to go > >> > >>>>>>>>through > >> > to > >> > >>>>>>>>redeploy them. > >> > >>>>>>>> > >> > >>>>>>>>In particular I'd like to understand if you want to redeploy > >> > >> > >> > >>imported > >> > >> > >> > >>>>>>>>contributions (imported by <import> in sca-contribution.xml), > >> > >> > >> > >>nested > >> > >> > >> > >>>>>>>>composites, and what you'd like to be able to update in the > >> > >>>>>>>>contributions and composites, classes? component > configuration? > >> > >>>>>>>>bindings? wiring? etc. > >> > >>>>>>>> > >> > >>>>>>> > >> > >>>>>>>My use case like that(there are three contributions): > >> > >>>>>>>contribution A export composite A, > >> > >>>>>>>contribution B import composite A used by composite B and > export > >> > >>>>>> > >> > >>>>>>composite > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>>B, > >> > >>>>>>>contribution C import composite B > >> > >>>>>>>If we update composite A in contribution A,the sca runtime > >> > >>>>>>>should > >> > be > >> > >>>>>>>update the correlated contribution B and C and the component's > >> > >>>>>>>relationship should be rewiring. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>>>>- Support SDO namespace when using websservice. > >> > >>>>>>>>>Deploy a service to webservice,a schema file used in SDO and > >> have > >> > >>> > >> > >>>sdo > >> > >>> > >> > >>>>>>>namespace such as commonj.sdo/java or commonj.sdo/xml,we > should > >> > >>> > >> > >>>support > >> > >>> > >> > >>>>>>>the feature when parsing the wsdl. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>>>Could you provide an example WSDL and XSD? > >> > >>>>>>>> > >> > >>>>>>> > >> > >>>>>>>My wsdl file like this: > >> > >>>>>>><wsdl:definitions xmlns:apachesoap=" > >> http://xml.apache.org/xml-soap"; > >> > >>>>>>>xmlns:sdoJava="commonj.sdo/java" xmlns:soapenc=" > >> > >>>>>>>http://schemas.xmlsoap.org/soap/encoding/"; xmlns:tns=" > >> > >>>>>>>http://com.primeton.eos/com/primeton/eos/newcomponent"; > >> xmlns:wsdl=" > >> > >>>>>>>http://schemas.xmlsoap.org/wsdl/"; xmlns:wsdlsoap=" > >> > >>>>>>>http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:xsd=" > >> > >>>>>>>http://www.w3.org/2001/XMLSchema"; targetNamespace=" > >> > >>>>>>>http://com.primeton.eos/com/primeton/eos/newcomponent";> > >> > >>>>>>> <wsdl:types> > >> > >>>>>>> <schema xmlns="http://www.w3.org/2001/XMLSchema"; > >> > >>>>>> > >> > >>>>>>targetNamespace=" > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>>http://com.primeton.eos/com/primeton/eos/newcomponent";> > >> > >>>>>>> <import namespace=" > >> > >>> > >> > >>>http://schemas.xmlsoap.org/soap/encoding/ > >> > >>> > >> > >>>>>>>"/> > >> > >>>>>>> <complexType name="SdoJava_java_util_List" > >> > >>>>>>>sdoJava:instanceClass="java.util.List"/> > >> > >>>>>>> <complexType name="ArrayOf_soapenc_string"> > >> > >>>>>>> <complexContent> > >> > >>>>>>> <restriction base="soapenc:Array"> > >> > >>>>>>> <attribute ref="soapenc:arrayType" > >> > >>>>>>>wsdl:arrayType="soapenc:string[]"/> > >> > >>>>>>> </restriction> > >> > >>>>>>> </complexContent> > >> > >>>>>>> </complexType> > >> > >>>>>>> <complexType name="SdoJava_java_lang_String" > >> > >>>>>>>sdoJava:instanceClass="java.lang.String"/> > >> > >>>>>>> <complexType > >> name="SdoJava_stockquote_StockQuoteService" > >> > >>>>>>>sdoJava:instanceClass="stockquote.StockQuoteService"/> > >> > >>>>>>> <complexType > >> > >>>>>>>name="ArrayOf_soapenc_stockquote_StockQuoteService"> > >> > >>>>>>> <complexContent> > >> > >>>>>>> <restriction base="soapenc:Array"> > >> > >>>>>>> <attribute ref="soapenc:arrayType" > >> > >>>>>>>wsdl:arrayType="tns:SdoJava_stockquote_StockQuoteService[]"/> > >> > >>>>>>> </restriction> > >> > >>>>>>> </complexContent> > >> > >>>>>>> </complexType> > >> > >>>>>>> </schema> > >> > >>>>>>> </wsdl:types> > >> > >>>>>>> <wsdl:message name="newcomponent.newbiz1OutputMessage"> > >> > >>>>>>> <wsdl:part name="out1" type="xsd:string"></wsdl:part> > >> > >>>>>>> <wsdl:part name="out2" type="xsd:string"></wsdl:part> > >> > >>>>>>> </wsdl:message> > >> > >>>>>>> <wsdl:message name="newcomponent.newbiz1InputMessage"> > >> > >>>>>>> <wsdl:part name="param1" > >> > > >> > > >> > >>>>>>>type="tns:ArrayOf_soapenc_stockquote_StockQuoteService"></wsdl:part> > >> > >>>>>>> <wsdl:part name="param2" type="xsd:string"></wsdl:part> > >> > >>>>>>> </wsdl:message> > >> > >>>>>>> <wsdl:message name="newcomponent.newbiz.bizxOutputMessage"> > >> > >>>>>>> <wsdl:part name="out1" > >> > >>>>>>>type="tns:SdoJava_java_lang_String"></wsdl:part> > >> > >>>>>>> </wsdl:message> > >> > >>>>>>> <wsdl:message name="newcomponent.newbiz.bizxInputMessage"> > >> > >>>>>>> <wsdl:part name="param1" > >> > >>>>>>>type="tns:SdoJava_java_util_List"></wsdl:part> > >> > >>>>>>> <wsdl:part name="param2" > >> > >>>>>>>type="tns:ArrayOf_soapenc_string"></wsdl:part> > >> > >>>>>>> </wsdl:message> > >> > >>>>>>> <wsdl:portType name="newcomponent"> > >> > >>>>>>> <wsdl:operation name="newbiz"> > >> > >>>>>>> <wsdl:input message="tns: > >> > >>>>>> > >> > >>>>>>newcomponent.newbiz.bizxInputMessage > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>>"></wsdl:input> > >> > >>>>>>> <wsdl:output message="tns: > >> > >>>>>>>newcomponent.newbiz.bizxOutputMessage"></wsdl:output> > >> > >>>>>>> </wsdl:operation> > >> > >>>>>>> <wsdl:operation name="newbiz1"> > >> > >>>>>>> <wsdl:input message="tns: > >> > >> > >> > >>newcomponent.newbiz1InputMessage > >> > >> > >> > >>>>>>>"></wsdl:input> > >> > >>>>>>> <wsdl:output message="tns: > >> > >>> > >> > >>>newcomponent.newbiz1OutputMessage > >> > >>> > >> > >>>>>>>"></wsdl:output> > >> > >>>>>>> </wsdl:operation> > >> > >>>>>>> </wsdl:portType> > >> > >>>>>>></wsdl:definitions> > >> > >>>>>>> > >> > >>>>>>>When I use the wsdl file to describe a service's interface,the > >> > >> > >> > >>console > >> > >> > >> > >>>>>>>show a warning as below. > >> > >>>>>>>[WARNING] Component service interface incompatible with > service > >> > >>>>>> > >> > >>>>>>interface: > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>>test/HelloInterfaceImpl null > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>>>>- Support load contribution as a osgi bundle. > >> > >>>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>>Are you looking for something different from the OSGi bundle > >> > >>>>>>>>contribution support already in the 1.0 release (as in > >> > >>>>>>>>itest/itest-contribution-osgi for example)? > >> > >>>>>>>> > >> > >>>>>>> > >> > >>>>>>>Sorry for the misunderstanding. > >> > >>>>>>>I meaned that the sca runtime should be run in a osgi runtime > >> > >>>>>>>and > >> > >> > >> > >>the > >> > >> > >> > >>>>>>>classloader should be different for every contribution. > >> > >>>>>>>I have already found there were some discussion on the mail > >> > >>>>>>>list. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>>>>Thanks, > >> > >>>>>>>>>wangfeng > >> > >>>>>>>> > >> > >>>>>>>>-- > >> > >>>>>>>>Jean-Sebastien > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>> > >> > > >> > > >> > >>>>>>>--------------------------------------------------------------------- > >> > >>>>>>> > >> > >>>>>>>>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] > >> > >>>>>>> > >> > >>>>>>>Now that 1.0.1 is well on the way I'd like to suggest that we > >> start > >> > >> > >> > >>to > >> > >> > >> > >>>>>>think about our next feature release (1.1). I just had a look > >> > >>>>>>back > >> > at > >> > >>> > >> > >>>the > >> > >>> > >> > >>>>>>roadmap page that Raymond created [1] and tried to mark things > >> that > >> > >> > >> > >>I'd > >> > >> > >> > >>>>>>seen > >> > >>>>>>going past on the the mail list either as done or as being > worked > >> > on. > >> > >>> > >> > >>>We > >> > >>> > >> > >>>>>>need to decide what we want in and when we want to get the > >> > >>>>>>release > >> > >> > >> > >>out. > >> > >> > >> > >>>>>>There's a lot left on the list and also items that have been > >> raised > >> > >> > >> > >>on > >> > >> > >> > >>>>>>the > >> > >>>>>>list since the page was created and in the spirit of trying to > >> > >>>>>>get > >> > us > >> > >>> > >> > >>>in > >> > >>> > >> > >>>>>>the > >> > >>>>>>right shape to get a release done I'd like to volunteer as the > >> > >> > >> > >>release > >> > >> > >> > >>>>>>manager. > >> > >>>>>> > >> > >>>>>>Regards > >> > >>>>>> > >> > >>>>>>Simon > >> > >>>>>> > >> > >>>>>> > >> > >>> > >> > >> > >> > > >> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion > >> > >> > >> > >>>>> > >> > >>>>>+1 to the 1.1 release and for Simon as RM. > >> > >>>>> > >> > >>>>>What sort of time frame are you thinking? There's a few things > I'd > >> > >> > >> > >>like > >> > >> > >> > >>>>>to > >> > >>>>>try get in 1.1 but the main one would be the JMS binding and it > >> will > >> > >>>>>probably take at least a few weeks to get that ready. > >> > >>>>> > >> > >>>>> ...ant > >> > >>>>> > >> > >>>>> ...ant > >> > >>>>> > >> > >>>> > >> > >>>> > >> > > >> > >>>>--------------------------------------------------------------------- > >> > >>>>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] > >> > >>> > >> > >>>OK, I think it's a reasonable point about the release getting lost > >> > >>>in > >> > >> > >> > >>the > >> > >>holidays. However if we don't get the content for the release done > >> > before > >> > >>Christmas then my worry is that the actual release will slip out > >> > >>until > >> > >>February, as is the way with these things. > >> > >> > >> > >>So if people favour announcing the release in January how about we > >> look > >> > to > >> > >>see if we can get the content done before we all go on holiday. We > >> then > >> > >>complete the voting process and announce the release early in > >> > >>January? > >> > >> > >> > >>Can we get some idea what from the list [1] has to be in? I've put > >> some > >> > >>thumbs up on the things I'm interested in and think I will have > time > >> to > >> > >>work > >> > >>on before I go away for the holidays. Can you all do the same? > >> > >> > >> > >>Regards > >> > >> > >> > >>Simon > >> > >> > >> > >>[1] > >> > >> > >> > > >> > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion > >> > >> > >> > > > >> > > > >> > > > >> > > Its good to release often and its already about 6 weeks since the > >> > > 1.0release so ideally we'd be doing a release about *now*. The > longer > >> > > its left > >> > > the harder it becomes and the more work it takes to pull the > release > >> > > together, waiting till January seems too long to me so i'd still > >> > > favor > >> > going > >> > > for the pre-Christmas 1.1 release. > >> > > > >> > > ...ant > >> > > > >> > We are doing a release about *now". It's 1.0.1. > >> > > >> > Every time we do a release we have to close down active development > >> > threads, bring everythng together at a consistent level, and go into > a > >> > review cycle to get the release up to a decent quality level. > >> > > >> > Given that we have only just completed this exercise for 1.0.1, I > think > >> > we need at least 4 weeks of solid development before we close down > and > >> > go into the next of these consolidate and review cycles. This is > >> > consistent with having the release candidate available before > Christmas > >> > and actually releasing it in early January. > >> > > >> > Simon > >> > > >> > >> But 1.0.1 is based on the 1.0 branch not the trunk code, sure a lot > from > >> trunk got merged into 1.0.1 but its still going to be a long time > before > >> we > >> get a release based on trunk and the longer we leave it entropy sets in > >> and > >> the harder it gets. Its true getting a release out does suck up a lot > of > >> time that could otherwise be used doing other development so there is a > >> balance to be found. > >> > >> I'm fine with waiting till next year if thats what everyone else > >> wants...but > >> I'm sure it will get harder (which is mainly a problem for the RM), and > >> having a release is a motivator - there's a good chance work items will > >> just > >> stretch out to fill up the extra time available so we may end up not > >> getting > >> that much more into the release by having longer to do it. > >> > >> ...ant > > > > There at least seems to be agreement that any development work for 1.1 > > needs > > to be done this year. Event with the "publish after the holidays" option > > the > > very latest I would want to cut the branch would be the 14th to give me > a > > chance to get at least RC1 out before I go on holiday. That is only > > actually 9 working days after the original proposal. > > > > As I say I'll agree to publishing 1.1 in Jan but not to carry on > > developing > > for 1.1 in Jan. > > > > Simon > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
