Simon Laws wrote:
On Thu, May 1, 2008 at 1:00 PM, Graham Charters <[EMAIL PROTECTED]>
wrote:
It would seem that the fine-grained/coarse-grained thoughts have
people divided. Rajini's note (aside from the fact she has a tonne of
experience having done most, if not all, of the OSGi work in Tuscany)
paints a picture where the two are not mutually exclusive. I don't
typically like doing two options because that seems like indecision,
but in this case they do appear to complement each other.
Based on what I've seen in this thread, I'm hoping this briefly
summarizes the collection of thoughts on how we might proceed:
Tuscany Running in OSGi
1. Add bundle manifests to all the Tuscany modules (using maven
bundle plugin). This will ensure the most fine-grained decomposition
works and therefore coarser-grained distributions will also work.
2. Add a distribution which creates bundles around manageable
collections of Tuscany modules aligned with how we see the runtime
being extended/subsetted/replaced. Have this build and test on
Continuum.
3. Create 'virtual bundles' for third-party libraries to avoid
licensing and disk space issues (based on Rajini's suggestions, which
I need to better understand).
4. Provide guidance on the wiki on how to avoid breaking OSGi.
There's also the suggestion that implementation.osgi relate to
Distributed OSGi (RFC 119), which shouldn't be lost.
Have I missed anything?
It sounds like a staging of 1 & 3 first, followed by 2 would work (and
4 if things keep breaking :-( ). I'd be concerned if we didn't get to
2, and as part of 1&3, we need to make sure these are regularly tested
under osgi.
2008/5/1 Mike Edwards <[EMAIL PROTECTED]>:
Simon Laws wrote:
On Thu, May 1, 2008 at 10:03 AM, Rajini Sivaram <
[EMAIL PROTECTED]> wrote:
On 5/1/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
My 2c:
+1 to promote OSGi to a first class Tuscany runtime environment
+1 for an OSGi continuum build (thinking about a build profile
that'll
run
the Tuscany itest suite in an OSGi environment, similar to the
profiles
we
have for Web containers for example)
Here's what I imagined we'd do:
1. add OSGi entries to each of our JAR manifests
2. have developers maintain them and pay attention to
imports/exports
3. use the OSGi build to detect API and SPI import/export
violations
4. find the best way to OSGi-enable 3rd party dependency JARs
I realize that my suggestion [1] is not very popular and most
people
on
this list would prefer to come up with bigger bundles grouping
several
of
our JARs/modules. I don't think that the 'bigger aggregate bundle'
approach
will work, but I'll be happy to watch people try it :) if they
want
to.
With respect to [4] I find rather funny to see many projects out
there
claim OSGi enablement without having OSGified their 3rd party
dependencies.
I wonder how that works, can an OSGi-enabled project really
leverage
the
OSGi classloader isolation and versioning capabilities when 99% of
the
JARs
it requires are not OSGi bundles? I must be missing something...
and I
hope
we can do better in Tuscany with a real end-to-end OSGi enablement
story
:)
--
Jean-Sebastien
I agree with Sebastien's suggestions1-4. But I would like to suggest
a
slight variation to the first suggestion.
1. Use maven-bundle-plugin to introduce OSGi manifest entries into
all
the Tuscany modules, with auto-generated import/export statements.
Modify
itest/osgi-tuscany to run these modules under OSGi, with all 3rd
party
jars
installed into OSGi using virtual bundles created on the fly.
This step will provide a version of osgi-tuscany tests that is less
prone
to
breakage than the one we have today. It will also help fix any
remaining
classloading issues that we have left in Tuscany (and hopefully help
in maintaining the classloader isolation). This is not a big piece
of
work
since this is just bringing together the different pieces that we
already
have. I will be happy to contribute the code towards this first
step, so
others can concentrate on what we really want to achieve in terms of
modularity, distribution etc. We can also use this step to explore
versioning - in particular about having multiple extensions
referring to
different versions of 3rd party libraries. This will be very useful
for
4.
Suggestions 2-3 are not requirements for OSGi, but these are clearly
cases
where OSGi technology can help Tuscany improve modularity. If we
want to
have explicitly hard-coded import/export statements in the modules
to
enforce modularity, that can be introduced in step 2.
And I would expect that there will be more work in terms of building
the
distributions suitable for OSGi as well as non-OSGi after 1-4.
Thank you...
Regards,
Rajini
Re. modularity, it strikes me that there is lack of consensus about
whether
big bundles or small bundles, relative to our maven modules, are
preferable
but that there is consensus about using OSGi bundles to help us test
and
refine out modularity story.
So maybe we should agree to disregard the question about how big OSGi
bundles should be relative to our maven modules and concentrate on the
question about whether our maven modules are correctly factored. Using
OSGi
as a tool to help us with this of course.
Simon
I support both Rajini's and Simon's points. We can get the mechanics
going
first with the bundles following the existing grain of the modules - and
we
can discuss and tinker with the modules as we please later to find the
best
arrangements.
I suspect that the differing opinions about module size reflect
different
usecases. Lots of small modules can promote great flexibility in the
construction of runtimes, but at the expense of making it much harder
for
users to make sense of the options. Larger modules cut down the options
but
make things easier for end users.
Yours, Mike.
I would further propose that we take a subset of the output of 1 and 3, for
example, enough to run the calculator sample, as an initial test case
separate from the full range of itest/osgi-tuscany tests. This would give us
something to shoot re. inclusion in the regular build.
Simon
+1 Very good idea
--
Jean-Sebastien
