Graham Charters wrote:
2008/4/30 Raymond Feng <[EMAIL PROTECTED]>:
"Enforcing" the modularity via OSGi is a good way to validate our
modularity/extensibility story in Tuscany. I think we already have a fairly
well organized module structure in Tuscany (from the maven dependency
perspective). To be consistent, should we consider directly mapping our
module structure into OSGi bundles (one bundle per existing Tuscany module)?
I wonder if that might be too fine-grained and unmanageable.
Personally, I'd prefer an approach which took into consideration how
we see folks extending or sub-setting the runtime (e.g. the things
Yang referred to - implementation types, etc.).
I'd prefer not to equate OSGi bundles 1:1 with maven modules.
For me, one of the values we get from this exercise is to explore
what higher-level combinations of individual maven modules
would form meaningful clusters of functionality from a
user/extender/embedder perspective. If the answer is none,
then we are back to the only units of modularity being the whole
of Tuscany or the individual maven modules. My intuition is that
we will be able to find some meaningful larger-grained clusters.
Simon
There may be different levels for the OSGi enablement.
1) Add OSGi entries to the META-INF/MANIFEST.MF so that Tuscany jars can be
consumed as OSGi bundles
2) Run Tuscany bundles with an OSGi runtime (using OSGi as the
modularization mechanism for the Tuscany runtime, system level)
I think we need this step to occur regularly and frequently to stop
the support decaying. I've fixed these kinds of issues twice in the
last week, which occur because new modules are added to Tuscany, but
not the OSGi support (not surprising since the OSGi support is outside
the main build).
3) Support OSGi bundles as SCA contributions (application level, how does
the OSGi import/export relate to the sca-contributions.xml?).
The other interesting issue is how we deal with the 3rd party jars, most of
which are not OSGi bundles. To support the case that different Tuscany
extensions may require different versions of the same 3rd party jar, we need
to figure out a good way to "turn" 3rd party jars into OSGi bundles.
This is a knotty problem. It's not a new problem and is discussed
here: https://mail.osgi.org/pipermail/jsr-291-eg/2006-March/000023.html
Licensing and signing can prevent us from adding information to the
jars, which leaves us with three options, I think:
1. Create wrapper bundles which contain the jars, which raises
concerns about disk space.
2. Use a non-OSGi mechanism to refer to jars outside a bundle
(Equinox allows this).
3. Devise a new mechanism to create 'virtual bundles' on the fly (see
https://www.osgi.org/members/bugzilla/show_bug.cgi?id=277).
3 might be the best solution longer term, but is the most work.
Thanks,
Raymond
--------------------------------------------------
From: "Yang Lei" <[EMAIL PROTECTED]>
Sent: Tuesday, April 29, 2008 9:09 PM
To: <tuscany-dev@ws.apache.org>
Subject: Re: Improving support for running in OSGi
I think enabling OSGI can help modularity with a clear definition of
package visibility, so we can have a much cleaner "module"
dependencies through osgi bundle import/export on package. I think
it will help Tuscany adopters a lot in the scenarios such as: when
implementing new implementation type, binding type, or data binding
types, there is clear indication which set of packages can be used
(exported API/SPI ). So upgrading to new Tuscany level can be as
simple as plug and play if there is no API/SPI changes, and version
control (multiple version co-existence) can also be made available
through OSGI capabilities.
Regards,
Yang
On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT)
<[EMAIL PROTECTED]> wrote:
Hi,
I'd like to get people's thoughts on whether the idea of 'promoting'
OSGi is a good one,
IMHO support of OSGi is very important and I glad to see increasing
interest of the community here.
and get ideas on how best to proceed.
I personally have currently not a very deep insight into implementation
details yet, but we are currently prototyping and have there also OSGi
services.
What I could offer today is only to feed our findings about limitations
and rooms for improvement back.
Another important thing which I see on the horizon, is the ongoing
standardization of Distributed OSGi (RFC119) and the benefit to support that
standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to
keep an eye on that as well.
Regards,
Philipp
-----Ursprüngliche Nachricht-----
Von: Graham Charters [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 28. April 2008 09:48
An: tuscany-dev@ws.apache.org
Betreff: Improving support for running in OSGi
Hi All,
I'd like to get more involved in the OSGi support in Tuscany (both the
modularity work (itest/osgi-tuscany) and the implementation.osgi). I
recently started looking at the work to run Tuscany in OSGi, embodied
in itest/osgi-tuscany and described in the thread entitled
"Classloading in Tuscany". I've noticed a couple of others on the
list also interested in Tuscany running in OSGi and wondered if it
might be worth considering making this a "first-class" option. At the
moment the five bundles are only built by folks who want the OSGi
support and go into the itest/osgi-tuscany directory to create it.
This can result in any problems being discovered late, but also could
create the impression that OSGi is considered a second-class
environment (which I don't believe is the case).
Aside from the obvious benefits to OSGi users in doing this, I think
there's a potential for Tuscany to use the OSGi build as a test-bed
for highlighting and working through modularity issues, which would
also benefit Tuscany in general, not just in an OSGi runtime.
I'd like to get people's thoughts on whether the idea of 'promoting'
OSGi is a good one, and get ideas on how best to proceed. We could
then start discussing what some of the issues might be (e.g. size of
builds, time to build, etc...).
Regards,
Graham.
