You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2009/02/09 22:37:33 UTC
[2.x] Java SCA 2.0 next milestones release
I'd like to start some discussion on how we should proceed going
forward with our 2.x Milestones releases aiming to be OASIS spec
compliant
I'd like to propose we alternate short milestones releases between
OASIS and Tuscany specific related items to allow us to better focus
and delivery contents. I'd also think we should have a small scope on
each release milestone (e.g about 5 main items or themes).
Below are some suggestions considering OASIS related items for the
next milestones, please feel free to add to it, and once we agree on a
small set of items/themes, I'll update the roadmap.
- Adjust our Tuscany models and artifact processors to the latest
OASIS Assembly Specification draft
- Review Tuscany Policy models and start necessary clean-up and
adjustment towards a more decoupled model/implementation and support
for the OASIS Policy Specification draft
- Although OASIS Java Specification draft is still a little behind
compared to others, there might still be some issues that could start
working on such as removing conversations
- Continue review and necessary work on Domain/Node APIs
- Continue with some code clean-up/refactoring as suggested/discussed
in previous threads
- Java implementation refactoring
- Endpoint refactoring
- Remove conversation
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] Java SCA 2.0 next milestones release
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Feb 13, 2009 at 1:27 PM, Simon Laws <si...@googlemail.com>wrote:
> Let me try and summarize this thread There's a lot to do here so we need
> to find things that people want to do that can happen in parallel. I think
> we logically need an M4. A guide rather than a plan set in concrete.
>
> M2 – Assembly compliance (based on extensions we already have in trunk)
>
> XSD/API
>
> Processors
>
> Assembly compliance tests
>
> Policy
>
> Endpoint
>
> Domain/Node
>
> + Any other infrastructure fixes we come across required for OASIS
> compliance
>
> M3 – Policy/Extension compliance
>
> Ws compliance tests
>
> Java compliance tests
>
> More policy work + Policy compliance tests
>
> More Domain/node work + Assembly compliance tests relating to domain
>
> Bring in remaining OASIS specific extension on upgraded infrastructure,
> e.g.
>
> JMS, JEE, BPEL, EJB binding, Spring (is there anything else)
>
> + compliance tests
>
> M4
>
> On top of beta compliance bring in any Tuscany specific extensions we
> think we need?
>
> Beta
>
> Lock down and prep for branch
>
> Simon
>
Touche Ant! This is just my summary of this thread. A guide with OASIS
compliance squarely in the frame but not a concrete plan and I would hope
it's treated in that spirit. If someone wants to bring up, say host-webapp,
or whatever much earlier then that's great I'm certainly not going to
complain. In fact webapp would be a good one as users want it and helps get
out sample testing thing complete with this tricky case. Maybe we should add
that explicitly to the list. Anyhow, I'd like us to move on from this
thread. Add the list to the roadmap, create appropriate JIRAS, adjust as we
see fit as we move forward and declare victory.
Simon
Re: [2.x] Java SCA 2.0 next milestones release
Posted by Simon Laws <si...@googlemail.com>.
Let me try and summarize this thread There's a lot to do here so we need to
find things that people want to do that can happen in parallel. I think we
logically need an M4. A guide rather than a plan set in concrete.
M2 – Assembly compliance (based on extensions we already have in trunk)
XSD/API
Processors
Assembly compliance tests
Policy
Endpoint
Domain/Node
+ Any other infrastructure fixes we come across required for OASIS
compliance
M3 – Policy/Extension compliance
Ws compliance tests
Java compliance tests
More policy work + Policy compliance tests
More Domain/node work + Assembly compliance tests relating to domain
Bring in remaining OASIS specific extension on upgraded infrastructure,
e.g.
JMS, JEE, BPEL, EJB binding, Spring (is there anything else)
+ compliance tests
M4
On top of beta compliance bring in any Tuscany specific extensions we
think we need?
Beta
Lock down and prep for branch
Simon
Re: [2.x] Java SCA 2.0 next milestones release
Posted by Raymond Feng <en...@gmail.com>.
I'm starting to look into the draft Policy spec from OASIS. The first thing is to come up a UML model that represents the various concepts in the policy framework. It can be slightly different from the XML syntax. I'll update the progress here on the ML whenever I'm ready.
Thanks,
Raymond
From: Simon Laws
Sent: Monday, February 09, 2009 2:35 PM
To: dev@tuscany.apache.org
Subject: Re: [2.x] Java SCA 2.0 next milestones release
On Mon, Feb 9, 2009 at 9:37 PM, Luciano Resende <lu...@gmail.com> wrote:
I'd like to start some discussion on how we should proceed going
forward with our 2.x Milestones releases aiming to be OASIS spec
compliant
I'd like to propose we alternate short milestones releases between
OASIS and Tuscany specific related items to allow us to better focus
and delivery contents. I'd also think we should have a small scope on
each release milestone (e.g about 5 main items or themes).
Below are some suggestions considering OASIS related items for the
next milestones, please feel free to add to it, and once we agree on a
small set of items/themes, I'll update the roadmap.
- Adjust our Tuscany models and artifact processors to the latest
OASIS Assembly Specification draft
- Review Tuscany Policy models and start necessary clean-up and
adjustment towards a more decoupled model/implementation and support
for the OASIS Policy Specification draft
- Although OASIS Java Specification draft is still a little behind
compared to others, there might still be some issues that could start
working on such as removing conversations
- Continue review and necessary work on Domain/Node APIs
- Continue with some code clean-up/refactoring as suggested/discussed
in previous threads
- Java implementation refactoring
- Endpoint refactoring
- Remove conversation
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
This is a good idea Luciano.
I would be happy if we set some kind of loose timetable for how this process is going to get us to an OASIS spec compliant code line by the the middle of the year (or whenever it is we think OASIS will be done by.
As you say some of the specs are more complete that others. As good measure is to look at the compliance statements and test cases. One of the ways we can drive and measure progress is by completion of compliance tests. We need to be able to pass them to demonstrate compliance so developing with them in mind would seem to be a good idea.
What do you mean by short? Monthly? Six weekly? I think it should be down at this sort of order.
I'd like to take a look at the Endpoint re-factoring piece next so I'll vote for that being in M2. There are parts of this that are a pre-req for the Domain piece. I'm also interested in the compliance testing and most of the action is in assembly so far.
Not sure we explicitly have to alternate but I like the idea of themes. Maybe this results in the same thing but I wouldn't want to pre-judge it.
Simon
Re: [2.x] Java SCA 2.0 next milestones release
Posted by ant elder <an...@apache.org>.
On Wed, Feb 11, 2009 at 5:05 PM, Raymond Feng <en...@gmail.com> wrote:
> Please see my comments inline.
>
> Thanks,
> Raymond
>
> *From:* ant elder <an...@gmail.com>
> *Sent:* Wednesday, February 11, 2009 7:06 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: [2.x] Java SCA 2.0 next milestones release
>
>
>
> On Mon, Feb 9, 2009 at 10:49 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> On Mon, Feb 9, 2009 at 2:35 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>> >
>> > What do you mean by short? Monthly? Six weekly? I think it should be
>> down at
>> > this sort of order.
>> >
>>
>> I was thinking on something around 4 weeks or less.
>>
>>
>> > Not sure we explicitly have to alternate but I like the idea of themes.
>> > Maybe this results in the same thing but I wouldn't want to pre-judge
>> it.
>> >
>>
>> I just want to avoid loosing focus, and having multiple people going
>> in multiple directions. Alternating focus between OASIS spec items and
>> Tuscany infrastructure/extensions would allow us to get the right
>> balance, and would allow active collaboration towards a common goal
>> and I hope better results at the end.
>>
>>
> +1 on not loosing focus, but i think we may need to have multiple people
> going in multiple directions if we're to get this done in time. Remember the
> date we're aiming for 2.0 is June, just three and a bit months away so not
> much time.
>
> Doing a release takes time away from other work so too short a release
> cycle will impact productivity, a release every few weeks is too often IMHO,
> it might work with the point releases we've done to fix bugs in 1.x.x type
> releases but for this type of milestone development it would mean an
> unnecessarily high percentage of our available time gets sucked up in
> release work. 6 weeks seems more realistic to me and that could give an M2
> at end of March, M3 end of April, perhaps beta1 end of May and then 2.0
> final tracks the OASIS date.
>
> A 6-week cycle sounds reasonable.
>
> So fitting the work and themes into into those three releases could be:
>
> M2 - port as much as possible from 1.x to 2.x
>
> IMO, it is probably too early to do this in M2. Porting non-OASIS
> extensions won't help the OASIS compliance and I'm afraid that we will have
> to do it again as the core and SPIs will change quite a bit. We need to
> adjust the XSDs, models and processors for the assembly, policy and other
> OASIS bindings/implementations so that the Tuscany runtime can consume the
> OASIS composites. We should try to get some of the key infrastructures such
> as Endpoint and Policy in place first. (The policy work can be spanning over
> two milestones)
>
> We can start with the extensions that are defined by OASIS specs and defer
> other extensions to a later stage.
>
> When will the Domain/Node story to be completed?
>
> M3 - work on OASIS compliance
>
> We should try to pass all of the OASIS compliance tests.
>
> Beta1 - stabilize all functional changes
>
> I think it's the time that we port non-OASIS extensions to 2.x and
> stabilize the code.
>
> and then only bug fixes in a 2.0 branch till the 2.0 final release
> Let's try to dump out the all the items toward an OASIS-compliant SCA
> runtime first and then plug them into the milestones.
>
>
>
I think we're on similar pages. The contents of M2 is still a bit hazy but i
think thats fine, these are themes not rules so we can work it out as we go
along. I don't think we should restrict things to only spec defined items
though, there are also other things we do need to do such as the Node story
and webapp integration we need to get done and they're not defined in any
specs, bringing up non OASIS extensions will help verify SPIs, provide
opportunities for people to help and get involved in the 2.x code, and they
provide a easier entry point to learning 2.x than diving right in to
something like implementation.bpel. We've also the results from the user
survey that shows us what people are using so that can help prioritize work.
Agree with that last point, we've the 2.0 draft release notes and 2.x JIRA
lists we've started on the other threads about this to help guide us, if we
keep adding JIRAs as we thing of things then it will help see what needs to
be done
...ant
Re: [2.x] Java SCA 2.0 next milestones release
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
From: ant elder
Sent: Wednesday, February 11, 2009 7:06 AM
To: dev@tuscany.apache.org
Subject: Re: [2.x] Java SCA 2.0 next milestones release
On Mon, Feb 9, 2009 at 10:49 PM, Luciano Resende <lu...@gmail.com> wrote:
On Mon, Feb 9, 2009 at 2:35 PM, Simon Laws <si...@googlemail.com> wrote:
>
> What do you mean by short? Monthly? Six weekly? I think it should be down at
> this sort of order.
>
I was thinking on something around 4 weeks or less.
> Not sure we explicitly have to alternate but I like the idea of themes.
> Maybe this results in the same thing but I wouldn't want to pre-judge it.
>
I just want to avoid loosing focus, and having multiple people going
in multiple directions. Alternating focus between OASIS spec items and
Tuscany infrastructure/extensions would allow us to get the right
balance, and would allow active collaboration towards a common goal
and I hope better results at the end.
+1 on not loosing focus, but i think we may need to have multiple people going in multiple directions if we're to get this done in time. Remember the date we're aiming for 2.0 is June, just three and a bit months away so not much time.
Doing a release takes time away from other work so too short a release cycle will impact productivity, a release every few weeks is too often IMHO, it might work with the point releases we've done to fix bugs in 1.x.x type releases but for this type of milestone development it would mean an unnecessarily high percentage of our available time gets sucked up in release work. 6 weeks seems more realistic to me and that could give an M2 at end of March, M3 end of April, perhaps beta1 end of May and then 2.0 final tracks the OASIS date.
A 6-week cycle sounds reasonable.
So fitting the work and themes into into those three releases could be:
M2 - port as much as possible from 1.x to 2.x
IMO, it is probably too early to do this in M2. Porting non-OASIS extensions won't help the OASIS compliance and I'm afraid that we will have to do it again as the core and SPIs will change quite a bit. We need to adjust the XSDs, models and processors for the assembly, policy and other OASIS bindings/implementations so that the Tuscany runtime can consume the OASIS composites. We should try to get some of the key infrastructures such as Endpoint and Policy in place first. (The policy work can be spanning over two milestones)
We can start with the extensions that are defined by OASIS specs and defer other extensions to a later stage.
When will the Domain/Node story to be completed?
M3 - work on OASIS compliance
We should try to pass all of the OASIS compliance tests.
Beta1 - stabilize all functional changes
I think it's the time that we port non-OASIS extensions to 2.x and stabilize the code.
and then only bug fixes in a 2.0 branch till the 2.0 final release
Let's try to dump out the all the items toward an OASIS-compliant SCA runtime first and then plug them into the milestones.
...ant
Re: [2.x] Java SCA 2.0 next milestones release
Posted by ant elder <an...@gmail.com>.
On Mon, Feb 9, 2009 at 10:49 PM, Luciano Resende <lu...@gmail.com>wrote:
> On Mon, Feb 9, 2009 at 2:35 PM, Simon Laws <si...@googlemail.com>
> wrote:
> >
> > What do you mean by short? Monthly? Six weekly? I think it should be down
> at
> > this sort of order.
> >
>
> I was thinking on something around 4 weeks or less.
>
>
> > Not sure we explicitly have to alternate but I like the idea of themes.
> > Maybe this results in the same thing but I wouldn't want to pre-judge it.
> >
>
> I just want to avoid loosing focus, and having multiple people going
> in multiple directions. Alternating focus between OASIS spec items and
> Tuscany infrastructure/extensions would allow us to get the right
> balance, and would allow active collaboration towards a common goal
> and I hope better results at the end.
>
>
+1 on not loosing focus, but i think we may need to have multiple people
going in multiple directions if we're to get this done in time. Remember the
date we're aiming for 2.0 is June, just three and a bit months away so not
much time.
Doing a release takes time away from other work so too short a release cycle
will impact productivity, a release every few weeks is too often IMHO, it
might work with the point releases we've done to fix bugs in 1.x.x type
releases but for this type of milestone development it would mean an
unnecessarily high percentage of our available time gets sucked up in
release work. 6 weeks seems more realistic to me and that could give an M2
at end of March, M3 end of April, perhaps beta1 end of May and then 2.0
final tracks the OASIS date.
So fitting the work and themes into into those three releases could be:
M2 - port as much as possible from 1.x to 2.x
M3 - work on OASIS compliance
Beta1 - stabilize all functional changes
and then only bug fixes in a 2.0 branch till the 2.0 final release
...ant
Re: [2.x] Java SCA 2.0 next milestones release
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Feb 9, 2009 at 2:35 PM, Simon Laws <si...@googlemail.com> wrote:
>
> What do you mean by short? Monthly? Six weekly? I think it should be down at
> this sort of order.
>
I was thinking on something around 4 weeks or less.
> Not sure we explicitly have to alternate but I like the idea of themes.
> Maybe this results in the same thing but I wouldn't want to pre-judge it.
>
I just want to avoid loosing focus, and having multiple people going
in multiple directions. Alternating focus between OASIS spec items and
Tuscany infrastructure/extensions would allow us to get the right
balance, and would allow active collaboration towards a common goal
and I hope better results at the end.
> Simon
>
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] Java SCA 2.0 next milestones release
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Feb 9, 2009 at 9:37 PM, Luciano Resende <lu...@gmail.com>wrote:
> I'd like to start some discussion on how we should proceed going
> forward with our 2.x Milestones releases aiming to be OASIS spec
> compliant
>
> I'd like to propose we alternate short milestones releases between
> OASIS and Tuscany specific related items to allow us to better focus
> and delivery contents. I'd also think we should have a small scope on
> each release milestone (e.g about 5 main items or themes).
>
> Below are some suggestions considering OASIS related items for the
> next milestones, please feel free to add to it, and once we agree on a
> small set of items/themes, I'll update the roadmap.
>
> - Adjust our Tuscany models and artifact processors to the latest
> OASIS Assembly Specification draft
>
> - Review Tuscany Policy models and start necessary clean-up and
> adjustment towards a more decoupled model/implementation and support
> for the OASIS Policy Specification draft
>
> - Although OASIS Java Specification draft is still a little behind
> compared to others, there might still be some issues that could start
> working on such as removing conversations
>
> - Continue review and necessary work on Domain/Node APIs
>
> - Continue with some code clean-up/refactoring as suggested/discussed
> in previous threads
> - Java implementation refactoring
> - Endpoint refactoring
> - Remove conversation
>
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
This is a good idea Luciano.
I would be happy if we set some kind of loose timetable for how this process
is going to get us to an OASIS spec compliant code line by the the middle
of the year (or whenever it is we think OASIS will be done by.
As you say some of the specs are more complete that others. As good measure
is to look at the compliance statements and test cases. One of the ways we
can drive and measure progress is by completion of compliance tests. We need
to be able to pass them to demonstrate compliance so developing with them in
mind would seem to be a good idea.
What do you mean by short? Monthly? Six weekly? I think it should be down at
this sort of order.
I'd like to take a look at the Endpoint re-factoring piece next so I'll vote
for that being in M2. There are parts of this that are a pre-req for the
Domain piece. I'm also interested in the compliance testing and most of the
action is in assembly so far.
Not sure we explicitly have to alternate but I like the idea of themes.
Maybe this results in the same thing but I wouldn't want to pre-judge it.
Simon