Bigbank application, was Rules for Revolutionaries

[Jean-Sebastien Delfino <js...@apache.org>]

Rick wrote:
> If there are no issues I'd like to look at the bigbank sample 
> converting to the new composite spec.  Besides the obvious need to 
> change the SCDL,  I suppose refactoring the server (account) side to 
> take advantage of the composite nature maybe see if includes can be 
> used too.  Was there immediately more that you were thinking of ?
>
> Jean-Sebastien Delfino wrote:
>> Simon Nash wrote:
>>> Thanks, Sam; this is very helpful.  One part in particular of the
>>> James Duncan Davidson post caught my eye:
>>>
>>> <jdd>
>>> 4) The trunk is the official versioned line of the project. All
>>> evolutionary minded people are welcome to work on it to improve it.
>>> Evolutionary work is important and should not stop as it is always
>>> unclear when any particular revolution will be ready for prime time
>>> or whether it will be officially accepted.
>>> </jdd>
>>>
>>> I think we have failed to follow this guideline over recent weeks.
>>> People have submitted patches for the trunk and they have not been
>>> applied (or applied to a sandbox instead).  Technical discussions
>>> have started that in the normal course of events would have led to
>>> commits and patches, but these commits and patches have not been
>>> forthcoming.  This has generally led to progress on the project
>>> (except for sandbox activity) being stalled, presumably because
>>> people were waiting to see what would happen with the sandbox code.
>>>
>>> I believe we need to get the project moving forward again.  At the
>>> present time, we have an evolutionary trunk and a revolutionary
>>> sandbox.  We should therefore continue (in reality restart) doing
>>> evolutionary work on the trunk for the reasons that JDD gives in
>>> the quote above.  There is evolutionary work that can usefully
>>> be done, such as Raymond's work on databindings, the work on
>>> interface represenation that Ant and others have been discussing,
>>> Venkat's RMI binding, and the ongoing work on Java2WSDL.  I'm sure
>>> there are other things too.  If at some point there is a revolution,
>>> then we will deal with it when it happens and rework existing code
>>> as necessary.
>>>
>>> Revolutionaries can work in the "chianti" sandbox, or if they
>>> prefer a different brand of revolution, they can create another
>>> sandbox to do this.  The latter is perfectly legitimate according
>>> to the Rules for Revolutionaries, and I think it is healthy for
>>> the project for people to be able to show their new ideas in the
>>> form of code, as long as the project as a whole (i.e., the whole
>>> community) keeps moving forward with ongoing work on the trunk
>>> and doesn't focus exclusively on what is happening in the
>>> sandboxes.
>>>
>>>   Simon
>>>
>>> Sam Ruby wrote:
>>>
>>>> Jeremy Boynes wrote:
>>>>
>>>>> Ant
>>>>>
>>>>> I'm disappointed that you have chosen this path. I will ask one 
>>>>> more time if you and Sebastien would consider collaborating with 
>>>>> those of us working on core2.
>>>>
>>>>
>>>> A while ago, I agreed to be a mentor for this project.  I guess it 
>>>> is about time that I start acting like one.
>>>>
>>>> If this project ever hopes to exit incubation, it had better start 
>>>> acting like an ASF project.  For starters, I suggest that all 
>>>> committers read the Rules for Revolutionaries[1][2][3].
>>>>
>>>> For those who want the Cliff notes version: anybody who wants to 
>>>> work in an evolutionary fashion on the main trunk is welcome to do 
>>>> so.  Anybody who wants to work on a revolutionary branch is welcome 
>>>> to do so. Multiple concurrent revolutionary branches are OK too.
>>>>
>>>> One thing that is decidedly NOT OK is to include a version number 
>>>> in the name, as it causes friction.  Hence, I'd suggest that 
>>>> "core2" immediately get renamed to something that neither reflects 
>>>> the term "core" or the number "2".
>>>>
>>>> Something implicit in the R4R document is that the burden of proof 
>>>> is on the revolutionaries.  If you would like to see your 
>>>> particular branch merged back onto the trunk, be prepared to 
>>>> demonstrate why your particular branch is not merely better, but 
>>>> necessary.  My experience it that the more concrete and the less 
>>>> hand-wavy the argument, the more likely it will be accepted.  So, 
>>>> if you chose to believe that scenarios and test cases are optional, 
>>>> just remember, merging your sandbox back to the trunk is optional 
>>>> too.  That does not mean that scenarios and test cases are 
>>>> required, but it does mean that if these aren't present, you need 
>>>> to come up with something just as compelling.
>>>>
>>>> - Sam Ruby
>>>>
>>>> [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
>>>> [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf
>>>> [3] 
>>>> http://marc2.theaimsgroup.com/?l=apache-community&m=105712356508947
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>>
>>>
>> Simon,
>>
>> I agree. I'm going to do some work on the samples in the trunk, I'd 
>> like to evolve some of them (starting with the Calculator sample and 
>> then Bigbank) to start showing some of the concepts in the evolving 
>> SCA specification.
>>
>> In addition, I searched through our JIRA backlog and found the 
>> following patches, which should be reviewed and potentially applied 
>> to the trunk:
>> TUSCANY-120 - Java2WSDL patches to generate correct XSDs
>> TUSCANY-454 - Fixes WSDLs in some of the samples
>> TUSCANY-457 - Fixes an NPE in TuscanyContextListener
>> TUSCANY-477 - Improve unresolved type error handling
>> TUSCANY-520 - Fixes build to handle folder names containing spaces
>> TUSCANY-535 - Implements XSDHelper.generate()
>>
>> I'm going to start by looking at TUSCANY-120.
>>
>> I may have missed some patches (I wished JIRA had a query listing all 
>> issues with pending patches...) so could people waiting for their 
>> patches to be reviewed and applied please speak up and point us to 
>> the JIRA issue numbers? Thanks.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Rick,

Sounds like a good plan, we could port the SCDL first and adjust to the 
new APIs (for example ModuleContext becomes CompositeContext). After 
this first pass, I suggest to write a Composite around the bigbank 
moduleComponents (equivalent to an SCA 0.9 subsystem), and maybe also 
use composite includes and/or nested composite implementations inside 
the account composite.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org