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/[email protected]/msg12291.html
http://www.mail-archive.com/[email protected]/msg13445.html
http://www.mail-archive.com/[email protected]/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
---------------------------------------------------------------------
---------------------------------------------------------------------
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]
