You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/02/06 02:19:30 UTC
Content for next milestone
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by scabooz <sc...@gmail.com>.
I think Raymond makes some good points. It's very difficult to consume,
extend and test the runtime with all of the volatility. A bunch of itests
have
been contributed, but they don't work. These tests are a concrete way
to measure stability, and I'm sure there will be more contributed over time.
I think there's a difference between stability for the sake of producing a
milestone and stability for the sake of consumers and extenders to utilize
and be productive with the runtime, which is a lower bar. The branch will
help in this regard.
Dave
----- Original Message -----
From: "Raymond Feng" <en...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Thursday, February 08, 2007 2:28 PM
Subject: Re: Content for next milestone
> Hi,
>
> First of all, I think it's really helpful to have a public list which is
> collaboratively maintained by the community to capture the To-Dos in one
> place instead of having them being buried in thousands of notes on the ML.
> I
> would appreciate the compilation effort. AFAIK, some of the items are
> known
> issues which have been either reported by JIRA issues or discussed on the
> ML. The others reflect the latest changes from the SCA spec. I don't treat
> it as a private list as it has been posted publicly and made open to the
> community (via wiki) and quite a few of us have started to sign up for the
> tasks by updating the list. To me, the list is a collection of items that
> either have been discussed and or being discussed in the community. In
> term
> of the contents, it seems to me that most of them are really to fill the
> gaps in Tuscany to better align with the latest SCA spec (AFAIK, it's
> getting close to 1.0 level). I think these pieces are critical (or
> must-have) for Tuscany to reach the SCA spec 1.0 level in the near future.
>
> Secondly, I tend to agree with the proposal to create a branch with all
> the
> stable code so that we can work on it to get some changes done quickly
> without breaking each other base on the observations I had below:
>
> 1) When I tried to apply incremental changes to the pre-spec-changes, but
> the dependencies across the two streams just slow me down.The samples,
> itest
> suites and "test" in the trunk has dependencies on the kernel and
> databindings in the pre-spec-changes branch. And most of the time, I have
> to
> jump between the two streams to build modules and refresh my Eclipse
> workspace (the dependencies are now referenced using jars instead of
> projects) to see through the effects.
>
> 2) When I feel ready to start to evolve an extension on top of the latest
> kernel in the trunk, I have to branch the code again as other things in
> the
> pre-spec-changes might depend on it. Please see the ML thread at
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13572.html. I
> wish
> we have copied all the code into the pre-spec-changes branch, then we
> won't
> have the pains in 1) and 2).
>
> 3) The kernel is NOT stable and we cannot even run basic things beyond the
> unit tests. It's very hard to verify the fixes are good for a JIRA. And
> it's
> very painful to refresh the kernel with breaking changes and it takes us
> time to understand the new code. I would think it will be more efficient
> to
> work off a stable branch and later on merge the changes back to the trunk.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jean-Sebastien Delfino" <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Monday, February 05, 2007 5:19 PM
> Subject: Content for next milestone
>
>
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by kelvin goodson <ke...@gmail.com>.
On 08/02/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> First of all, I think it's really helpful to have a public list which is
> collaboratively maintained by the community to capture the To-Dos in one
> place instead of having them being buried in thousands of notes on the ML.
> I
> would appreciate the compilation effort.
+1 I did a similar thing for SDO, and would have been delighted if it had
captured so much attention. the purpose was to collate and to generate
discussion and to provide a single point of reference for any existing or
future member of the community that might want to contribute to the project.
AFAIK, some of the items are known
> issues which have been either reported by JIRA issues or discussed on the
> ML. The others reflect the latest changes from the SCA spec. I don't treat
> it as a private list as it has been posted publicly and made open to the
> community (via wiki) and quite a few of us have started to sign up for the
> tasks by updating the list. To me, the list is a collection of items that
> either have been discussed and or being discussed in the community.
similarly my list was composed of my assessment of high priority jiras,
spec updates and anything that has been discussed on the list. It was
intended as a straw man for discussion that could be extended and altered by
the normal community processes.
---
Kelvin.
In term
> of the contents, it seems to me that most of them are really to fill the
> gaps in Tuscany to better align with the latest SCA spec (AFAIK, it's
> getting close to 1.0 level). I think these pieces are critical (or
> must-have) for Tuscany to reach the SCA spec 1.0 level in the near future.
>
> Secondly, I tend to agree with the proposal to create a branch with all
> the
> stable code so that we can work on it to get some changes done quickly
> without breaking each other base on the observations I had below:
>
> 1) When I tried to apply incremental changes to the pre-spec-changes, but
> the dependencies across the two streams just slow me down.The samples,
> itest
> suites and "test" in the trunk has dependencies on the kernel and
> databindings in the pre-spec-changes branch. And most of the time, I have
> to
> jump between the two streams to build modules and refresh my Eclipse
> workspace (the dependencies are now referenced using jars instead of
> projects) to see through the effects.
>
> 2) When I feel ready to start to evolve an extension on top of the latest
> kernel in the trunk, I have to branch the code again as other things in
> the
> pre-spec-changes might depend on it. Please see the ML thread at
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13572.html. I
> wish
> we have copied all the code into the pre-spec-changes branch, then we
> won't
> have the pains in 1) and 2).
>
> 3) The kernel is NOT stable and we cannot even run basic things beyond the
> unit tests. It's very hard to verify the fixes are good for a JIRA. And
> it's
> very painful to refresh the kernel with breaking changes and it takes us
> time to understand the new code. I would think it will be more efficient
> to
> work off a stable branch and later on merge the changes back to the trunk.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Jean-Sebastien Delfino" <js...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Monday, February 05, 2007 5:19 PM
> Subject: Content for next milestone
>
>
> > 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
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Content for next milestone
Posted by Raymond Feng <en...@gmail.com>.
Hi,
First of all, I think it's really helpful to have a public list which is
collaboratively maintained by the community to capture the To-Dos in one
place instead of having them being buried in thousands of notes on the ML. I
would appreciate the compilation effort. AFAIK, some of the items are known
issues which have been either reported by JIRA issues or discussed on the
ML. The others reflect the latest changes from the SCA spec. I don't treat
it as a private list as it has been posted publicly and made open to the
community (via wiki) and quite a few of us have started to sign up for the
tasks by updating the list. To me, the list is a collection of items that
either have been discussed and or being discussed in the community. In term
of the contents, it seems to me that most of them are really to fill the
gaps in Tuscany to better align with the latest SCA spec (AFAIK, it's
getting close to 1.0 level). I think these pieces are critical (or
must-have) for Tuscany to reach the SCA spec 1.0 level in the near future.
Secondly, I tend to agree with the proposal to create a branch with all the
stable code so that we can work on it to get some changes done quickly
without breaking each other base on the observations I had below:
1) When I tried to apply incremental changes to the pre-spec-changes, but
the dependencies across the two streams just slow me down.The samples, itest
suites and "test" in the trunk has dependencies on the kernel and
databindings in the pre-spec-changes branch. And most of the time, I have to
jump between the two streams to build modules and refresh my Eclipse
workspace (the dependencies are now referenced using jars instead of
projects) to see through the effects.
2) When I feel ready to start to evolve an extension on top of the latest
kernel in the trunk, I have to branch the code again as other things in the
pre-spec-changes might depend on it. Please see the ML thread at
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13572.html. I wish
we have copied all the code into the pre-spec-changes branch, then we won't
have the pains in 1) and 2).
3) The kernel is NOT stable and we cannot even run basic things beyond the
unit tests. It's very hard to verify the fixes are good for a JIRA. And it's
very painful to refresh the kernel with breaking changes and it takes us
time to understand the new code. I would think it will be more efficient to
work off a stable branch and later on merge the changes back to the trunk.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <js...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, February 05, 2007 5:19 PM
Subject: Content for next milestone
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Where development happens ...
Posted by Jeremy Boynes <jb...@apache.org>.
Patches for new functionality such as this should be submitted
against trunk.
--
Jeremy
On Feb 7, 2007, at 5:16 AM, 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 7, 2007, at 10:48 AM, Venkata Krishnan wrote:
> Hi,
>
> Heres my opinion from the perspective of some items that I have
> owned up to
> do quite a while back - support for complex properties and multivalued
> properties. I'd see them as some fundamental things that a user might
> expect to see out of our next milestone and am happy that they are
> a part of
> this list that Sebastien has proposed.
I think this is good - there's a lot of value in this feature. But as
far as it being on "Sebastien's list", to be blunt from a community
perspective that's irrelevant. It's on /your/ list of things that are
important and that's what matters.
>
> Now to complete this, I am in dire need for a stable runtime and
> client
> API. I need this for two reasons i) to figure out the workings of the
> kernel through debugging so that I may implement these features
> according to
> the framework's design (with loaders, builders, etc.) and ii) to
> test if the
> whole thing sews up together and works as expected. I am just not
> able to
> figure out how to do this from the current trunk andI have already
> started
> to plead for help in this regard from the community
>
> I have no complaints about the work that is going on presently in
> the kernel
> - infact I am excited about the vision with which its being
> driven. But
> then, I'd be happy if I could do my parts as well alongside.
It's important that we can work together on this and the modules in
the codebase are intended to allow this. The feature you are talking
about seems, to me, to be a kernel feature and as such should be
integrated in and tested with the kernel. The kernel can be build,
tested and debugged without any runtime at all and in terms of kernel
development that is an important aspect to maintain. This feature
should work in every runtime that picks up the kernel and hence
testing should not depend on any runtime.
I hadn't picked up from previous mails that you were looking for help
testing and debugging the kernel - to me they seemed to be about
running application code. Please can you repost them in kernel terms
and let's figure them out.
>
> Here are my thoughts for the path forward...
> - I'd like us to plan for the next milestone release ideally by end
> of March
> to feed the curiosity of our users. Having a long gap will kill their
> interest in our technology.
I agree, I think frequent releases are important. That seems to be
inline with what Jim and Ant were proposing (smaller and sooner).
> - I'd deem the current kernel work as well as the items listed by
> Sebastien
> as equally important, but we probably need to figure out how we can
> do both
> parallely. Can we not do an incremental development of both? For
> example
> we could baseline a stable and functioning version of the kernel
> and runtime
> and then choose those items from Sebastien's list that can be
> implemented
> over this baseline. Or maybe do the viceversa, choose the items
> and bring
> the kernel up to a level to be able to support its implementation.
> Going
> forward with both in increments will also help us to merge forward
> easily, I
> would imagine.
I don't get the issue here. We have several people working in the
kernel at the moment on different features - commits from me,
jmarino, meerajk, rfeng, svkrish in the last 24 hours. This is all
evolutionary development of stuff which will be in the next /kernel/
release.
> - I don't think its would be a good idea for the items in
> Sebastien's list
> to wait until the ongoing work in the kernel and runtime is complete.
I really don't give a flying rat's patootie about what's on a list
developed outside the community.
>
> I think Jeremy's point that we have to stop and now look what we
> are doing
> as a community is valid. We must have to get things around so that
> everybody
> in the community is able to contribute effectively.
>
Those are concrete issues that we can tackle. The pre-spec branch was
meant to provide an environment that would let people develop
extensions whilst the kernel was evolving given we know having
everything merged does not work. If it's not working either, let's do
something different.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Angel Todorov wrote:
> Hi All,
>
> Are there any plans for Tuscany to actually use the Axis2 runtime
> (whole infrastructure), not only its libs for specific parts of the
> SOAP processing? I think it is very important to use one uniform
> stack, and not have different runtimes. The axis2 WS runtime is more
> mature, and more advanced. Could you comment on what the efforts are
> to do this migration? Maybe I can also help... Thanks.
>
> Best,
> Angel
>
We are already using parts of the Axis2 infrastructure in addition to
the obvious use of the Axis2 runtime in our WS/SOAP binding:
- Our Axiom databinding can be used independent of SOAP, to convert
from another databinding to an Axiom model
- We are using the Axis2 WSDL2Java code generators, and this goes beyond
Web Services as with SCA all components can mix WSDL portTypes and Java
interfaces.
We could probably reuse more from Axis2 or improve how we use it... and
we could use help as well :) What did you have in mind?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Angel Todorov <at...@gmail.com>.
Hi All,
Are there any plans for Tuscany to actually use the Axis2 runtime
(whole infrastructure), not only its libs for specific parts of the
SOAP processing? I think it is very important to use one uniform
stack, and not have different runtimes. The axis2 WS runtime is more
mature, and more advanced. Could you comment on what the efforts are
to do this migration? Maybe I can also help... Thanks.
Best,
Angel
On 2/9/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Sam Ruby wrote:
> > On 2/8/07, Jim Marino <jm...@myromatours.com> wrote:
> >>
> >> - To satisfy those requirements, is the intent to do that significant
> >> work in branch and how will it be moved into trunk? Or, is it
> >> intended that the work be done in trunk and rolled into branch?
> >
> > In times like these, generally the intent is to do the work and then
> > to assess based on taking a look at the actual code what the best path
> > forward is. Until that code is written, it is premature to speculate
> > what the outcome will be.
> >
> >> - If it is the latter, how is this any different than the process of
> >> using Maven snapshots that we have already set up?
> >>
> >> - If the goal is to do significant work in branch, what happens when
> >> changes in trunk are incompatible with new work in the branch?
> >
> > As I understand it, the goal is to do whatever it takes to get some
> > specific user scenarios working. Whatever it takes generally includes
> > changes.
> >
> > Given the discussion to date, I think that it is taken as a given that
> > some portion of the changes in the trunk will be incompatible with the
> > work done in this branch. The only way to prevent this is to either
> > cease work on the trunk, continue to impede progress towards getting
> > these scenarios working, or a branch.
> >
> >> I'm all for people doing revolutions or blowing off steam but more
> >> clarity and discussion about what is going on would be helpful for me.
> >
> > Referring to this as "blowing off steam" is counter productive.
> > Getting the scenarios working is productive, even if only 85%, 65%, or
> > 35% of the work ultimately ends up being reusable.
> >
> >> The other question I had is how this relates to the release process
> >> others of us are working toward that was started back in January. I
> >> think having this branch called the "next milestone" release is
> >> confusing. I'm all for simultaneous release processes if that helps
> >> ease friction or provides people what they need but what then do we
> >> call the work going on in trunk? In keeping with our Italian theme
> >> and the idea of blowing off smoke, maybe the branch can be tagged
> >> "fumo" :-) Are there some precedents for this in other projects?
> >
> > This I agree with. Statements or nomenclature that imply any form of
> > succession cause friction.
> >
>
> I had not seen your "fumo" proposal as I was busy creating the branch
> and assessing what will need to be adjusted to be able to build it, but
> I agree too. I couldn't think of a good name like "fumo" :) so I called
> it sca-java-integration, a branch where I'd like to start integration
> work and get end to end scenarios and integration tests going.
>
> >> Jim
> >
> > - Sam Ruby
> >
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jim Marino <jm...@myromatours.com>.
> away in PHP and C++ land. But I've only this week started again to
> think
> about looking back at getting the various runtimes to play together
> having
> not looked at Java SCA since M1 days.
That would be cool. We're getting the federated pieces in place and
are using JXTA which has a C++ implementation.
> Back then I got put off because of
> the revolution moving from M1 to the M2 approach made it very
> difficult, for
> the Java SCA novice like me at least, to do anything sensible. My
> timing
> must be really messed up because I'm now looking at this thread with a
> certain sense of Deja Vu. I'm interested in being able to test
> running Java
> SCA composites over the coming weeks. Not absolutely convinced I
> need a
> system supporting all the 1.0 features this minute but clearly it
> would be
> good not to be prevented from moving in that direction.
You probably have several options we'd be happy to help get you spun
up with:
- If you want a (relatively) stable, tested release, I would try M2.
The downside is it is based of the .95 SCA spec. For starting our and
developing apps, I would use this.
- If you want a slightly more updated version for creating runtime
extensions, the pre-spec snapshot should be relatively stable. The
changes from the M2 release are constrained so if you were more
interested in developing an extension on a stable release, I would go
with it.
- If you want to develop against the 1.0 spec, we're pretty close in
trunk to getting support for a good chunk of the 1.0 client APIs.
Meeraj has also made a lot of progress on defining the discovery and
federation messages. Perhaps we could work together on those so the
Java and C++ runtime can federate as a starting point?
I'm happy to help so drop a line on the list.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Simon Laws <si...@googlemail.com>.
On 2/8/07, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On 2/8/07, Jeremy Boynes <jb...@apache.org> wrote:
> > On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote:
> >
> > > On 2/8/07, Jeremy Boynes <jb...@apache.org> wrote:
> > >> >
> > >> > So I think we need a branch to do this stabilization work
> > >>
> > >> I'm disturbed by this proposal as I don't think we have consensus in
> > >> the community yet on this issue.
> > >
> > > This is not an issue that requires consensus. I've referred
> > > previously to a memo tited 'rules for revolutionaries'[1] which
> > > addresses the need to reduce friction in times like these.
> >
> > Consensus may have been the wrong word - common understanding of what
> > the branch is for might have been better phrasing. There's been talk
> > about stabilizing for a release (which is often when branches are
> > used for), but also about developing new features (which is usually
> > done in trunk). Is this someone's personal environment, or a
> > revolution? I simply don't know.
>
> It actually is unknowable. It is the nature of the work.
>
> The branch could go nowhere. It could become the basis for people to
> quickly these scenarios to the trunk. It could expose problems
> earlier than would otherwise be found on the trunk.
>
> At a minimum, it will not disrupt continued progress on the trunk, and
> by being done in the open and under a compatible license, it can be
> readily cannibalized at any point.
>
> > I think consensus here though is important - not on whether we create
> > a branch but in the impact this has on how we develop as a community.
> > We were working together, all of a sudden something has changed and
> > now we have friction. That's what we need to fix.
>
> Reviewing the archives, what I see is mounting frustration, one that
> would benefit from a release valve. No-one seems to be questioning
> that the work that is going on in the trunk is necessary, the only is
> growing recognition that more parallelism is required.
>
> > >> If the issue here is that trunk is unstable, then we should stabilize
> > >> trunk.
> > >
> > > That would be wonderful. But let's put that in concrete terms. At
> > > least one individual (and possibly several) is interested in working
> > > on the 'BigBank' end to end scenario. Other (others?) are interested
> > > in verifying fixes to issues reported in JIRA.
> > >
> > > Which would minimize friction more? Allowing that work to proceed in
> > > a branch, or for that individual (or individuals) to start exercising
> > > their right to veto any change that impedes their progress? The
> > > latter approach would put a significant, albeit short term, damper on
> > > refactoring efforts, independent of the long term value in said
> > > refactoring.
> > >
> > > So, to put a not so fine point on it, it would represent essentially a
> > > moratorium on all but the most insignificant refactoring efforts.
> > >
> > > Is that what this group wants?
> >
> > I don't know.
>
> Actually, I would seriously doubt it.
>
> > One of the factors here is the change in the spec APIs from 0.95 to
> > 1.0 which had many incompatible changes. I think we all want to
> > support 1.0 but reality is that all of our samples, "end-to-end
> > scenarios" and itests are written against the 0.95 level. We knew
> > evolution to 1.0 would be disruptive which is why we have a "pre-
> > spec" branch as a baseline for ongoing development at the 0.95 level;
> > it seems like some friction is coming because this is not working and
> > perhaps tackling that will make things smoother.
>
> Perhaps. But it is also possible that a branch that is closer to the
> current trunk would be less disruptive long term. And not necessarily
> just one branch, this process could conceivably even repeat
> periodically, and eventually converge.
>
> > People have talked about working on scenarios and Jira issues, but
> > it's not clear if they are intending to do that at the 0.95 level or
> > at the 1.0 level. If at the 1.0 level, the harsh reality is that we
> > don't have a 1.0 level runtime yet to support them - some of us are
> > working on it but it's not done yet. I think joining in that work is
> > the most effective way to get something that can run 1.0 level
> > scenarios, but if people want to start a branch and do it there
> > that's cool too.
>
> At some point you hit the mythical man month "nine women, one baby" issue.
>
> re: "if people want to start a branch and do it there that's cool too."
>
> +1
>
> > > If so, another way to proceed is for the project to adopt a 'review
> > > then commit model', whereby all changes are proposed for discussion
> > > and voted on before commits are made. Projects which place a high
> > > premium on stability, like the Apache HTTPD project operate in this
> > > way everyday.
> >
> > I've been wondering about that too - not for stability, but for the
> > community-building aspect. It's certainly a better option than
> > throwing vetos around.
>
> Geronimo recently had this imposed on them. It was just the jolt that
> they needed, but once that was accomplished, it was quickly disposed
> of. My thoughts are that it is an option to consider, but one not to
> be taken lightly.
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> I can't speak from a java SCA developers perspective. I 've been tucked
away in PHP and C++ land. But I've only this week started again to think
about looking back at getting the various runtimes to play together having
not looked at Java SCA since M1 days. Back then I got put off because of
the revolution moving from M1 to the M2 approach made it very difficult, for
the Java SCA novice like me at least, to do anything sensible. My timing
must be really messed up because I'm now looking at this thread with a
certain sense of Deja Vu. I'm interested in being able to test running Java
SCA composites over the coming weeks. Not absolutely convinced I need a
system supporting all the 1.0 features this minute but clearly it would be
good not to be prevented from moving in that direction. I'm no fan of branch
and merge either but I guess I'm saying I would like two things which
appear, from this thread, to be at odds at the moment, i.e. a reasonably
stable and up to date-ish integration environment and the continued
development of the trunk toward the bells and whistles 1.0 environment.
Simon
Re: Content for next milestone
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Sam Ruby wrote:
> On 2/8/07, Jim Marino <jm...@myromatours.com> wrote:
>>
>> - To satisfy those requirements, is the intent to do that significant
>> work in branch and how will it be moved into trunk? Or, is it
>> intended that the work be done in trunk and rolled into branch?
>
> In times like these, generally the intent is to do the work and then
> to assess based on taking a look at the actual code what the best path
> forward is. Until that code is written, it is premature to speculate
> what the outcome will be.
>
>> - If it is the latter, how is this any different than the process of
>> using Maven snapshots that we have already set up?
>>
>> - If the goal is to do significant work in branch, what happens when
>> changes in trunk are incompatible with new work in the branch?
>
> As I understand it, the goal is to do whatever it takes to get some
> specific user scenarios working. Whatever it takes generally includes
> changes.
>
> Given the discussion to date, I think that it is taken as a given that
> some portion of the changes in the trunk will be incompatible with the
> work done in this branch. The only way to prevent this is to either
> cease work on the trunk, continue to impede progress towards getting
> these scenarios working, or a branch.
>
>> I'm all for people doing revolutions or blowing off steam but more
>> clarity and discussion about what is going on would be helpful for me.
>
> Referring to this as "blowing off steam" is counter productive.
> Getting the scenarios working is productive, even if only 85%, 65%, or
> 35% of the work ultimately ends up being reusable.
>
>> The other question I had is how this relates to the release process
>> others of us are working toward that was started back in January. I
>> think having this branch called the "next milestone" release is
>> confusing. I'm all for simultaneous release processes if that helps
>> ease friction or provides people what they need but what then do we
>> call the work going on in trunk? In keeping with our Italian theme
>> and the idea of blowing off smoke, maybe the branch can be tagged
>> "fumo" :-) Are there some precedents for this in other projects?
>
> This I agree with. Statements or nomenclature that imply any form of
> succession cause friction.
>
I had not seen your "fumo" proposal as I was busy creating the branch
and assessing what will need to be adjusted to be able to build it, but
I agree too. I couldn't think of a good name like "fumo" :) so I called
it sca-java-integration, a branch where I'd like to start integration
work and get end to end scenarios and integration tests going.
>> Jim
>
> - Sam Ruby
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Sam Ruby <ru...@apache.org>.
On 2/8/07, Jim Marino <jm...@myromatours.com> wrote:
>
> - To satisfy those requirements, is the intent to do that significant
> work in branch and how will it be moved into trunk? Or, is it
> intended that the work be done in trunk and rolled into branch?
In times like these, generally the intent is to do the work and then
to assess based on taking a look at the actual code what the best path
forward is. Until that code is written, it is premature to speculate
what the outcome will be.
> - If it is the latter, how is this any different than the process of
> using Maven snapshots that we have already set up?
>
> - If the goal is to do significant work in branch, what happens when
> changes in trunk are incompatible with new work in the branch?
As I understand it, the goal is to do whatever it takes to get some
specific user scenarios working. Whatever it takes generally includes
changes.
Given the discussion to date, I think that it is taken as a given that
some portion of the changes in the trunk will be incompatible with the
work done in this branch. The only way to prevent this is to either
cease work on the trunk, continue to impede progress towards getting
these scenarios working, or a branch.
> I'm all for people doing revolutions or blowing off steam but more
> clarity and discussion about what is going on would be helpful for me.
Referring to this as "blowing off steam" is counter productive.
Getting the scenarios working is productive, even if only 85%, 65%, or
35% of the work ultimately ends up being reusable.
> The other question I had is how this relates to the release process
> others of us are working toward that was started back in January. I
> think having this branch called the "next milestone" release is
> confusing. I'm all for simultaneous release processes if that helps
> ease friction or provides people what they need but what then do we
> call the work going on in trunk? In keeping with our Italian theme
> and the idea of blowing off smoke, maybe the branch can be tagged
> "fumo" :-) Are there some precedents for this in other projects?
This I agree with. Statements or nomenclature that imply any form of
succession cause friction.
> Jim
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: sca-java-integration branch, was: Content for next milestone
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 9, 2007, at 5:48 PM, Raymond Feng wrote:
> Hi,
>
> I have changed the branch to use "0.1-integration-incubating-
> SNAPSHOT" as the version id.
Thanks
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: sca-java-integration branch, was: Content for next milestone
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I have changed the branch to use "0.1-integration-incubating-SNAPSHOT" as
the version id.
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Friday, February 09, 2007 8:36 AM
Subject: Re: sca-java-integration branch, was: Content for next milestone
> To prevent confusion with trunk, please change the artifactIds for this
> branch (I'd suggest using a different groupId or version).
>
> Thanks
> --
> Jeremy
>
>
> On Feb 8, 2007, at 7:05 PM, Jean-Sebastien Delfino wrote:
>
>> [snip]
>>>> People have talked about working on scenarios and Jira issues, but
>>>> it's not clear if they are intending to do that at the 0.95 level or
>>>> at the 1.0 level. If at the 1.0 level, the harsh reality is that we
>>>> don't have a 1.0 level runtime yet to support them - some of us are
>>>> working on it but it's not done yet. I think joining in that work is
>>>> the most effective way to get something that can run 1.0 level
>>>> scenarios, but if people want to start a branch and do it there
>>>> that's cool too.
>>>
>>> At some point you hit the mythical man month "nine women, one baby"
>>> issue.
>>>
>>> re: "if people want to start a branch and do it there that's cool too."
>>>
>>> +1
>>>
>>
>> +1
>>
>> I have copied java/spec/, sca/, samples/, sampleapps/, testing/,
>> buildtools/ and pom/ from revision r502852 to a new branch under
>> branches/sca-java-integration/.
>>
>> I would like to start using this branch for integration and
>> stabilization of our runtime and get a complete system and end to end
>> scenarios incl. Bigbank plus our integration tests working again. As a
>> starting point I'd like to see a smooth top-down build of all the pieces
>> so I'm going to start adjusting a little the pom.xml files. If anybody
>> is interested in helping with this effort, please jump in.
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: sca-java-integration branch, was: Content for next milestone
Posted by Jeremy Boynes <jb...@apache.org>.
To prevent confusion with trunk, please change the artifactIds for
this branch (I'd suggest using a different groupId or version).
Thanks
--
Jeremy
On Feb 8, 2007, at 7:05 PM, Jean-Sebastien Delfino wrote:
> [snip]
>>> People have talked about working on scenarios and Jira issues, but
>>> it's not clear if they are intending to do that at the 0.95 level or
>>> at the 1.0 level. If at the 1.0 level, the harsh reality is that we
>>> don't have a 1.0 level runtime yet to support them - some of us are
>>> working on it but it's not done yet. I think joining in that work is
>>> the most effective way to get something that can run 1.0 level
>>> scenarios, but if people want to start a branch and do it there
>>> that's cool too.
>>
>> At some point you hit the mythical man month "nine women, one
>> baby" issue.
>>
>> re: "if people want to start a branch and do it there that's cool
>> too."
>>
>> +1
>>
>
> +1
>
> I have copied java/spec/, sca/, samples/, sampleapps/, testing/,
> buildtools/ and pom/ from revision r502852 to a new branch under
> branches/sca-java-integration/.
>
> I would like to start using this branch for integration and
> stabilization of our runtime and get a complete system and end to
> end scenarios incl. Bigbank plus our integration tests working
> again. As a starting point I'd like to see a smooth top-down build
> of all the pieces so I'm going to start adjusting a little the
> pom.xml files. If anybody is interested in helping with this
> effort, please jump in.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
sca-java-integration branch, was: Content for next milestone
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
>> People have talked about working on scenarios and Jira issues, but
>> it's not clear if they are intending to do that at the 0.95 level or
>> at the 1.0 level. If at the 1.0 level, the harsh reality is that we
>> don't have a 1.0 level runtime yet to support them - some of us are
>> working on it but it's not done yet. I think joining in that work is
>> the most effective way to get something that can run 1.0 level
>> scenarios, but if people want to start a branch and do it there
>> that's cool too.
>
> At some point you hit the mythical man month "nine women, one baby"
> issue.
>
> re: "if people want to start a branch and do it there that's cool too."
>
> +1
>
+1
I have copied java/spec/, sca/, samples/, sampleapps/, testing/,
buildtools/ and pom/ from revision r502852 to a new branch under
branches/sca-java-integration/.
I would like to start using this branch for integration and
stabilization of our runtime and get a complete system and end to end
scenarios incl. Bigbank plus our integration tests working again. As a
starting point I'd like to see a smooth top-down build of all the pieces
so I'm going to start adjusting a little the pom.xml files. If anybody
is interested in helping with this effort, please jump in.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jim Marino <jm...@myromatours.com>.
> It actually is unknowable. It is the nature of the work.
>
> The branch could go nowhere. It could become the basis for people to
> quickly these scenarios to the trunk. It could expose problems
> earlier than would otherwise be found on the trunk.
>
> At a minimum, it will not disrupt continued progress on the trunk, and
> by being done in the open and under a compatible license, it can be
> readily cannibalized at any point.
>
I wanted to know if the goal was to develop against trunk or to
develop against branch. Wouldn't people know this at the outset, i.e.
what the purpose of branching is? I realize goals may change as
things evolve but it would be nice to know what the initial
objectives are. Those are still unclear to me. Sebastien mentioned,
"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". Yet the list of
"requirements" he put on the wiki entail significant additions to the
existing architecture. For example, the runtime and client api are
changed in the SCA specifications, which means none of the existing
samples (e.g. BigBank) or runtimes work on any revision of the code
base.
So, what would really help me is for someone to clarify for me the
following:
- To satisfy those requirements, is the intent to do that significant
work in branch and how will it be moved into trunk? Or, is it
intended that the work be done in trunk and rolled into branch?
- If it is the latter, how is this any different than the process of
using Maven snapshots that we have already set up?
- If the goal is to do significant work in branch, what happens when
changes in trunk are incompatible with new work in the branch?
I'm all for people doing revolutions or blowing off steam but more
clarity and discussion about what is going on would be helpful for me.
The other question I had is how this relates to the release process
others of us are working toward that was started back in January. I
think having this branch called the "next milestone" release is
confusing. I'm all for simultaneous release processes if that helps
ease friction or provides people what they need but what then do we
call the work going on in trunk? In keeping with our Italian theme
and the idea of blowing off smoke, maybe the branch can be tagged
"fumo" :-) Are there some precedents for this in other projects?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Sam Ruby <ru...@intertwingly.net>.
On 2/8/07, Jeremy Boynes <jb...@apache.org> wrote:
> On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote:
>
> > On 2/8/07, Jeremy Boynes <jb...@apache.org> wrote:
> >> >
> >> > So I think we need a branch to do this stabilization work
> >>
> >> I'm disturbed by this proposal as I don't think we have consensus in
> >> the community yet on this issue.
> >
> > This is not an issue that requires consensus. I've referred
> > previously to a memo tited 'rules for revolutionaries'[1] which
> > addresses the need to reduce friction in times like these.
>
> Consensus may have been the wrong word - common understanding of what
> the branch is for might have been better phrasing. There's been talk
> about stabilizing for a release (which is often when branches are
> used for), but also about developing new features (which is usually
> done in trunk). Is this someone's personal environment, or a
> revolution? I simply don't know.
It actually is unknowable. It is the nature of the work.
The branch could go nowhere. It could become the basis for people to
quickly these scenarios to the trunk. It could expose problems
earlier than would otherwise be found on the trunk.
At a minimum, it will not disrupt continued progress on the trunk, and
by being done in the open and under a compatible license, it can be
readily cannibalized at any point.
> I think consensus here though is important - not on whether we create
> a branch but in the impact this has on how we develop as a community.
> We were working together, all of a sudden something has changed and
> now we have friction. That's what we need to fix.
Reviewing the archives, what I see is mounting frustration, one that
would benefit from a release valve. No-one seems to be questioning
that the work that is going on in the trunk is necessary, the only is
growing recognition that more parallelism is required.
> >> If the issue here is that trunk is unstable, then we should stabilize
> >> trunk.
> >
> > That would be wonderful. But let's put that in concrete terms. At
> > least one individual (and possibly several) is interested in working
> > on the 'BigBank' end to end scenario. Other (others?) are interested
> > in verifying fixes to issues reported in JIRA.
> >
> > Which would minimize friction more? Allowing that work to proceed in
> > a branch, or for that individual (or individuals) to start exercising
> > their right to veto any change that impedes their progress? The
> > latter approach would put a significant, albeit short term, damper on
> > refactoring efforts, independent of the long term value in said
> > refactoring.
> >
> > So, to put a not so fine point on it, it would represent essentially a
> > moratorium on all but the most insignificant refactoring efforts.
> >
> > Is that what this group wants?
>
> I don't know.
Actually, I would seriously doubt it.
> One of the factors here is the change in the spec APIs from 0.95 to
> 1.0 which had many incompatible changes. I think we all want to
> support 1.0 but reality is that all of our samples, "end-to-end
> scenarios" and itests are written against the 0.95 level. We knew
> evolution to 1.0 would be disruptive which is why we have a "pre-
> spec" branch as a baseline for ongoing development at the 0.95 level;
> it seems like some friction is coming because this is not working and
> perhaps tackling that will make things smoother.
Perhaps. But it is also possible that a branch that is closer to the
current trunk would be less disruptive long term. And not necessarily
just one branch, this process could conceivably even repeat
periodically, and eventually converge.
> People have talked about working on scenarios and Jira issues, but
> it's not clear if they are intending to do that at the 0.95 level or
> at the 1.0 level. If at the 1.0 level, the harsh reality is that we
> don't have a 1.0 level runtime yet to support them - some of us are
> working on it but it's not done yet. I think joining in that work is
> the most effective way to get something that can run 1.0 level
> scenarios, but if people want to start a branch and do it there
> that's cool too.
At some point you hit the mythical man month "nine women, one baby" issue.
re: "if people want to start a branch and do it there that's cool too."
+1
> > If so, another way to proceed is for the project to adopt a 'review
> > then commit model', whereby all changes are proposed for discussion
> > and voted on before commits are made. Projects which place a high
> > premium on stability, like the Apache HTTPD project operate in this
> > way everyday.
>
> I've been wondering about that too - not for stability, but for the
> community-building aspect. It's certainly a better option than
> throwing vetos around.
Geronimo recently had this imposed on them. It was just the jolt that
they needed, but once that was accomplished, it was quickly disposed
of. My thoughts are that it is an option to consider, but one not to
be taken lightly.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jeremy Boynes <jb...@apache.org>.
On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote:
> On 2/8/07, Jeremy Boynes <jb...@apache.org> wrote:
>> >
>> > So I think we need a branch to do this stabilization work
>>
>> I'm disturbed by this proposal as I don't think we have consensus in
>> the community yet on this issue.
>
> This is not an issue that requires consensus. I've referred
> previously to a memo tited 'rules for revolutionaries'[1] which
> addresses the need to reduce friction in times like these.
Consensus may have been the wrong word - common understanding of what
the branch is for might have been better phrasing. There's been talk
about stabilizing for a release (which is often when branches are
used for), but also about developing new features (which is usually
done in trunk). Is this someone's personal environment, or a
revolution? I simply don't know.
I think consensus here though is important - not on whether we create
a branch but in the impact this has on how we develop as a community.
We were working together, all of a sudden something has changed and
now we have friction. That's what we need to fix.
>
>> If the issue here is that trunk is unstable, then we should stabilize
>> trunk.
>
> That would be wonderful. But let's put that in concrete terms. At
> least one individual (and possibly several) is interested in working
> on the 'BigBank' end to end scenario. Other (others?) are interested
> in verifying fixes to issues reported in JIRA.
>
> Which would minimize friction more? Allowing that work to proceed in
> a branch, or for that individual (or individuals) to start exercising
> their right to veto any change that impedes their progress? The
> latter approach would put a significant, albeit short term, damper on
> refactoring efforts, independent of the long term value in said
> refactoring.
>
> So, to put a not so fine point on it, it would represent essentially a
> moratorium on all but the most insignificant refactoring efforts.
>
> Is that what this group wants?
I don't know.
One of the factors here is the change in the spec APIs from 0.95 to
1.0 which had many incompatible changes. I think we all want to
support 1.0 but reality is that all of our samples, "end-to-end
scenarios" and itests are written against the 0.95 level. We knew
evolution to 1.0 would be disruptive which is why we have a "pre-
spec" branch as a baseline for ongoing development at the 0.95 level;
it seems like some friction is coming because this is not working and
perhaps tackling that will make things smoother.
People have talked about working on scenarios and Jira issues, but
it's not clear if they are intending to do that at the 0.95 level or
at the 1.0 level. If at the 1.0 level, the harsh reality is that we
don't have a 1.0 level runtime yet to support them - some of us are
working on it but it's not done yet. I think joining in that work is
the most effective way to get something that can run 1.0 level
scenarios, but if people want to start a branch and do it there
that's cool too.
>
> If so, another way to proceed is for the project to adopt a 'review
> then commit model', whereby all changes are proposed for discussion
> and voted on before commits are made. Projects which place a high
> premium on stability, like the Apache HTTPD project operate in this
> way everyday.
I've been wondering about that too - not for stability, but for the
community-building aspect. It's certainly a better option than
throwing vetos around.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Sam Ruby <ru...@apache.org>.
On 2/8/07, Jeremy Boynes <jb...@apache.org> wrote:
> >
> > So I think we need a branch to do this stabilization work
>
> I'm disturbed by this proposal as I don't think we have consensus in
> the community yet on this issue.
This is not an issue that requires consensus. I've referred
previously to a memo tited 'rules for revolutionaries'[1] which
addresses the need to reduce friction in times like these.
> If the issue here is that trunk is unstable, then we should stabilize
> trunk.
That would be wonderful. But let's put that in concrete terms. At
least one individual (and possibly several) is interested in working
on the 'BigBank' end to end scenario. Other (others?) are interested
in verifying fixes to issues reported in JIRA.
Which would minimize friction more? Allowing that work to proceed in
a branch, or for that individual (or individuals) to start exercising
their right to veto any change that impedes their progress? The
latter approach would put a significant, albeit short term, damper on
refactoring efforts, independent of the long term value in said
refactoring.
So, to put a not so fine point on it, it would represent essentially a
moratorium on all but the most insignificant refactoring efforts.
Is that what this group wants?
If so, another way to proceed is for the project to adopt a 'review
then commit model', whereby all changes are proposed for discussion
and voted on before commits are made. Projects which place a high
premium on stability, like the Apache HTTPD project operate in this
way everyday.
- Sam Ruby
[1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 8, 2007, at 6:28 AM, Geoffrey Winn wrote:
> Does it do any actual harm to have a branch, even if not everyone
> thinks
> it's necessary?
I would say it depends on the purpose of the branch. If the intent is
stabilization for a release where only bug fixes are introduced, then
I think it is a good thing since it allows development (e.g. new
features) to continue in trunk without disrupting the release. There
is also the case of revolution or experimentation where people want
to try out radically new ideas; it seems like sandbox is a better
place for that type of work. Another case is new development on an
existing codeline, e.g. SCA .95, which seems appropriate for a branch.
However, I'm not sure either of those are a goal of the current
branch proposal. The list of "requirements" posted to the wiki entail
a significant number of new features that are intended to be done in
trunk (e.g. "support for SCA 1.0"). It doesn't seem like the goal is
revolution. For example, Sebastien mentioned his criteria for
integrating new code developed in trunk: "I'll be happy to
synchronize with pieces of it [kernel trunk], as long as the samples
and integration tests work".
Maybe someone could explain the goals of the branch? Specifically, it
would help me if someone could answer a few questions:
- Is development going to take place there or is it just to
"stabilize" for a release?
- If development is going to take place, is it for SCA .95 or SCA 1.0?
- Why can't new development be done in trunk? It would be
particularly helpful to understand specifics so that people working
in kernel and other areas can resolve them.
- What code would serve as the basis of the branch? For example, M2
or another tag?
> Presumably that gives the people that want stability a place
> to work and at worst they've bought themselves some extra work
> merging back
> into the main development stream later.
>
> My previous experience (3 major occasions) has been that code
> branches often
> turn out to be more trouble than they are worth, but just
> occasionally they
> can be the right answer.
>
My experience has been the same. I'd really like to understand the
intent of branching a little more, and specifically how it relates to
the release work already underway in trunk.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Geoffrey Winn <ge...@googlemail.com>.
Does it do any actual harm to have a branch, even if not everyone thinks
it's necessary? Presumably that gives the people that want stability a place
to work and at worst they've bought themselves some extra work merging back
into the main development stream later.
My previous experience (3 major occasions) has been that code branches often
turn out to be more trouble than they are worth, but just occasionally they
can be the right answer.
Geoff.
On 08/02/07, Jeremy Boynes <jb...@apache.org> wrote:
>
> On 2/7/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > Like Venkat I'm also looking for a more stable runtime environment.
> >
> > I want that stable environment to bring-up end to end scenarios,
> > including Bigbank, variations of BigBank and Calculator similar to what
> > we've been running with the C++ runtime, our integration test suite, and
> > the new integration test cases that I want to add to cover the
> > requirements on the Wiki. Right now I can't get even simple samples
> > working with the trunk and we can't run any integration tests as the
> > itest plugin does not even compile. I understand why the kernel is
> > evolving so much and so quickly and this is good and exciting, but
> > integrating all the pieces and making the fixes and improvements here
> > and there to get the end to end story working is difficult enough...
> > that we can't be distracted or broken all the time by the refactoring
> > and ongoing changes in the trunk.
> >
> > So I think we need a branch to do this stabilization work, with the goal
> > of having the scenarios and integration tests in place by March. I think
> > that it will be good for the project if people interested in stabilizing
> > and improving basic function can do it in a more stable environment
> > while the kernel is getting refactored in parallel. When the trunk
> > settles I'll be happy to synchronize with pieces of it, as long as the
> > samples and integration tests work. I'll try to create the branch some
> > time tomorrow morning (Thursday) PST.
>
> I'm disturbed by this proposal as I don't think we have consensus in
> the community yet on this issue.
>
> If the issue here is that trunk is unstable, then we should stabilize
> trunk. None of the current samples will run against trunk because they
> are still using the 0.95 apis. I have updated kernel to use the 1.0
> ones and I am in the process of implementing the proposal I made on
> the list on how to migrate the runtime. I could certainly use help
> migrating the samples and itests to 1.0.
>
> If the purpose of the stabilization branch is to prep for a release
> (like we did with M2), I would like to know what we are planning to
> release. There's a list of "requirements" on the wiki but we've not
> discussed those as a community at all. Most of them pertain to new
> functionality and I struggle to see how we can "stabilize" code that
> is not yet written.
>
> If the purpose is to implement new features, we have a place for that:
> trunk. Things like complex properties, XML ordering, contribution
> processing, and assembly changes are all kernel features and can all
> be implemented in the kernel's trunk without dependency on any
> runtime.
>
> --
> Jeremy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Content for next milestone
Posted by Jeremy Boynes <jb...@apache.org>.
On 2/7/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Like Venkat I'm also looking for a more stable runtime environment.
>
> I want that stable environment to bring-up end to end scenarios,
> including Bigbank, variations of BigBank and Calculator similar to what
> we've been running with the C++ runtime, our integration test suite, and
> the new integration test cases that I want to add to cover the
> requirements on the Wiki. Right now I can't get even simple samples
> working with the trunk and we can't run any integration tests as the
> itest plugin does not even compile. I understand why the kernel is
> evolving so much and so quickly and this is good and exciting, but
> integrating all the pieces and making the fixes and improvements here
> and there to get the end to end story working is difficult enough...
> that we can't be distracted or broken all the time by the refactoring
> and ongoing changes in the trunk.
>
> So I think we need a branch to do this stabilization work, with the goal
> of having the scenarios and integration tests in place by March. I think
> that it will be good for the project if people interested in stabilizing
> and improving basic function can do it in a more stable environment
> while the kernel is getting refactored in parallel. When the trunk
> settles I'll be happy to synchronize with pieces of it, as long as the
> samples and integration tests work. I'll try to create the branch some
> time tomorrow morning (Thursday) PST.
I'm disturbed by this proposal as I don't think we have consensus in
the community yet on this issue.
If the issue here is that trunk is unstable, then we should stabilize
trunk. None of the current samples will run against trunk because they
are still using the 0.95 apis. I have updated kernel to use the 1.0
ones and I am in the process of implementing the proposal I made on
the list on how to migrate the runtime. I could certainly use help
migrating the samples and itests to 1.0.
If the purpose of the stabilization branch is to prep for a release
(like we did with M2), I would like to know what we are planning to
release. There's a list of "requirements" on the wiki but we've not
discussed those as a community at all. Most of them pertain to new
functionality and I struggle to see how we can "stabilize" code that
is not yet written.
If the purpose is to implement new features, we have a place for that:
trunk. Things like complex properties, XML ordering, contribution
processing, and assembly changes are all kernel features and can all
be implemented in the kernel's trunk without dependency on any
runtime.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Venkata Krishnan wrote:
> Hi,
>
> Heres my opinion from the perspective of some items that I have owned
> up to
> do quite a while back - support for complex properties and multivalued
> properties. I'd see them as some fundamental things that a user might
> expect to see out of our next milestone and am happy that they are a
> part of
> this list that Sebastien has proposed.
>
> Now to complete this, I am in dire need for a stable runtime and client
> API. I need this for two reasons i) to figure out the workings of the
> kernel through debugging so that I may implement these features
> according to
> the framework's design (with loaders, builders, etc.) and ii) to test
> if the
> whole thing sews up together and works as expected. I am just not
> able to
> figure out how to do this from the current trunk andI have already
> started
> to plead for help in this regard from the community
>
> I have no complaints about the work that is going on presently in the
> kernel
> - infact I am excited about the vision with which its being driven. But
> then, I'd be happy if I could do my parts as well alongside.
>
> Here are my thoughts for the path forward...
> - I'd like us to plan for the next milestone release ideally by end of
> March
> to feed the curiosity of our users. Having a long gap will kill their
> interest in our technology.
> - I'd deem the current kernel work as well as the items listed by
> Sebastien
> as equally important, but we probably need to figure out how we can do
> both
> parallely. Can we not do an incremental development of both? For
> example
> we could baseline a stable and functioning version of the kernel and
> runtime
> and then choose those items from Sebastien's list that can be implemented
> over this baseline. Or maybe do the viceversa, choose the items and
> bring
> the kernel up to a level to be able to support its implementation. Going
> forward with both in increments will also help us to merge forward
> easily, I
> would imagine.
> - I don't think its would be a good idea for the items in Sebastien's
> list
> to wait until the ongoing work in the kernel and runtime is complete.
>
> I think Jeremy's point that we have to stop and now look what we are
> doing
> as a community is valid. We must have to get things around so that
> everybody
> in the community is able to contribute effectively.
>
> Thanks
>
> - Venkat
>
>
> On 2/7/07, Simon Nash <na...@hursley.ibm.com> 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
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
Like Venkat I'm also looking for a more stable runtime environment.
I want that stable environment to bring-up end to end scenarios,
including Bigbank, variations of BigBank and Calculator similar to what
we've been running with the C++ runtime, our integration test suite, and
the new integration test cases that I want to add to cover the
requirements on the Wiki. Right now I can't get even simple samples
working with the trunk and we can't run any integration tests as the
itest plugin does not even compile. I understand why the kernel is
evolving so much and so quickly and this is good and exciting, but
integrating all the pieces and making the fixes and improvements here
and there to get the end to end story working is difficult enough...
that we can't be distracted or broken all the time by the refactoring
and ongoing changes in the trunk.
So I think we need a branch to do this stabilization work, with the goal
of having the scenarios and integration tests in place by March. I think
that it will be good for the project if people interested in stabilizing
and improving basic function can do it in a more stable environment
while the kernel is getting refactored in parallel. When the trunk
settles I'll be happy to synchronize with pieces of it, as long as the
samples and integration tests work. I'll try to create the branch some
time tomorrow morning (Thursday) PST.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jim Marino <jm...@myromatours.com>.
Hi Venkat,
Thanks for the write-up, comments inline.
Jim
On Feb 7, 2007, at 10:48 AM, Venkata Krishnan wrote:
> Hi,
>
> Heres my opinion from the perspective of some items that I have
> owned up to
> do quite a while back - support for complex properties and multivalued
> properties. I'd see them as some fundamental things that a user might
> expect to see out of our next milestone and am happy that they are
> a part of
> this list that Sebastien has proposed.
>
> Now to complete this, I am in dire need for a stable runtime and
> client
> API. I need this for two reasons i) to figure out the workings of the
> kernel through debugging so that I may implement these features
> according to
> the framework's design (with loaders, builders, etc.)
Debugging and understanding the kernel architecture should be
orthogonal to a stable "runtime" and client API. Otherwise, we have
failed with our architecture design. The kernel architecture should
not be dependent on either the runtime (e.g. how it is embedded) or
the client API.
For example, you should be able to debug various subsystems through
the existing testcases. These, coupled with the posts to the mailing
list describing some of the new work being done, should provide you
with a starting point. Of course, documentation and write-up could
always be better...If you are still having trouble after working
through the testcases, I'm sure people working in particular areas of
concern would be happy to answer any questions you pose.
In terms of the specific work you are interested in, e.g. complex
properties, you should be able to go ahead and work off kernel
without issue. I would follow-up with Meeraj and Jeremy on the loader
side to sync with what they are doing.
> and ii) to test if the
> whole thing sews up together and works as expected. I am just not
> able to
> figure out how to do this from the current trunk andI have already
> started
> to plead for help in this regard from the community
>
I believe Jeremy responded in his launcher post. If not could you
send specifics to the list and someone will try and help out? We need
to update the Maven iTest plugin. I don't think you need to wait for
this, however, to start any of the work you are interested in.
> I have no complaints about the work that is going on presently in
> the kernel
> - infact I am excited about the vision with which its being
> driven. But
> then, I'd be happy if I could do my parts as well alongside.
>
> Here are my thoughts for the path forward...
> - I'd like us to plan for the next milestone release ideally by end
> of March
> to feed the curiosity of our users. Having a long gap will kill their
> interest in our technology.
Agreed that a long gap will kill momentum. That's why I suggested a
compact kernel release back in January, and that's what several of us
are working towards. I think it would be great to have additional
features others may be interested in. What I'm not too keen on is
holding up the kernel release for extensions - that will put us back
in the position we are attempting to get out of with the modularity
work.
That said, having a follow-on release that uses a prior-released
kernel version sounds like a great idea.
> - I'd deem the current kernel work as well as the items listed by
> Sebastien
> as equally important, but we probably need to figure out how we can
> do both
> parallely. Can we not do an incremental development of both?
Don't we get that with modularizing the build as we have done?
Extensions work off a release or snapshot of kernel that evolves over
time. I'm not sure why work on kernel cannot be done in parallel
assuming people coordinate on list.
> For example
> we could baseline a stable and functioning version of the kernel
> and runtime
> and then choose those items from Sebastien's list that can be
> implemented
> over this baseline.
I don't think this is appropriate or really needed. All development
should be done against trunk. Extensions may chose not to use kernel
directly, in which case they can point to a snapshot.
> Or maybe do the viceversa, choose the items and bring
> the kernel up to a level to be able to support its implementation.
I'm not sure I follow this. If we need the kernel to support certain
features, I'm happy to help out as best I can. However, I'm really
not for participating in another release that repeats the M1 process
where we concocted a long list of "requirements" that people marched
to and took months to deliver. I'd rather have smaller, incremental
releases. If people want to have a release that follows this longer
process, they should do so as long as we can release kernel in
accordance with the "release early, release often" mantra.
> Going
> forward with both in increments will also help us to merge forward
> easily, I
> would imagine.
If development is not done against the trunk I think this will be
very problematic both from a technical as well as a community
perspective. We need to work together, not separately. If during the
release process we need to branch for stability with the intention
that only bug fixing is done in branch, that works for me. However,
development would be done against trunk.
> - I don't think its would be a good idea for the items in
> Sebastien's list
> to wait until the ongoing work in the kernel and runtime is complete.
>
Why? :-) I think that work should start now in kernel against trunk.
> I think Jeremy's point that we have to stop and now look what we
> are doing
> as a community is valid. We must have to get things around so that
> everybody
> in the community is able to contribute effectively.
+1. For me, doing development in trunk and relating a release
proposal to work already being done is a first step toward getting
people to act more like a community.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
Heres my opinion from the perspective of some items that I have owned up to
do quite a while back - support for complex properties and multivalued
properties. I'd see them as some fundamental things that a user might
expect to see out of our next milestone and am happy that they are a part of
this list that Sebastien has proposed.
Now to complete this, I am in dire need for a stable runtime and client
API. I need this for two reasons i) to figure out the workings of the
kernel through debugging so that I may implement these features according to
the framework's design (with loaders, builders, etc.) and ii) to test if the
whole thing sews up together and works as expected. I am just not able to
figure out how to do this from the current trunk andI have already started
to plead for help in this regard from the community
I have no complaints about the work that is going on presently in the kernel
- infact I am excited about the vision with which its being driven. But
then, I'd be happy if I could do my parts as well alongside.
Here are my thoughts for the path forward...
- I'd like us to plan for the next milestone release ideally by end of March
to feed the curiosity of our users. Having a long gap will kill their
interest in our technology.
- I'd deem the current kernel work as well as the items listed by Sebastien
as equally important, but we probably need to figure out how we can do both
parallely. Can we not do an incremental development of both? For example
we could baseline a stable and functioning version of the kernel and runtime
and then choose those items from Sebastien's list that can be implemented
over this baseline. Or maybe do the viceversa, choose the items and bring
the kernel up to a level to be able to support its implementation. Going
forward with both in increments will also help us to merge forward easily, I
would imagine.
- I don't think its would be a good idea for the items in Sebastien's list
to wait until the ongoing work in the kernel and runtime is complete.
I think Jeremy's point that we have to stop and now look what we are doing
as a community is valid. We must have to get things around so that everybody
in the community is able to contribute effectively.
Thanks
- Venkat
On 2/7/07, Simon Nash <na...@hursley.ibm.com> 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
> >>
> >>
> >> ---------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Content for next milestone
Posted by Luciano Resende <lu...@gmail.com>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Content for next milestone
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Rick Rineholt <cr...@gmail.com>.
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 ?
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?
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?
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
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Rick Rineholt <cr...@gmail.com>.
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
>>>
>>>
>>> ---------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Simon Nash <na...@hursley.ibm.com>.
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
>>
>>
>> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jeremy Boynes <jb...@apache.org>.
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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Content for next milestone
Posted by Jim Marino <jm...@myromatours.com>.
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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org