Mailing-List: contact tuscany-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tuscany-dev@ws.apache.org
Received-SPF: pass (athena.apache.org: domain of rajinisivaram@googlemail.com
 designates 209.85.198.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=t9yBpBFY5zsxNb874qpYv7dB1XyFf58GU01QAV9+Zoa+EGYU18EioT6t6uQShE/+5/Pc7QvPhaCpcTIGFwjGt7+UgWn4831z3Nqiw0fSNzBxJpjR4ZLqK8eVDIY/mWe1v3XEcWwvF2Mpjg+0Q3jzCcgAWAKVT3yuCi7hkj7MUP4=
Message-ID: <a440eccf0805010203y4224b7a3t6fe8b179e7db6@mail.gmail.com>
Date: Thu, 1 May 2008 10:03:25 +0100
From: "Rajini Sivaram" <rajinisivaram@googlemail.com>
To: tuscany-dev@ws.apache.org
Subject: Re: Improving support for running in OSGi
In-Reply-To: <4819035B.8070704@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_4657_23739255.1209632605103"
References: <345578340804280048m59d06defn85ea21634c1b473a@mail.gmail.com>
	 <F84FCC845482B341870BB03D88B461A95DD5D8@MCHP7I7A.ww902.siemens.net>
	 <3df38e420804292109g242b1637wbddee903d681059f@mail.gmail.com>
	 <F06B3C37C66C4F5BADEBC0D7FBC6E5D8@rfengt60p>
	 <345578340804300943k30334bf9s6cd0aeaac589c62d@mail.gmail.com>
	 <D10B5F58ABB8467DAD4E3E7967A425E1@rfengt60p>
	 <345578340804301259v63fe9b3vda9f6cf862c83078@mail.gmail.com>
	 <4819035B.8070704@apache.org>

------=_Part_4657_23739255.1209632605103
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/1/08, Jean-Sebastien Delfino <jsdelfino@apache.org> 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

------=_Part_4657_23739255.1209632605103--