Simon Laws wrote:
On Wed, Nov 12, 2008 at 11:08 AM, ant elder <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Wed, Nov 12, 2008 at 6:34 AM, Ramkumar R <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Simon,
My preference would be to "Start with the smallest set of
modules possible and iterate toward OASIS compliance adding in
more function/extensions as people address different
features/specifications",
as I believe this option would give us a more clear direction on
where we are heading towards.
On Tue, Nov 11, 2008 at 3:02 PM, Simon Laws
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
Several alternatives have been suggested [1] which I
summarize here.
A) Start from what we already have in trunk, develop the
OASIS function, introduce new improvements or improvements
from the Equinox branch as appropriate
B) Start from a completely clean trunk and build up from
there based on the resources we have in the the 1.x code
stream, in the Equinox branch or from new developments
C) Start from what is in the Equinox branch
Is this correct? Are there other combinations people want to
consider? There is a related question of how we develop
trunk toward OASIS compliance. I see two extremes;
i) Start with a full set of modules and update to OASIS
compliance while keeping all the function we have running
ii) Start with the smallest set of modules possible and
iterate toward OASIS compliance adding in more
function/extensions as people address different
features/specifications.
Again, are there other approaches?
The object of this discussion is to agree the starting point
for future trunk development. If you don't have other
options to add it would be useful for you to express a
preference so we can see what people think. If we can't come
to a conclusion in the next couple of days though this
discussion we will have to identify a small number of
options to vote on.
Thanks
Simon
[1]
http://www.mail-archive.com/dev%40tuscany.apache.org/msg03215.html
I liked what was said over on the other thread [1]:
"...starting afresh in trunk based on the assets that we already
have, primarily that it gives us all the opportunity to feel
involved in how Tuscany v2.0 will look"
So i guess thats closest to (B ii). Its not that clear yet how this
would actually work but it sounds like a good thing to aim for.
..ant
[1] http://apache.markmail.org/message/apawwigihmpgx7sk
Yes, my choice would be B ii also. How would this work?
Firstly I'd like to see us define a relatively short (max two weeks?)
timescale for getting the minimal function working in the new trunk.
This will focus the mind and help us not get sidetracked with other fluff.
I would propose that we set ourselves the objective of getting a simple
scenario (e.g. calculator) working to demonstrate the trunk structure
and operation.
We need to identify those issues that must be addressed in this bring up
stage and define a strategy for address them. I believe this will come
out of the themes thread.
Then work out who wants to tackle each topic and drive the thrashing out
of the details on the ML/in the code . We may have to accept that there
may be things we can't do in parallel so this has to be a collaborative
exercise with those currently active keeping the ML up to date giving
the opportunity for others to jump in.
Ultimately one person is going to have to commit some initial modules to
trunk and we will soon hit the "where do they come from issues". To help
me with this question I'd like use to understand
1. What modules from trunk today would be the minimum set needed. I can
go an pull the dependency list from the calculator sample.
2. With this minimum set what is the difference between these and what
is in the Equinox branch. Can someone familiar with the branch explain
please?
Once we get to the minimum function stage we can test it and introduce
other features and changes in a controlled manner while adopting the
best practice that has been established.
Simon
Folks,
One question worth asking is whether the idea is to move to OASIS compliance and to OSGi/Equinox at
the same time?
It might be a good idea to do these together, especially if we're starting with something small and
building it up piece by piece.
Yours, Mike.
