Resending in plain text format to avoid spam alarm.
Thanks,
Raymond
From: Raymond Feng
Sent: Thursday, October 09, 2008 9:44 AM
To: [email protected]
Subject: Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Hi,
Please see my comments inline.
Thanks,
Raymond
From: Simon Laws
Sent: Thursday, October 09, 2008 5:55 AM
To: [email protected] ; [EMAIL PROTECTED]
Subject: Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
On Thu, Oct 9, 2008 at 10:08 AM, ant elder <[EMAIL PROTECTED]> wrote:
On Thu, Oct 9, 2008 at 7:52 AM, Jean-Sebastien Delfino
<[EMAIL PROTECTED]> wrote:
Simon Nash wrote:
See inline.
Simon
ant elder wrote:
On Mon, Oct 6, 2008 at 9:02 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
ant elder wrote:
> (cut)
So this branch is really a fork isn't it?
...ant
Is that a question or a statement? I don't really understand how you
come up to that conclusion.
It's not a fork, it's a branch to work through breaking changes (and
pretty complex changes I must say) which should allow our runtime to
correctly work as a set of modular bundles in an Equinox/OSGi
environment.
I'm hoping that this work can somehow benefit Tuscany, by providing
code, patterns or maybe just a set of techniques that the project
can implement to work in Equinox/OSGi. It'll be up to the Tuscany
community to take a look and decide what can be reused or if it's
just something to study and learn from.
If the focus is purely on OSGi/Equinox support, this sounds fine to me,
with the resulting code/patterns/techniques eventually getting applied
to trunk. If it includes other restructuring or changes, I'd prefer to
see this kind of thing done in trunk as far as possible so it's easier
for the whole community to participate.
At the moment that Equinox port is still pretty broken, I've made
changes to start to clean up the dependencies on
assembly.builder.impl and contribution.service.impl for example, but
there are many other similar cross-bundle dependencies on
implementation packages which will take time to clean up.
When this is working, will it imply a hard dependency from Tuscany on
Equinox, or will there still be a way to run Tuscany outside of the
OSGI/Equinox environment?
Simon
-- Jean-Sebastien
I guess what i'm still not understanding is why can't the most of this
happen in trunk? For example - "clean up the dependencies on
assembly.builder.impl and contribution.service.impl for example, but there
are many other similar cross-bundle dependencies on implementation
packages" - all of that is applicable to the trunk code and has no
dependencies on the OSGi changes so why not just do it from the start in
trunk?
...ant
Here's how I'm approaching this work at the moment (although the approach
may change as I make progress, resolve issues or run into new issues).
- Correctly running in OSGi requires significant restructuring and
refactoring of the Tuscany runtime. It's not just about dependencies on OSGi
APIs or changing how a few classes get loaded, it's also about making sure
that cross-bundle calls go through defined and exported SPIs. We had well
defined SPIs for a while but a lot of code has gone around the SPIs, instead
of evolving the SPIs when needed and that has gone for about 18 months, so
there's many examples of that. Now when you try to run this stuff in OSGi,
it just breaks as OSGi is not going to allow you to go around the package
visibility rules (and putting the whole runtime in a few big bundles that
import/export everything is not really serious or interesting).
Ok and AFAICT there are no reasons that sort of SPI clean up and module
refactoring work could not happen in the trunk code.
- That restructuring would probably break trunk for a few months while we
work through ways to refactor it.
I don't see why that needs to break trunk for months, this type of
refactoring and clean up can be done less disruptively than that, we've done
that type of thing in the earlier days of Tuscany without being broken for
months at a time.
So, I'm trying to contribute enough of the refactoring and the code
patterns that work well in OSGi in the sca-equinox branch now, to make it
easier to do it in trunk when trunk is ready for it. I'm hoping that we'll
then be able to do this work without breaking trunk too much and too long,
since we'll have something to look at and reflect on in the branch. It's
always much easier to do things a second time, when somebody has already
been through the pain of exploring it for you and you can take a look at the
result. That's what I'm trying to do now to help the project.
I'm _really_ nervous of this approach. It sounds so much like what happened
with the chianti fork and the disaster that caused.
I don't believe after months of development you'd be able to easily share
what you'd learnt while doing it or that it would be just used to "look at
and reflect on". Its already becoming so different its almost impossible for
those outside to be able to make any detailed code comparisons so i just
don't see how this approach would be that useful to us for making
corresponding changes in trunk.
I've been wondering what to do about this fork for a while now, having it
developed by one person in isolation and then forced on us as the new 2.x
code stream would be the final nail in the project IMO. Just having the fork
going on has stalled the trunk - nothing much is going on these days other
than a bit of bug fixing, i've certainly stopped bothering doing much else
as unless it gets picked up by the branch there doesn't seem much point.
There's only one thing i've been able to think of to do so far - all join in
now while its still in its infancy. We keep saying we need a new 2.x branch
to do some breaking changes, to clean things up, and to 'innovate' in. The
final versions of the OASIS spec are coming out so we could use a new branch
to have clean support for those. Having us all work together on this
refactor and clean up would mean we'd all get a much better understanding of
the changes and would completely avoid all the issues about how to move it
forward.
What do others think? Are you happy having the branch going on? Nervous
about what the future holds? Do you have other suggestions for changes that
might make it seem more benevolent? Is anyone else up for helping to use
this branch as the new 2.x?
...ant
I'm actually completely comfortable if someone feels the motivation to go
off and try some things out in a branch or a sandbox. I wouldn't want to
make that hard to do in Tuscany.
<rfeng>Why do we care so much about the name of the stream? They are just
two different folders in svn . We just need to have a place to do the work.
I'm happy to contribute to the branch to take it to a better shape
sooner.</rfeng>
I do share your concern about how the hidden gems in that work are
exploited. Normally I would expect the people doing the work to take the
responsibility for educating the community with their findings and for
working out how to suitably enhance the trunk. However in this case the
changes and challenges are, IMHO, more psychological/intellectual than
technical. If we really are going to do OSGi we all need to learn how to do
it and what this means for the way wite write Tuscany runtime code.
Hence +1 for making the contents of the branch be the new 2.x trunk.
<rfeng>+1 to make the content of the branch as the starting code base for
new 2.x trunk.</rfeng>
I would say though that there are a number of things that I personally want
to see enhanced in the 1.x code stream and I certainly don't want to
disappear into 6 months (or however long/short it is) of 2.x trunk
development without adding value for our community that has committed to 1.x
for the time being.
So I would further propose that we take the current trunk and create a 1.x
branch (1-SNAPSHOT?) from which I (we?) can continue 1.x development and
releases as trunk shapes up.
<rfeng>+1</rfeng>
Simon
