You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2008/08/29 18:56:45 UTC
Creating distros for OSGi-enabled Tuscany/SCA
Hi,
I noticed that a new module [1] has been added to produce OSGi bundles for
tuscany modules and 3rd party jars. I propose that we integrate with this
effort with the list of distros following the practice we have at [2]. [2]
already defines a set of features that collects related tuscany modules and
3rd party dependencies.
Basically, we can probably add a new profile on top of [2] to preprocess the
3rd party jars to be OSGi bundles before the maven-assembly-plugin packages
them into distros. When we run the maven build with the OSGi profile, the
distros should be ready for OSGi.
Thanks,
Raymond
[1]
http://svn.apache.org/repos/asf/tuscany/java/sca/itest/osgi-tuscany/tuscany-versioned/
[2] http://svn.apache.org/repos/asf/tuscany/java/sca/distribution/features/
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled Tuscany/SCA
Posted by ant elder <an...@gmail.com>.
On Thu, Oct 9, 2008 at 10:08 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Thu, Oct 9, 2008 at 7:52 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Simon Nash wrote:
>>
>>> See inline.
>>>
>>> Simon
>>>
>>> ant elder wrote:
>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 9:02 AM, Jean-Sebastien Delfino <
>>>> jsdelfino@apache.org <ma...@apache.org>> 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
>
>
With only two replies to this I don't think we should go ahead with such a
drastic change to trunk. As an alternative could we base the new 2.x branch
on the current trunk code and right away start moving over the changes from
the branch to trunk and do any further development for OSGi in this new
trunk? That way we'd all start learning better whats needed for OSGi, with
help we could even probably all help moving some of the branch changes to
trunk. We'd still take the 1.4 branch now based on the current trunk so we'd
have that stable branch for near term releases.
...ant
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled Tuscany/SCA
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Oct 9, 2008 at 10:08 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Thu, Oct 9, 2008 at 7:52 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Simon Nash wrote:
>>
>>> See inline.
>>>
>>> Simon
>>>
>>> ant elder wrote:
>>>
>>>>
>>>>
>>>> On Mon, Oct 6, 2008 at 9:02 AM, Jean-Sebastien Delfino <
>>>> jsdelfino@apache.org <ma...@apache.org>> 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.
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.
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.
Simon
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled Tuscany/SCA
Posted by ant elder <an...@gmail.com>.
On Thu, Oct 9, 2008 at 7:52 AM, Jean-Sebastien Delfino <jsdelfino@apache.org
> wrote:
> Simon Nash wrote:
>
>> See inline.
>>
>> Simon
>>
>> ant elder wrote:
>>
>>>
>>>
>>> On Mon, Oct 6, 2008 at 9:02 AM, Jean-Sebastien Delfino <
>>> jsdelfino@apache.org <ma...@apache.org>> 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
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> See inline.
>
> Simon
>
> ant elder wrote:
>>
>>
>> On Mon, Oct 6, 2008 at 9:02 AM, Jean-Sebastien Delfino
>> <jsdelfino@apache.org <ma...@apache.org>> 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).
- That restructuring would probably break trunk for a few months while
we work through ways to refactor it. 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.
- You've already asked a similar question about 'a dependency from
Tuscany on Equinox', I've looked up my earlier response for you as it
has not changed: http://marc.info/?l=tuscany-dev&m=122274696224651
--
Jean-Sebastien
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Simon Nash <na...@apache.org>.
See inline.
Simon
ant elder wrote:
>
>
> On Mon, Oct 6, 2008 at 9:02 AM, Jean-Sebastien Delfino
> <jsdelfino@apache.org <ma...@apache.org>> 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
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled Tuscany/SCA
Posted by ant elder <an...@gmail.com>.
On Mon, Oct 6, 2008 at 9:02 AM, Jean-Sebastien Delfino <jsdelfino@apache.org
> wrote:
> ant elder wrote:
>
>>
>>
>> On Wed, Oct 1, 2008 at 6:21 AM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org <ma...@apache.org>> wrote:
>>
>> ant elder wrote:
>>
>>
>>
>> On Mon, Sep 29, 2008 at 5:01 PM, Jean-Sebastien Delfino
>> <jsdelfino@apache.org <ma...@apache.org>
>> <mailto:jsdelfino@apache.org <ma...@apache.org>>>
>> wrote:
>>
>> ant elder wrote:
>>
>>
>>
>> On Thu, Sep 11, 2008 at 5:37 PM, Jean-Sebastien Delfino
>> <jsdelfino@apache.org <ma...@apache.org>
>> <mailto:jsdelfino@apache.org <ma...@apache.org>>
>> <mailto:jsdelfino@apache.org
>> <ma...@apache.org> <mailto:jsdelfino@apache.org
>> <ma...@apache.org>>>> wrote:
>>
>> <snip>
>>
>>
>> I'll create a branch to make progress on this Equinox
>> porting
>> effort
>> without breaking everybody else. As I said before
>> it'll probably
>> take a few weeks to get most Tuscany samples and
>> itests up and
>> running, but I'd like to try to have a few core itests
>> and
>> maybe a
>> Web Service or two working in the next few days.
>>
>>
>>
>> Its been a few weeks now, what are the plans and time
>> frames for
>> merging this branch back into the mainstream trunk?
>>
>> ...ant
>>
>>
>> Still making progress on the Equinox bringup, going slowly as
>> I'm
>> busy at work. Getting the whole runtime really working end to
>> end in
>> Equinox is going to require changes in many different places
>> in the
>> code, so don't expect miracles it's going to take time. Some
>> of the
>> changes may be possible to merge to trunk already if people
>> want to
>> help with that.
>>
>> -- Jean-Sebastien
>>
>>
>> The problem with helping is that its difficult to work out what
>> are the changes. I've done a diff of the sca-equinox branch to
>> the trunk which is at:
>> http://people.apache.org/~antelder/temp/sca-equinox.diff<http://people.apache.org/%7Eantelder/temp/sca-equinox.diff>
>> <http://people.apache.org/%7Eantelder/temp/sca-equinox.diff>.
>>
>> Its huge, and lots of the changes seem quite unrelated to OSGi
>> class loading. Some changes from trunk get merged to the branch,
>> some don't, others get modified and then merged, there's also
>> what looks like new development not directly related to
>> OSGi/Equinox that goes into the branch but not trunk. If this
>> branch is to show what changes are needed for Equinox then
>> wouldn't it be clearer if the only changes in the branch were
>> directly related to Equinox? With the diff so huge now how can
>> this ever get merged to trunk?
>>
>> ...ant
>>
>>
>> I've always had trouble too working off flat diffs like that.
>> Merging / porting individual commits from the history should be
>> easier. That's what I've been doing to pull some changes from trunk,
>> and it's really easy once you've done it a few times and have
>> defined your merge processes with the Svn, diff, patch tools etc. If
>> you're interested in trying it, for more complicated cases (like
>> when I started to create the android branch) I've also found Git
>> very powerful at handling merges. Working off the history should
>> also help you pick only the changes that are not going to break the
>> trunk at this point, or pick them in a more convenient sequence for
>> example.
>>
>> If that helps I could try to document the steps that I've been
>> following for various merge cases but I'm busy these days so it'll
>> probably take some time before I get to it.
>>
>> If people want to help, at the moment I'm seeing issues with many
>> 'dirty' cross module dependencies (tapping directly into impl
>> classes instead of going through the SPI.
>>
>> An example is dependencies on o.a.t.sca.contribution.impl, causing
>> this:
>>
>> warning: Unresolved resource
>> META-INF/services/org.apache.tuscany.sca.node.SCANodeFactory found
>> in 15 org.apache.tuscany.sca.node.impl INSTALLED
>> severe: SCA Node could not be created
>> java.lang.reflect.InvocationTargetException
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at
>>
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>> at
>>
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>> at
>> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>> at
>>
>> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
>> at
>>
>> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
>> at
>> calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
>> at junit.framework.TestCase.runBare(TestCase.java:132)
>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>> at junit.framework.TestResult.runProtected(TestResult.java:128)
>> at junit.framework.TestResult.run(TestResult.java:113)
>> at junit.framework.TestCase.run(TestCase.java:124)
>> at junit.framework.TestSuite.runTest(TestSuite.java:232)
>> at junit.framework.TestSuite.run(TestSuite.java:227)
>> at
>>
>> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>> at
>>
>> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>> at
>>
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>> at
>>
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>>
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
>> at
>>
>> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
>> Caused by: org.osoa.sca.ServiceRuntimeException:
>> java.lang.reflect.InvocationTargetException
>> at
>>
>> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
>> at
>>
>> org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
>> ... 25 more
>> Caused by: java.lang.reflect.InvocationTargetException
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>>
>> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
>> ... 26 more
>> Caused by: java.lang.IllegalStateException:
>> org.osgi.framework.BundleException: The bundle could not be
>> resolved. Reason: Missing Constraint: Import-Package:
>> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
>> at
>>
>> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
>> at
>>
>> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
>> at
>>
>> org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
>> ... 31 more
>> Caused by: org.osgi.framework.BundleException: The bundle could not
>> be resolved. Reason: Missing Constraint: Import-Package:
>> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
>> at
>>
>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
>> at
>>
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
>> at
>>
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
>> at
>>
>> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
>> ... 33 more
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
>> 4.213 sec <<< FAILURE!
>> testDummy(calculator.CalculatorTestCase) Time elapsed: 4.153 sec
>> <<< ERROR!
>> org.apache.tuscany.sca.node.equinox.launcher.LauncherException:
>> java.lang.reflect.InvocationTargetException
>> at
>>
>> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:174)
>> at
>>
>> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
>> at
>> calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
>> at junit.framework.TestCase.runBare(TestCase.java:132)
>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>> at junit.framework.TestResult.runProtected(TestResult.java:128)
>> at junit.framework.TestResult.run(TestResult.java:113)
>> at junit.framework.TestCase.run(TestCase.java:124)
>> at junit.framework.TestSuite.runTest(TestSuite.java:232)
>> at junit.framework.TestSuite.run(TestSuite.java:227)
>> at
>>
>> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
>> at
>>
>> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
>> at
>>
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
>> at
>>
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
>> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>>
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
>> at
>>
>> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
>> Caused by: java.lang.reflect.InvocationTargetException
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at
>>
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>> at
>>
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>> at
>> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>> at
>>
>> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
>> ... 20 more
>> Caused by: org.osoa.sca.ServiceRuntimeException:
>> java.lang.reflect.InvocationTargetException
>> at
>>
>> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
>> at
>>
>> org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
>> ... 25 more
>> Caused by: java.lang.reflect.InvocationTargetException
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>>
>> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
>> ... 26 more
>> Caused by: java.lang.IllegalStateException:
>> org.osgi.framework.BundleException: The bundle could not be
>> resolved. Reason: Missing Constraint: Import-Package:
>> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
>> at
>>
>> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
>> at
>>
>> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
>> at
>>
>> org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
>> ... 31 more
>> Caused by: org.osgi.framework.BundleException: The bundle could not
>> be resolved. Reason: Missing Constraint: Import-Package:
>> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
>> at
>>
>> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
>> at
>>
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
>> at
>>
>> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
>> at
>>
>> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
>> ... 33 more
>>
>>
>> I'm starting to fix node-impl to only reference SPIs but I've not
>> been able to find what's causing the above exception, given that the
>> unresolved contribution.impl package is exported+imported right now
>> (as a workaround, but the workaround doesn't seem to work).
>>
>> So if anybody has ideas about that exception, please let me know...
>>
>> Thanks
>> -- Jean-Sebastien
>>
>>
>>
>> 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.
>
> 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.
>
> --
> 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
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
>
>
> On Wed, Oct 1, 2008 at 6:21 AM, Jean-Sebastien Delfino
> <jsdelfino@apache.org <ma...@apache.org>> wrote:
>
> ant elder wrote:
>
>
>
> On Mon, Sep 29, 2008 at 5:01 PM, Jean-Sebastien Delfino
> <jsdelfino@apache.org <ma...@apache.org>
> <mailto:jsdelfino@apache.org <ma...@apache.org>>> wrote:
>
> ant elder wrote:
>
>
>
> On Thu, Sep 11, 2008 at 5:37 PM, Jean-Sebastien Delfino
> <jsdelfino@apache.org <ma...@apache.org>
> <mailto:jsdelfino@apache.org <ma...@apache.org>>
> <mailto:jsdelfino@apache.org
> <ma...@apache.org> <mailto:jsdelfino@apache.org
> <ma...@apache.org>>>> wrote:
>
> <snip>
>
>
> I'll create a branch to make progress on this Equinox
> porting
> effort
> without breaking everybody else. As I said before
> it'll probably
> take a few weeks to get most Tuscany samples and
> itests up and
> running, but I'd like to try to have a few core itests and
> maybe a
> Web Service or two working in the next few days.
>
>
>
> Its been a few weeks now, what are the plans and time
> frames for
> merging this branch back into the mainstream trunk?
>
> ...ant
>
>
> Still making progress on the Equinox bringup, going slowly as I'm
> busy at work. Getting the whole runtime really working end to
> end in
> Equinox is going to require changes in many different places
> in the
> code, so don't expect miracles it's going to take time. Some
> of the
> changes may be possible to merge to trunk already if people
> want to
> help with that.
>
> -- Jean-Sebastien
>
>
> The problem with helping is that its difficult to work out what
> are the changes. I've done a diff of the sca-equinox branch to
> the trunk which is at:
> http://people.apache.org/~antelder/temp/sca-equinox.diff
> <http://people.apache.org/%7Eantelder/temp/sca-equinox.diff>.
> Its huge, and lots of the changes seem quite unrelated to OSGi
> class loading. Some changes from trunk get merged to the branch,
> some don't, others get modified and then merged, there's also
> what looks like new development not directly related to
> OSGi/Equinox that goes into the branch but not trunk. If this
> branch is to show what changes are needed for Equinox then
> wouldn't it be clearer if the only changes in the branch were
> directly related to Equinox? With the diff so huge now how can
> this ever get merged to trunk?
>
> ...ant
>
>
> I've always had trouble too working off flat diffs like that.
> Merging / porting individual commits from the history should be
> easier. That's what I've been doing to pull some changes from trunk,
> and it's really easy once you've done it a few times and have
> defined your merge processes with the Svn, diff, patch tools etc. If
> you're interested in trying it, for more complicated cases (like
> when I started to create the android branch) I've also found Git
> very powerful at handling merges. Working off the history should
> also help you pick only the changes that are not going to break the
> trunk at this point, or pick them in a more convenient sequence for
> example.
>
> If that helps I could try to document the steps that I've been
> following for various merge cases but I'm busy these days so it'll
> probably take some time before I get to it.
>
> If people want to help, at the moment I'm seeing issues with many
> 'dirty' cross module dependencies (tapping directly into impl
> classes instead of going through the SPI.
>
> An example is dependencies on o.a.t.sca.contribution.impl, causing this:
>
> warning: Unresolved resource
> META-INF/services/org.apache.tuscany.sca.node.SCANodeFactory found
> in 15 org.apache.tuscany.sca.node.impl INSTALLED
> severe: SCA Node could not be created
> java.lang.reflect.InvocationTargetException
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
> at
> calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
> at junit.framework.TestCase.runBare(TestCase.java:132)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
> Caused by: org.osoa.sca.ServiceRuntimeException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
> at
> org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
> ... 25 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
> ... 26 more
> Caused by: java.lang.IllegalStateException:
> org.osgi.framework.BundleException: The bundle could not be
> resolved. Reason: Missing Constraint: Import-Package:
> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
> at
> org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
> ... 31 more
> Caused by: org.osgi.framework.BundleException: The bundle could not
> be resolved. Reason: Missing Constraint: Import-Package:
> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
> ... 33 more
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 4.213 sec <<< FAILURE!
> testDummy(calculator.CalculatorTestCase) Time elapsed: 4.153 sec
> <<< ERROR!
> org.apache.tuscany.sca.node.equinox.launcher.LauncherException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:174)
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
> at
> calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
> at junit.framework.TestCase.runBare(TestCase.java:132)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
> Caused by: java.lang.reflect.InvocationTargetException
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
> ... 20 more
> Caused by: org.osoa.sca.ServiceRuntimeException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
> at
> org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
> ... 25 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
> ... 26 more
> Caused by: java.lang.IllegalStateException:
> org.osgi.framework.BundleException: The bundle could not be
> resolved. Reason: Missing Constraint: Import-Package:
> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
> at
> org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
> ... 31 more
> Caused by: org.osgi.framework.BundleException: The bundle could not
> be resolved. Reason: Missing Constraint: Import-Package:
> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
> ... 33 more
>
>
> I'm starting to fix node-impl to only reference SPIs but I've not
> been able to find what's causing the above exception, given that the
> unresolved contribution.impl package is exported+imported right now
> (as a workaround, but the workaround doesn't seem to work).
>
> So if anybody has ideas about that exception, please let me know...
>
> Thanks
> --
> Jean-Sebastien
>
>
>
> 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.
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.
--
Jean-Sebastien
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled Tuscany/SCA
Posted by ant elder <an...@gmail.com>.
On Wed, Oct 1, 2008 at 6:21 AM, Jean-Sebastien Delfino <jsdelfino@apache.org
> wrote:
> ant elder wrote:
>
>>
>>
>> On Mon, Sep 29, 2008 at 5:01 PM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org <ma...@apache.org>> wrote:
>>
>> ant elder wrote:
>>
>>
>>
>> On Thu, Sep 11, 2008 at 5:37 PM, Jean-Sebastien Delfino
>> <jsdelfino@apache.org <ma...@apache.org>
>> <mailto:jsdelfino@apache.org <ma...@apache.org>>>
>> wrote:
>>
>> <snip>
>>
>>
>> I'll create a branch to make progress on this Equinox porting
>> effort
>> without breaking everybody else. As I said before it'll probably
>> take a few weeks to get most Tuscany samples and itests up and
>> running, but I'd like to try to have a few core itests and
>> maybe a
>> Web Service or two working in the next few days.
>>
>>
>>
>> Its been a few weeks now, what are the plans and time frames for
>> merging this branch back into the mainstream trunk?
>>
>> ...ant
>>
>>
>> Still making progress on the Equinox bringup, going slowly as I'm
>> busy at work. Getting the whole runtime really working end to end in
>> Equinox is going to require changes in many different places in the
>> code, so don't expect miracles it's going to take time. Some of the
>> changes may be possible to merge to trunk already if people want to
>> help with that.
>>
>> -- Jean-Sebastien
>>
>>
>> The problem with helping is that its difficult to work out what are the
>> changes. I've done a diff of the sca-equinox branch to the trunk which is
>> at: http://people.apache.org/~antelder/temp/sca-equinox.diff<http://people.apache.org/%7Eantelder/temp/sca-equinox.diff>.
>> Its huge, and lots of the changes seem quite unrelated to OSGi class
>> loading. Some changes from trunk get merged to the branch, some don't,
>> others get modified and then merged, there's also what looks like new
>> development not directly related to OSGi/Equinox that goes into the branch
>> but not trunk. If this branch is to show what changes are needed for Equinox
>> then wouldn't it be clearer if the only changes in the branch were directly
>> related to Equinox? With the diff so huge now how can this ever get merged
>> to trunk?
>>
>> ...ant
>>
>>
> I've always had trouble too working off flat diffs like that. Merging /
> porting individual commits from the history should be easier. That's what
> I've been doing to pull some changes from trunk, and it's really easy once
> you've done it a few times and have defined your merge processes with the
> Svn, diff, patch tools etc. If you're interested in trying it, for more
> complicated cases (like when I started to create the android branch) I've
> also found Git very powerful at handling merges. Working off the history
> should also help you pick only the changes that are not going to break the
> trunk at this point, or pick them in a more convenient sequence for example.
>
> If that helps I could try to document the steps that I've been following
> for various merge cases but I'm busy these days so it'll probably take some
> time before I get to it.
>
> If people want to help, at the moment I'm seeing issues with many 'dirty'
> cross module dependencies (tapping directly into impl classes instead of
> going through the SPI.
>
> An example is dependencies on o.a.t.sca.contribution.impl, causing this:
>
> warning: Unresolved resource
> META-INF/services/org.apache.tuscany.sca.node.SCANodeFactory found in 15
> org.apache.tuscany.sca.node.impl INSTALLED
> severe: SCA Node could not be created
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
> at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
> at junit.framework.TestCase.runBare(TestCase.java:132)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
> Caused by: org.osoa.sca.ServiceRuntimeException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
> at
> org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
> ... 25 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
> ... 26 more
> Caused by: java.lang.IllegalStateException:
> org.osgi.framework.BundleException: The bundle could not be resolved.
> Reason: Missing Constraint: Import-Package:
> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
> at
> org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
> ... 31 more
> Caused by: org.osgi.framework.BundleException: The bundle could not be
> resolved. Reason: Missing Constraint: Import-Package:
> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
> ... 33 more
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.213 sec
> <<< FAILURE!
> testDummy(calculator.CalculatorTestCase) Time elapsed: 4.153 sec <<<
> ERROR!
> org.apache.tuscany.sca.node.equinox.launcher.LauncherException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:174)
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
> at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
> at junit.framework.TestCase.runBare(TestCase.java:132)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
> ... 20 more
> Caused by: org.osoa.sca.ServiceRuntimeException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
> at
> org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
> ... 25 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
> ... 26 more
> Caused by: java.lang.IllegalStateException:
> org.osgi.framework.BundleException: The bundle could not be resolved.
> Reason: Missing Constraint: Import-Package:
> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
> at
> org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
> ... 31 more
> Caused by: org.osgi.framework.BundleException: The bundle could not be
> resolved. Reason: Missing Constraint: Import-Package:
> org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
> at
> org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
> at
> org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
> at
> org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
> ... 33 more
>
>
> I'm starting to fix node-impl to only reference SPIs but I've not been able
> to find what's causing the above exception, given that the unresolved
> contribution.impl package is exported+imported right now (as a workaround,
> but the workaround doesn't seem to work).
>
> So if anybody has ideas about that exception, please let me know...
>
> Thanks
> --
> Jean-Sebastien
>
So this branch is really a fork isn't it?
...ant
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
>
>
> On Mon, Sep 29, 2008 at 5:01 PM, Jean-Sebastien Delfino
> <jsdelfino@apache.org <ma...@apache.org>> wrote:
>
> ant elder wrote:
>
>
>
> On Thu, Sep 11, 2008 at 5:37 PM, Jean-Sebastien Delfino
> <jsdelfino@apache.org <ma...@apache.org>
> <mailto:jsdelfino@apache.org <ma...@apache.org>>> wrote:
>
> <snip>
>
>
> I'll create a branch to make progress on this Equinox porting
> effort
> without breaking everybody else. As I said before it'll probably
> take a few weeks to get most Tuscany samples and itests up and
> running, but I'd like to try to have a few core itests and
> maybe a
> Web Service or two working in the next few days.
>
>
>
> Its been a few weeks now, what are the plans and time frames for
> merging this branch back into the mainstream trunk?
>
> ...ant
>
>
> Still making progress on the Equinox bringup, going slowly as I'm
> busy at work. Getting the whole runtime really working end to end in
> Equinox is going to require changes in many different places in the
> code, so don't expect miracles it's going to take time. Some of the
> changes may be possible to merge to trunk already if people want to
> help with that.
>
> --
> Jean-Sebastien
>
>
> The problem with helping is that its difficult to work out what are the
> changes. I've done a diff of the sca-equinox branch to the trunk which
> is at: http://people.apache.org/~antelder/temp/sca-equinox.diff. Its
> huge, and lots of the changes seem quite unrelated to OSGi class
> loading. Some changes from trunk get merged to the branch, some don't,
> others get modified and then merged, there's also what looks like new
> development not directly related to OSGi/Equinox that goes into the
> branch but not trunk. If this branch is to show what changes are needed
> for Equinox then wouldn't it be clearer if the only changes in the
> branch were directly related to Equinox? With the diff so huge now how
> can this ever get merged to trunk?
>
> ...ant
>
I've always had trouble too working off flat diffs like that. Merging /
porting individual commits from the history should be easier. That's
what I've been doing to pull some changes from trunk, and it's really
easy once you've done it a few times and have defined your merge
processes with the Svn, diff, patch tools etc. If you're interested in
trying it, for more complicated cases (like when I started to create the
android branch) I've also found Git very powerful at handling merges.
Working off the history should also help you pick only the changes that
are not going to break the trunk at this point, or pick them in a more
convenient sequence for example.
If that helps I could try to document the steps that I've been following
for various merge cases but I'm busy these days so it'll probably take
some time before I get to it.
If people want to help, at the moment I'm seeing issues with many
'dirty' cross module dependencies (tapping directly into impl classes
instead of going through the SPI.
An example is dependencies on o.a.t.sca.contribution.impl, causing this:
warning: Unresolved resource
META-INF/services/org.apache.tuscany.sca.node.SCANodeFactory found in 15
org.apache.tuscany.sca.node.impl INSTALLED
severe: SCA Node could not be created
java.lang.reflect.InvocationTargetException
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
Caused by: org.osoa.sca.ServiceRuntimeException:
java.lang.reflect.InvocationTargetException
at
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
at
org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
... 25 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
... 26 more
Caused by: java.lang.IllegalStateException:
org.osgi.framework.BundleException: The bundle could not be resolved.
Reason: Missing Constraint: Import-Package:
org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
at
org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
... 31 more
Caused by: org.osgi.framework.BundleException: The bundle could not be
resolved. Reason: Missing Constraint: Import-Package:
org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
... 33 more
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.213
sec <<< FAILURE!
testDummy(calculator.CalculatorTestCase) Time elapsed: 4.153 sec <<<
ERROR!
org.apache.tuscany.sca.node.equinox.launcher.LauncherException:
java.lang.reflect.InvocationTargetException
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:174)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
Caused by: java.lang.reflect.InvocationTargetException
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
... 20 more
Caused by: org.osoa.sca.ServiceRuntimeException:
java.lang.reflect.InvocationTargetException
at
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
at
org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
... 25 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
... 26 more
Caused by: java.lang.IllegalStateException:
org.osgi.framework.BundleException: The bundle could not be resolved.
Reason: Missing Constraint: Import-Package:
org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
at
org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
... 31 more
Caused by: org.osgi.framework.BundleException: The bundle could not be
resolved. Reason: Missing Constraint: Import-Package:
org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
... 33 more
I'm starting to fix node-impl to only reference SPIs but I've not been
able to find what's causing the above exception, given that the
unresolved contribution.impl package is exported+imported right now (as
a workaround, but the workaround doesn't seem to work).
So if anybody has ideas about that exception, please let me know...
Thanks
--
Jean-Sebastien
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled Tuscany/SCA
Posted by ant elder <an...@gmail.com>.
On Mon, Sep 29, 2008 at 5:01 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> ant elder wrote:
>
>>
>>
>> On Thu, Sep 11, 2008 at 5:37 PM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org <ma...@apache.org>> wrote:
>>
>> <snip>
>>
>>
>> I'll create a branch to make progress on this Equinox porting effort
>> without breaking everybody else. As I said before it'll probably
>> take a few weeks to get most Tuscany samples and itests up and
>> running, but I'd like to try to have a few core itests and maybe a
>> Web Service or two working in the next few days.
>>
>>
>>
>> Its been a few weeks now, what are the plans and time frames for merging
>> this branch back into the mainstream trunk?
>>
>> ...ant
>>
>>
> Still making progress on the Equinox bringup, going slowly as I'm busy at
> work. Getting the whole runtime really working end to end in Equinox is
> going to require changes in many different places in the code, so don't
> expect miracles it's going to take time. Some of the changes may be possible
> to merge to trunk already if people want to help with that.
>
> --
> Jean-Sebastien
>
The problem with helping is that its difficult to work out what are the
changes. I've done a diff of the sca-equinox branch to the trunk which is
at: http://people.apache.org/~antelder/temp/sca-equinox.diff. Its huge, and
lots of the changes seem quite unrelated to OSGi class loading. Some changes
from trunk get merged to the branch, some don't, others get modified and
then merged, there's also what looks like new development not directly
related to OSGi/Equinox that goes into the branch but not trunk. If this
branch is to show what changes are needed for Equinox then wouldn't it be
clearer if the only changes in the branch were directly related to Equinox?
With the diff so huge now how can this ever get merged to trunk?
...ant
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
>
>
> On Thu, Sep 11, 2008 at 5:37 PM, Jean-Sebastien Delfino
> <jsdelfino@apache.org <ma...@apache.org>> wrote:
>
> <snip>
>
>
> I'll create a branch to make progress on this Equinox porting effort
> without breaking everybody else. As I said before it'll probably
> take a few weeks to get most Tuscany samples and itests up and
> running, but I'd like to try to have a few core itests and maybe a
> Web Service or two working in the next few days.
>
>
>
> Its been a few weeks now, what are the plans and time frames for merging
> this branch back into the mainstream trunk?
>
> ...ant
>
Still making progress on the Equinox bringup, going slowly as I'm busy
at work. Getting the whole runtime really working end to end in Equinox
is going to require changes in many different places in the code, so
don't expect miracles it's going to take time. Some of the changes may
be possible to merge to trunk already if people want to help with that.
--
Jean-Sebastien
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled Tuscany/SCA
Posted by ant elder <an...@gmail.com>.
On Thu, Sep 11, 2008 at 5:37 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
<snip>
> I'll create a branch to make progress on this Equinox porting effort
> without breaking everybody else. As I said before it'll probably take a few
> weeks to get most Tuscany samples and itests up and running, but I'd like to
> try to have a few core itests and maybe a Web Service or two working in the
> next few days.
>
>
Its been a few weeks now, what are the plans and time frames for merging
this branch back into the mainstream trunk?
...ant
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> One question inline.
>
> Simon
>
> Jean-Sebastien Delfino wrote:
>> Jean-Sebastien Delfino wrote:
>>> Jean-Sebastien Delfino wrote:
>>>> Raymond Feng wrote:
>>>>> From: "Graham Charters" <gc...@googlemail.com>
>>>> ...
>>>>>> I see from the design (and also the module name :-) ) that this work
>>>>>> is Equinox-specific and will not work in other OSGi runtimes. I
>>>>>> think
>>>>>> it would be a shame to make this the only way to use an OSGi
>>>>>> implementation and I know Rajini worked very hard to ensure the osgi
>>>>>> runtime work she did also supported Apache Felix. Is the
>>>>>> intention to
>>>>>> deprecate support for other OSGi implementations?
>>>>>
>>>>> We use Equinox to get the idea working. It doesn't really prevent
>>>>> other OSGi runtime from supporting the same design.
>>>>> For Apache Felix, we can just slightly change the way how we create
>>>>> the virtual bundle for 3rd party jars (it might be a
>>>>> bit more expensive as Felix doesn't support "external" classpaths
>>>>> for the "Bundle-ClassPath" entry and we can create a folder-based
>>>>> bundle that include the 3rd party jars).
>>>>>
>>>>> BTW, it might be worth trying to propose the Hook ideas to Felix to
>>>>> support various Bundle formats, Bundle wrapping and ClassLoading :-).
>>>>>
>>>>
>>>> Right, I was not thinking about making this 'the only way' or
>>>> deprecating the osgi modules either. I see this a bit like what
>>>> we've done for server runtime integrations, where several runtime
>>>> integrations can co-exist (e.g. Tomcat, Jetty, Geronimo), we try to
>>>> use common code when convenient, and maybe we can also have a more
>>>> generic integration story like what we've done or Webapps for example.
>>>>
>>>> Also, I like Raymond's idea to propose/ask the Felix team for hooks
>>>> that will help us integrate Felix with Tuscany.
>>>>
>>>> One aspect I'm really interested in at the moment is to try to get
>>>> all (or almost all) of Tuscany working smoothly in an OSGi
>>>> environment, but I must say I'm a little stuck on how to try that
>>>> without making many changes to the whole code base (like some
>>>> surgery in all the modules that do not behave correctly
>>>> classloading-wise, and revisit all samples and test cases which are
>>>> not designed to work in OSGi). Any thoughts are welcome.
>>>
>>> Yesterday evening I made one more minor change to
>>> node-launcher-equinox and simplified it a bit as it didn't really
>>> need a BundleActivator to initialize itself (since it's main function
>>> is to be actively 'launched' anyway). I just committed that small
>>> change this morning.
>>>
>>> I've started to look at how to change samples and test cases to work
>>> in OSGi with the OSGi based launchers, tried the helloworld WS and
>>> store samples and ran into errors (ClassLoading issues again in the
>>> Tuscany code and Axis2).
>>>
>>> I also tried the calculator-rcp app that Raymond has started to work
>>> on and realized that for it to work all other modules should be seen
>>> as PDE plugin projects in my IDE. I tried to convert the sca-api
>>> module to a plugin and that made calculator-rcp compile at least.
>>>
>>> Obviously I'm not going to commit any of these changes right now as
>>> they would be pretty disruptive, but I just wanted to give an update.
>>>
>>> I think that getting the whole all Tuscany working in OSGi is going
>>> to require a serious effort of several weeks and changes in many
>>> different places in the code.
>>>
>>
>> I've made some progress since yesterday:
>> - changed the build as suggested by Raymond in [1];
>> - started to change calls to getContextClassLoader(), about 70 places
>> across the Tuscany code;
>> - ported some of the samples and itests to use the Equinox launcher;
> >
> Does this mean that these samples and itests would be dependent on
> Equinox? Or is there some other way of running them in a non-Equinox
> environment?
>
I'm not sure actually. Time will tell.
RCP samples like calculator-rcp are RCP/Equinox specific.
OSGi based samples (like samples packaged as OSGi bundles) are probably
OSGi specific.
Other samples or itests may reference the Equinox launcher so I guess
that makes them Equinox specific? or maybe later that launcher gets
merged with the default one and then they're not Equinox specific anymore?
I guess I'll discover more options as I work through this. Just my 2c,
others may find other valid paths as they experiment with OSGi and
Equinox as well.
--
Jean-Sebastien
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Simon Nash <na...@apache.org>.
One question inline.
Simon
Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>> Jean-Sebastien Delfino wrote:
>>> Raymond Feng wrote:
>>>> From: "Graham Charters" <gc...@googlemail.com>
>>> ...
>>>>> I see from the design (and also the module name :-) ) that this work
>>>>> is Equinox-specific and will not work in other OSGi runtimes. I think
>>>>> it would be a shame to make this the only way to use an OSGi
>>>>> implementation and I know Rajini worked very hard to ensure the osgi
>>>>> runtime work she did also supported Apache Felix. Is the intention to
>>>>> deprecate support for other OSGi implementations?
>>>>
>>>> We use Equinox to get the idea working. It doesn't really prevent
>>>> other OSGi runtime from supporting the same design.
>>>> For Apache Felix, we can just slightly change the way how we create
>>>> the virtual bundle for 3rd party jars (it might be a
>>>> bit more expensive as Felix doesn't support "external" classpaths
>>>> for the "Bundle-ClassPath" entry and we can create a folder-based
>>>> bundle that include the 3rd party jars).
>>>>
>>>> BTW, it might be worth trying to propose the Hook ideas to Felix to
>>>> support various Bundle formats, Bundle wrapping and ClassLoading :-).
>>>>
>>>
>>> Right, I was not thinking about making this 'the only way' or
>>> deprecating the osgi modules either. I see this a bit like what we've
>>> done for server runtime integrations, where several runtime
>>> integrations can co-exist (e.g. Tomcat, Jetty, Geronimo), we try to
>>> use common code when convenient, and maybe we can also have a more
>>> generic integration story like what we've done or Webapps for example.
>>>
>>> Also, I like Raymond's idea to propose/ask the Felix team for hooks
>>> that will help us integrate Felix with Tuscany.
>>>
>>> One aspect I'm really interested in at the moment is to try to get
>>> all (or almost all) of Tuscany working smoothly in an OSGi
>>> environment, but I must say I'm a little stuck on how to try that
>>> without making many changes to the whole code base (like some surgery
>>> in all the modules that do not behave correctly classloading-wise,
>>> and revisit all samples and test cases which are not designed to work
>>> in OSGi). Any thoughts are welcome.
>>
>> Yesterday evening I made one more minor change to
>> node-launcher-equinox and simplified it a bit as it didn't really need
>> a BundleActivator to initialize itself (since it's main function is to
>> be actively 'launched' anyway). I just committed that small change
>> this morning.
>>
>> I've started to look at how to change samples and test cases to work
>> in OSGi with the OSGi based launchers, tried the helloworld WS and
>> store samples and ran into errors (ClassLoading issues again in the
>> Tuscany code and Axis2).
>>
>> I also tried the calculator-rcp app that Raymond has started to work
>> on and realized that for it to work all other modules should be seen
>> as PDE plugin projects in my IDE. I tried to convert the sca-api
>> module to a plugin and that made calculator-rcp compile at least.
>>
>> Obviously I'm not going to commit any of these changes right now as
>> they would be pretty disruptive, but I just wanted to give an update.
>>
>> I think that getting the whole all Tuscany working in OSGi is going to
>> require a serious effort of several weeks and changes in many
>> different places in the code.
>>
>
> I've made some progress since yesterday:
> - changed the build as suggested by Raymond in [1];
> - started to change calls to getContextClassLoader(), about 70 places
> across the Tuscany code;
> - ported some of the samples and itests to use the Equinox launcher;
>
Does this mean that these samples and itests would be dependent on
Equinox? Or is there some other way of running them in a non-Equinox
environment?
Simon
> - and started to debug issues with Tomcat and Axis2 in this environment.
>
> I'll create a branch to make progress on this Equinox porting effort
> without breaking everybody else. As I said before it'll probably take a
> few weeks to get most Tuscany samples and itests up and running, but I'd
> like to try to have a few core itests and maybe a Web Service or two
> working in the next few days.
>
> I hope others can jump in if they are interested and help debug some of
> these classloading issues: ClassNotFoundException, NoClassDefFoundError,
> IncompatibleClassChangeError... pick your exception :)
>
> [1] http://marc.info/?l=tuscany-dev&m=122107319814317
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>> Raymond Feng wrote:
>>> From: "Graham Charters" <gc...@googlemail.com>
>> ...
>>>> I see from the design (and also the module name :-) ) that this work
>>>> is Equinox-specific and will not work in other OSGi runtimes. I think
>>>> it would be a shame to make this the only way to use an OSGi
>>>> implementation and I know Rajini worked very hard to ensure the osgi
>>>> runtime work she did also supported Apache Felix. Is the intention to
>>>> deprecate support for other OSGi implementations?
>>>
>>> We use Equinox to get the idea working. It doesn't really prevent
>>> other OSGi runtime from supporting the same design.
>>> For Apache Felix, we can just slightly change the way how we create
>>> the virtual bundle for 3rd party jars (it might be a
>>> bit more expensive as Felix doesn't support "external" classpaths for
>>> the "Bundle-ClassPath" entry and we can create a folder-based
>>> bundle that include the 3rd party jars).
>>>
>>> BTW, it might be worth trying to propose the Hook ideas to Felix to
>>> support various Bundle formats, Bundle wrapping and ClassLoading :-).
>>>
>>
>> Right, I was not thinking about making this 'the only way' or
>> deprecating the osgi modules either. I see this a bit like what we've
>> done for server runtime integrations, where several runtime
>> integrations can co-exist (e.g. Tomcat, Jetty, Geronimo), we try to
>> use common code when convenient, and maybe we can also have a more
>> generic integration story like what we've done or Webapps for example.
>>
>> Also, I like Raymond's idea to propose/ask the Felix team for hooks
>> that will help us integrate Felix with Tuscany.
>>
>> One aspect I'm really interested in at the moment is to try to get all
>> (or almost all) of Tuscany working smoothly in an OSGi environment,
>> but I must say I'm a little stuck on how to try that without making
>> many changes to the whole code base (like some surgery in all the
>> modules that do not behave correctly classloading-wise, and revisit
>> all samples and test cases which are not designed to work in OSGi).
>> Any thoughts are welcome.
>
> Yesterday evening I made one more minor change to node-launcher-equinox
> and simplified it a bit as it didn't really need a BundleActivator to
> initialize itself (since it's main function is to be actively 'launched'
> anyway). I just committed that small change this morning.
>
> I've started to look at how to change samples and test cases to work in
> OSGi with the OSGi based launchers, tried the helloworld WS and store
> samples and ran into errors (ClassLoading issues again in the Tuscany
> code and Axis2).
>
> I also tried the calculator-rcp app that Raymond has started to work on
> and realized that for it to work all other modules should be seen as PDE
> plugin projects in my IDE. I tried to convert the sca-api module to a
> plugin and that made calculator-rcp compile at least.
>
> Obviously I'm not going to commit any of these changes right now as they
> would be pretty disruptive, but I just wanted to give an update.
>
> I think that getting the whole all Tuscany working in OSGi is going to
> require a serious effort of several weeks and changes in many different
> places in the code.
>
I've made some progress since yesterday:
- changed the build as suggested by Raymond in [1];
- started to change calls to getContextClassLoader(), about 70 places
across the Tuscany code;
- ported some of the samples and itests to use the Equinox launcher;
- and started to debug issues with Tomcat and Axis2 in this environment.
I'll create a branch to make progress on this Equinox porting effort
without breaking everybody else. As I said before it'll probably take a
few weeks to get most Tuscany samples and itests up and running, but I'd
like to try to have a few core itests and maybe a Web Service or two
working in the next few days.
I hope others can jump in if they are interested and help debug some of
these classloading issues: ClassNotFoundException, NoClassDefFoundError,
IncompatibleClassChangeError... pick your exception :)
[1] http://marc.info/?l=tuscany-dev&m=122107319814317
--
Jean-Sebastien
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Raymond Feng wrote:
>> From: "Graham Charters" <gc...@googlemail.com>
> ...
>>> I see from the design (and also the module name :-) ) that this work
>>> is Equinox-specific and will not work in other OSGi runtimes. I think
>>> it would be a shame to make this the only way to use an OSGi
>>> implementation and I know Rajini worked very hard to ensure the osgi
>>> runtime work she did also supported Apache Felix. Is the intention to
>>> deprecate support for other OSGi implementations?
>>
>> We use Equinox to get the idea working. It doesn't really prevent
>> other OSGi runtime from supporting the same design.
>> For Apache Felix, we can just slightly change the way how we create
>> the virtual bundle for 3rd party jars (it might be a
>> bit more expensive as Felix doesn't support "external" classpaths for
>> the "Bundle-ClassPath" entry and we can create a folder-based
>> bundle that include the 3rd party jars).
>>
>> BTW, it might be worth trying to propose the Hook ideas to Felix to
>> support various Bundle formats, Bundle wrapping and ClassLoading :-).
>>
>
> Right, I was not thinking about making this 'the only way' or
> deprecating the osgi modules either. I see this a bit like what we've
> done for server runtime integrations, where several runtime integrations
> can co-exist (e.g. Tomcat, Jetty, Geronimo), we try to use common code
> when convenient, and maybe we can also have a more generic integration
> story like what we've done or Webapps for example.
>
> Also, I like Raymond's idea to propose/ask the Felix team for hooks that
> will help us integrate Felix with Tuscany.
>
> One aspect I'm really interested in at the moment is to try to get all
> (or almost all) of Tuscany working smoothly in an OSGi environment, but
> I must say I'm a little stuck on how to try that without making many
> changes to the whole code base (like some surgery in all the modules
> that do not behave correctly classloading-wise, and revisit all samples
> and test cases which are not designed to work in OSGi). Any thoughts are
> welcome.
Yesterday evening I made one more minor change to node-launcher-equinox
and simplified it a bit as it didn't really need a BundleActivator to
initialize itself (since it's main function is to be actively 'launched'
anyway). I just committed that small change this morning.
I've started to look at how to change samples and test cases to work in
OSGi with the OSGi based launchers, tried the helloworld WS and store
samples and ran into errors (ClassLoading issues again in the Tuscany
code and Axis2).
I also tried the calculator-rcp app that Raymond has started to work on
and realized that for it to work all other modules should be seen as PDE
plugin projects in my IDE. I tried to convert the sca-api module to a
plugin and that made calculator-rcp compile at least.
Obviously I'm not going to commit any of these changes right now as they
would be pretty disruptive, but I just wanted to give an update.
I think that getting the whole all Tuscany working in OSGi is going to
require a serious effort of several weeks and changes in many different
places in the code.
--
Jean-Sebastien
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> From: "Graham Charters" <gc...@googlemail.com>
...
>> I see from the design (and also the module name :-) ) that this work
>> is Equinox-specific and will not work in other OSGi runtimes. I think
>> it would be a shame to make this the only way to use an OSGi
>> implementation and I know Rajini worked very hard to ensure the osgi
>> runtime work she did also supported Apache Felix. Is the intention to
>> deprecate support for other OSGi implementations?
>
> We use Equinox to get the idea working. It doesn't really prevent other
> OSGi runtime from supporting the same design.
> For Apache Felix, we can just slightly change the way how we create the
> virtual bundle for 3rd party jars (it might be a
> bit more expensive as Felix doesn't support "external" classpaths for
> the "Bundle-ClassPath" entry and we can create a folder-based
> bundle that include the 3rd party jars).
>
> BTW, it might be worth trying to propose the Hook ideas to Felix to
> support various Bundle formats, Bundle wrapping and ClassLoading :-).
>
Right, I was not thinking about making this 'the only way' or
deprecating the osgi modules either. I see this a bit like what we've
done for server runtime integrations, where several runtime integrations
can co-exist (e.g. Tomcat, Jetty, Geronimo), we try to use common code
when convenient, and maybe we can also have a more generic integration
story like what we've done or Webapps for example.
Also, I like Raymond's idea to propose/ask the Felix team for hooks that
will help us integrate Felix with Tuscany.
One aspect I'm really interested in at the moment is to try to get all
(or almost all) of Tuscany working smoothly in an OSGi environment, but
I must say I'm a little stuck on how to try that without making many
changes to the whole code base (like some surgery in all the modules
that do not behave correctly classloading-wise, and revisit all samples
and test cases which are not designed to work in OSGi). Any thoughts are
welcome.
>> Regarding Class.forName and TCCL, you might find the following blog
>> posts from BJ Hargrave interesting. I'm not sure whether these
>> circumstances are likely to arise in Tuscany, but it's something to be
>> aware of:
>>
>> http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html
>>
>> http://blog.bjhargrave.com/2007/07/contextfinder-in-eclipse-is-broken.html
Have read these two entries several times after each ClassNotFound
exception the last few days :)
>> Regarding META-INF/services, is there any reason why we couldn't use
>> the OSGi service registry to register and discover these services?
>> The more we use of standard OSGi capabilities, the more we can perhaps
>> leverage standard or third-party tools for things like configuration,
>> administration, analysis, etc...
>>
>
> One reason is that we want to keep the support to run Tuscany in an
> environment without OSGi.
>
Here too I think we can be flexible and use implementations of
ServiceDiscoverer that leverage the facilities provided by J2SE, OSGi in
general and/or specific OSGi implementations. The OSGi service registry
is an option if people want to try that, as well as the Eclipse plugin
registry for example.
--
Jean-Sebastien
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled Tuscany/SCA
Posted by Raymond Feng <en...@gmail.com>.
Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Graham Charters" <gc...@googlemail.com>
Sent: Tuesday, September 09, 2008 4:46 AM
To: <de...@tuscany.apache.org>
Subject: Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
> Hi Sebastien,
>
> I see from the design (and also the module name :-) ) that this work
> is Equinox-specific and will not work in other OSGi runtimes. I think
> it would be a shame to make this the only way to use an OSGi
> implementation and I know Rajini worked very hard to ensure the osgi
> runtime work she did also supported Apache Felix. Is the intention to
> deprecate support for other OSGi implementations?
We use Equinox to get the idea working. It doesn't really prevent other OSGi
runtime from supporting the same design.
For Apache Felix, we can just slightly change the way how we create the
virtual bundle for 3rd party jars (it might be a
bit more expensive as Felix doesn't support "external" classpaths for the
"Bundle-ClassPath" entry and we can create a folder-based
bundle that include the 3rd party jars).
BTW, it might be worth trying to propose the Hook ideas to Felix to support
various Bundle formats, Bundle wrapping and ClassLoading :-).
>
> Regarding Class.forName and TCCL, you might find the following blog
> posts from BJ Hargrave interesting. I'm not sure whether these
> circumstances are likely to arise in Tuscany, but it's something to be
> aware of:
>
> http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html
> http://blog.bjhargrave.com/2007/07/contextfinder-in-eclipse-is-broken.html
>
> Regarding META-INF/services, is there any reason why we couldn't use
> the OSGi service registry to register and discover these services?
> The more we use of standard OSGi capabilities, the more we can perhaps
> leverage standard or third-party tools for things like configuration,
> administration, analysis, etc...
>
One reason is that we want to keep the support to run Tuscany in an
environment without OSGi.
> Regards, Graham.
>
>
> 2008/9/9 Jean-Sebastien Delfino <js...@apache.org>:
>> Jean-Sebastien Delfino wrote:
>>>
>>> Rajini Sivaram wrote:
>>>>
>>>>
>>>> On 8/29/08, *Raymond Feng* <enjoyjava@gmail.com
>>>> <ma...@gmail.com>> wrote:
>>>>
>>>> Great!
>>>>
>>>> Worth to point out is that [1] can preprocess the 3rd party jars to
>>>> be OSGi bundles instead of on-the-fly conversion during runtime.
>>>>
>>>> Based on the discussion in one of the other threads, I would also like
>>>> to point out that the manifest entries of Tuscany modules are also
>>>> modified
>>>> by tuscany-maven-bundle-plugin to introduce versioning. So for creating
>>>> distributions, it will be good if you can use both Tuscany modules and
>>>> 3rd
>>>> party jars generated by tuscany-maven-bundle-plugin.
>>>>
>>>
>>> Here's what I'm going to try:
>>>
>>> a) put the right versioning in the Tuscany modules when they are built,
>>> to
>>> avoid having to post-process them;
>>>
>>> b) derive the OSGi metadata from 3rd party jars on the fly from their
>>> Maven metadata, to not require two copies of these JARs;
>>>
>>> c) do (b) in a
>>> org.eclipse.osgi.baseadaptor.hooks.BundleFileWrapperFactoryHook, to
>>> avoid
>>> having to read/rewrite/read the whole JAR in memory like we currently
>>> do.
>>>
>>
>> With the nice improvements to the Equinox integration made by Raymond the
>> last few days, and a few more fixes that I just committed, I'm able to
>> get a
>> simple end to end scenario working with Tuscany / Equinox.
>>
>> One of the initial difficulties, if I understand correctly, was to handle
>> non-bundle 3rd party JARs. Here's how node-launcher-equinox handles them
>> now, and that seems to work quite nicely.
>>
>> 1) The launcher looks for runtime JARs and class folders in a Tuscany
>> distribution install or just the classpath entries used to start it.
>>
>> 2) Then it looks for OSGi Bundle-SymbolicName entries in their manifests
>> to
>> determine if they are OSGi bundles or just regular JARs.
>>
>> 3) It creates a single in-memory bundle for these regular JARs, in an
>> Equinox BundleFileFactoryHook:
>> - export and import all their packages
>> - import * with a DynamicImport
>> - reference the JARs outside of the bundle in Bundle-classpath
>>
>> That step is fast as it just writes a Manifest to a byte[] in memory,
>> with
>> no need to copy the JARs and re-package them, as the manifest simply
>> references their actual locations.
>>
>> 4) Bundle tuscany-extensibility-equinox contains a DynamicImport *,
>> enabling
>> ServiceDiscovery to access the 3rd party packages.
>>
>> 5) Instead of Thread.getContextClassLoader(), Tuscany code must use
>> Class.forName() from modules that have the proper imports, and the
>> Tuscany
>> ServiceDiscovery to discover META-INF/services.
>>
>> The above seems to work well in the following environments:
>> - an installed distro, JARs and bundles are loaded from the distro
>> - Maven surefire, classes are loaded from the Maven repos
>> - an Eclipse project, classes are loaded from the project's classpath
>>
>> If people want to try it, the calculator-osgi sample is a (simplistic)
>> example that shows how to use the Equinox-based Tuscany launcher.
>>
>> It would be nice to have another sample showing how to use SCA from an
>> Equinox RCP application as that's a scenario that users have talked about
>> on
>> the Tuscany user list.
>>
>> Obviously a lot more work is needed to get all of Tuscany working well on
>> Equinox with a good development / build / test experience but that looks
>> encouraging to me.
>>
>> Hope this helps.
>> --
>> Jean-Sebastien
>>
Re: Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled Tuscany/SCA
Posted by Graham Charters <gc...@googlemail.com>.
Hi Sebastien,
I see from the design (and also the module name :-) ) that this work
is Equinox-specific and will not work in other OSGi runtimes. I think
it would be a shame to make this the only way to use an OSGi
implementation and I know Rajini worked very hard to ensure the osgi
runtime work she did also supported Apache Felix. Is the intention to
deprecate support for other OSGi implementations?
Regarding Class.forName and TCCL, you might find the following blog
posts from BJ Hargrave interesting. I'm not sure whether these
circumstances are likely to arise in Tuscany, but it's something to be
aware of:
http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html
http://blog.bjhargrave.com/2007/07/contextfinder-in-eclipse-is-broken.html
Regarding META-INF/services, is there any reason why we couldn't use
the OSGi service registry to register and discover these services?
The more we use of standard OSGi capabilities, the more we can perhaps
leverage standard or third-party tools for things like configuration,
administration, analysis, etc...
Regards, Graham.
2008/9/9 Jean-Sebastien Delfino <js...@apache.org>:
> Jean-Sebastien Delfino wrote:
>>
>> Rajini Sivaram wrote:
>>>
>>>
>>> On 8/29/08, *Raymond Feng* <enjoyjava@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> Great!
>>>
>>> Worth to point out is that [1] can preprocess the 3rd party jars to
>>> be OSGi bundles instead of on-the-fly conversion during runtime.
>>>
>>> Based on the discussion in one of the other threads, I would also like
>>> to point out that the manifest entries of Tuscany modules are also modified
>>> by tuscany-maven-bundle-plugin to introduce versioning. So for creating
>>> distributions, it will be good if you can use both Tuscany modules and 3rd
>>> party jars generated by tuscany-maven-bundle-plugin.
>>>
>>
>> Here's what I'm going to try:
>>
>> a) put the right versioning in the Tuscany modules when they are built, to
>> avoid having to post-process them;
>>
>> b) derive the OSGi metadata from 3rd party jars on the fly from their
>> Maven metadata, to not require two copies of these JARs;
>>
>> c) do (b) in a
>> org.eclipse.osgi.baseadaptor.hooks.BundleFileWrapperFactoryHook, to avoid
>> having to read/rewrite/read the whole JAR in memory like we currently do.
>>
>
> With the nice improvements to the Equinox integration made by Raymond the
> last few days, and a few more fixes that I just committed, I'm able to get a
> simple end to end scenario working with Tuscany / Equinox.
>
> One of the initial difficulties, if I understand correctly, was to handle
> non-bundle 3rd party JARs. Here's how node-launcher-equinox handles them
> now, and that seems to work quite nicely.
>
> 1) The launcher looks for runtime JARs and class folders in a Tuscany
> distribution install or just the classpath entries used to start it.
>
> 2) Then it looks for OSGi Bundle-SymbolicName entries in their manifests to
> determine if they are OSGi bundles or just regular JARs.
>
> 3) It creates a single in-memory bundle for these regular JARs, in an
> Equinox BundleFileFactoryHook:
> - export and import all their packages
> - import * with a DynamicImport
> - reference the JARs outside of the bundle in Bundle-classpath
>
> That step is fast as it just writes a Manifest to a byte[] in memory, with
> no need to copy the JARs and re-package them, as the manifest simply
> references their actual locations.
>
> 4) Bundle tuscany-extensibility-equinox contains a DynamicImport *, enabling
> ServiceDiscovery to access the 3rd party packages.
>
> 5) Instead of Thread.getContextClassLoader(), Tuscany code must use
> Class.forName() from modules that have the proper imports, and the Tuscany
> ServiceDiscovery to discover META-INF/services.
>
> The above seems to work well in the following environments:
> - an installed distro, JARs and bundles are loaded from the distro
> - Maven surefire, classes are loaded from the Maven repos
> - an Eclipse project, classes are loaded from the project's classpath
>
> If people want to try it, the calculator-osgi sample is a (simplistic)
> example that shows how to use the Equinox-based Tuscany launcher.
>
> It would be nice to have another sample showing how to use SCA from an
> Equinox RCP application as that's a scenario that users have talked about on
> the Tuscany user list.
>
> Obviously a lot more work is needed to get all of Tuscany working well on
> Equinox with a good development / build / test experience but that looks
> encouraging to me.
>
> Hope this helps.
> --
> Jean-Sebastien
>
Tuscany / Equinox-OSGi integration, was: Creating distros for OSGi-enabled
Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Rajini Sivaram wrote:
>>
>>
>> On 8/29/08, *Raymond Feng* <enjoyjava@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Great!
>>
>> Worth to point out is that [1] can preprocess the 3rd party jars to
>> be OSGi bundles instead of on-the-fly conversion during runtime.
>>
>>
>> Based on the discussion in one of the other threads, I would also like
>> to point out that the manifest entries of Tuscany modules are also
>> modified by tuscany-maven-bundle-plugin to introduce versioning. So
>> for creating distributions, it will be good if you can use both
>> Tuscany modules and 3rd party jars generated by
>> tuscany-maven-bundle-plugin.
>>
>
> Here's what I'm going to try:
>
> a) put the right versioning in the Tuscany modules when they are built,
> to avoid having to post-process them;
>
> b) derive the OSGi metadata from 3rd party jars on the fly from their
> Maven metadata, to not require two copies of these JARs;
>
> c) do (b) in a
> org.eclipse.osgi.baseadaptor.hooks.BundleFileWrapperFactoryHook, to
> avoid having to read/rewrite/read the whole JAR in memory like we
> currently do.
>
With the nice improvements to the Equinox integration made by Raymond
the last few days, and a few more fixes that I just committed, I'm able
to get a simple end to end scenario working with Tuscany / Equinox.
One of the initial difficulties, if I understand correctly, was to
handle non-bundle 3rd party JARs. Here's how node-launcher-equinox
handles them now, and that seems to work quite nicely.
1) The launcher looks for runtime JARs and class folders in a Tuscany
distribution install or just the classpath entries used to start it.
2) Then it looks for OSGi Bundle-SymbolicName entries in their manifests
to determine if they are OSGi bundles or just regular JARs.
3) It creates a single in-memory bundle for these regular JARs, in an
Equinox BundleFileFactoryHook:
- export and import all their packages
- import * with a DynamicImport
- reference the JARs outside of the bundle in Bundle-classpath
That step is fast as it just writes a Manifest to a byte[] in memory,
with no need to copy the JARs and re-package them, as the manifest
simply references their actual locations.
4) Bundle tuscany-extensibility-equinox contains a DynamicImport *,
enabling ServiceDiscovery to access the 3rd party packages.
5) Instead of Thread.getContextClassLoader(), Tuscany code must use
Class.forName() from modules that have the proper imports, and the
Tuscany ServiceDiscovery to discover META-INF/services.
The above seems to work well in the following environments:
- an installed distro, JARs and bundles are loaded from the distro
- Maven surefire, classes are loaded from the Maven repos
- an Eclipse project, classes are loaded from the project's classpath
If people want to try it, the calculator-osgi sample is a (simplistic)
example that shows how to use the Equinox-based Tuscany launcher.
It would be nice to have another sample showing how to use SCA from an
Equinox RCP application as that's a scenario that users have talked
about on the Tuscany user list.
Obviously a lot more work is needed to get all of Tuscany working well
on Equinox with a good development / build / test experience but that
looks encouraging to me.
Hope this helps.
--
Jean-Sebastien
Re: Creating distros for OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
> Rajini Sivaram wrote:
>> On 8/29/08, *Raymond Feng* <enjoyjava@gmail.com
>> <ma...@gmail.com>> wrote:
...
>> Worth to point out is that [1] can preprocess the 3rd party jars to
>> be OSGi bundles instead of on-the-fly conversion during runtime.
...
>> Based on the discussion in one of the other threads, I would also like
>> to point out that the manifest entries of Tuscany modules are also
>> modified by tuscany-maven-bundle-plugin to introduce versioning.
I've tried a few bundles and the only difference I can see in the JARs
processed by the tuscany-maven-bundle plugin is version ranges like
"[1.4, 1.5.0)" in the imports of other Tuscany packages instead of a
fixed version number "[1.4]".
Is that what you're talking about?
For the Tuscany JARs, is the tuscany-maven-plugin doing anything else
than adding these ranges? Did I miss something? (I could easily have as
the entries of the JARs I was comparing were all shuffled in different
sequences)
Thanks
--
Jean-Sebastien
Re: Creating distros for OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Rajini Sivaram wrote:
>
>
> On 8/29/08, *Raymond Feng* <enjoyjava@gmail.com
> <ma...@gmail.com>> wrote:
>
> Great!
>
> Worth to point out is that [1] can preprocess the 3rd party jars to
> be OSGi bundles instead of on-the-fly conversion during runtime.
>
>
> Based on the discussion in one of the other threads, I would also like
> to point out that the manifest entries of Tuscany modules are also
> modified by tuscany-maven-bundle-plugin to introduce versioning. So for
> creating distributions, it will be good if you can use both Tuscany
> modules and 3rd party jars generated by tuscany-maven-bundle-plugin.
>
Here's what I'm going to try:
a) put the right versioning in the Tuscany modules when they are built,
to avoid having to post-process them;
b) derive the OSGi metadata from 3rd party jars on the fly from their
Maven metadata, to not require two copies of these JARs;
c) do (b) in a
org.eclipse.osgi.baseadaptor.hooks.BundleFileWrapperFactoryHook, to
avoid having to read/rewrite/read the whole JAR in memory like we
currently do.
--
Jean-Sebastien
Re: Creating distros for OSGi-enabled Tuscany/SCA
Posted by Rajini Sivaram <ra...@googlemail.com>.
On 8/29/08, Raymond Feng <en...@gmail.com> wrote:
>
> Great!
>
> Worth to point out is that [1] can preprocess the 3rd party jars to be OSGi
> bundles instead of on-the-fly conversion during runtime.
Based on the discussion in one of the other threads, I would also like to
point out that the manifest entries of Tuscany modules are also modified by
tuscany-maven-bundle-plugin to introduce versioning. So for creating
distributions, it will be good if you can use both Tuscany modules and 3rd
party jars generated by tuscany-maven-bundle-plugin.
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Jean-Sebastien Delfino" <js...@apache.org>
> Sent: Friday, August 29, 2008 10:03 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: Creating distros for OSGi-enabled Tuscany/SCA
>
> Raymond Feng wrote:
>>
>>> Hi,
>>>
>>> I noticed that a new module [1] has been added to produce OSGi bundles
>>> for tuscany modules and 3rd party jars. I propose that we integrate with
>>> this effort with the list of distros following the practice we have at [2].
>>> [2] already defines a set of features that collects related tuscany modules
>>> and 3rd party dependencies.
>>>
>>> Basically, we can probably add a new profile on top of [2] to preprocess
>>> the 3rd party jars to be OSGi bundles before the maven-assembly-plugin
>>> packages them into distros. When we run the maven build with the OSGi
>>> profile, the distros should be ready for OSGi.
>>>
>>> Thanks,
>>> Raymond
>>>
>>> [1]
>>> http://svn.apache.org/repos/asf/tuscany/java/sca/itest/osgi-tuscany/tuscany-versioned/[2]
>>> http://svn.apache.org/repos/asf/tuscany/java/sca/distribution/features/
>>>
>>
>> Raymond, I am working on doing that in [2] in the default profile. That's
>> one of the things I've been experimenting with, triggering the few questions
>> I was asking on the user list.
>>
>> --
>> Jean-Sebastien
>>
>
>
--
Thank you...
Regards,
Rajini
Re: Creating distros for OSGi-enabled Tuscany/SCA
Posted by Raymond Feng <en...@gmail.com>.
Great!
Worth to point out is that [1] can preprocess the 3rd party jars to be OSGi
bundles instead of on-the-fly conversion during runtime.
Thanks,
Raymond
--------------------------------------------------
From: "Jean-Sebastien Delfino" <js...@apache.org>
Sent: Friday, August 29, 2008 10:03 AM
To: <de...@tuscany.apache.org>
Subject: Re: Creating distros for OSGi-enabled Tuscany/SCA
> Raymond Feng wrote:
>> Hi,
>>
>> I noticed that a new module [1] has been added to produce OSGi bundles
>> for tuscany modules and 3rd party jars. I propose that we integrate with
>> this effort with the list of distros following the practice we have at
>> [2]. [2] already defines a set of features that collects related tuscany
>> modules and 3rd party dependencies.
>>
>> Basically, we can probably add a new profile on top of [2] to preprocess
>> the 3rd party jars to be OSGi bundles before the maven-assembly-plugin
>> packages them into distros. When we run the maven build with the OSGi
>> profile, the distros should be ready for OSGi.
>>
>> Thanks,
>> Raymond
>>
>> [1]
>> http://svn.apache.org/repos/asf/tuscany/java/sca/itest/osgi-tuscany/tuscany-versioned/
>> [2]
>> http://svn.apache.org/repos/asf/tuscany/java/sca/distribution/features/
>
> Raymond, I am working on doing that in [2] in the default profile. That's
> one of the things I've been experimenting with, triggering the few
> questions I was asking on the user list.
>
> --
> Jean-Sebastien
Re: Creating distros for OSGi-enabled Tuscany/SCA
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Raymond Feng wrote:
> Hi,
>
> I noticed that a new module [1] has been added to produce OSGi bundles
> for tuscany modules and 3rd party jars. I propose that we integrate with
> this effort with the list of distros following the practice we have at
> [2]. [2] already defines a set of features that collects related tuscany
> modules and 3rd party dependencies.
>
> Basically, we can probably add a new profile on top of [2] to preprocess
> the 3rd party jars to be OSGi bundles before the maven-assembly-plugin
> packages them into distros. When we run the maven build with the OSGi
> profile, the distros should be ready for OSGi.
>
> Thanks,
> Raymond
>
> [1]
> http://svn.apache.org/repos/asf/tuscany/java/sca/itest/osgi-tuscany/tuscany-versioned/
>
> [2] http://svn.apache.org/repos/asf/tuscany/java/sca/distribution/features/
Raymond, I am working on doing that in [2] in the default profile.
That's one of the things I've been experimenting with, triggering the
few questions I was asking on the user list.
--
Jean-Sebastien