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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
