I have a new working itest/osgi-tuscany with the following: 1. modules/ are built with OSGi manifest headers using maven-bundle-plugin 2. For 3rd party jars, a manifest jar is created, similar to tuscany-sca-manifest.jar from the distribution. It contains the standard manifest file (with Jar classpath), a separate OSGi manifest file with import/exports for 3rd party libs created using maven-bundle-plugin, and a bundle activator. The bundle activator creates a virtual bundle for the third party jars using the Jar classpath and installs it into OSGi. 3. itest/osgi-tuscany loads Tuscany modules from the modules build. (it no longer creates the 5 combined bundles). The manifest jar is generated by itest/osgi-tuscany, which also copies all 3rd party libs (so it looks identical to a regular Tuscany distribution). It is not particularly efficient, but it does the job.
By adding a bundle activator to tuscany-sca-manifest.jar which can install Tuscany into OSGi, when the manifest bundle is installed into OSGi, we can have a Tuscany distribution which installs itself into OSGi straight out-of-the-box, without doubling the size of the distribution. Users who don't like to have virtual 3rd party bundles can generate a concrete OSGi bundle for the third party jars with a simple jar command using the 3rd party manifest file stored in tuscany-sca-manifest.jar. If Tuscany distribution is split into multiple smaller distributions, I assume we will continue to have a manifest.jar for each part, and the same bundle activator can be inserted into each manifest.jar to cause that part of the distribution to be self-installing for OSGi. At the moment, I am creating a single virtual 3rd party bundle. For the longer term, if there are use-cases where different Tuscany extensions require different versions of 3rd party libs, we may want to split this into multiple virtual bundles. There are a couple of issues that I raised JIRAs for, and once I get responses to those, I can check the code into SVN if there are are no objections. With these changes, you should have enough to look at modularity in Tuscany and decide how to move that forward. On 5/2/08, Graham Charters <[EMAIL PROTECTED]> wrote: > Hi Rajini, > > FWIW, I agree with starting with 1. I missed your earlier note saying > you'd be happy to contribute code to do this. Please let me know what > I can do to help. I'm particularly interested in the 'virtual bundle' > idea. I took a look at the way the samples are run in > itest/osgi-tuscany and now I have a better understanding, I agree, > it's not as much work as I first thought (fear of the unknown ;-) ). > I think the challenge will be in finding the right design to enable it > for third-party libraries so it's usable and flexible enough. Perhaps > you already have thoughts on this? > > I was a little surprised you didn't suggest 3 as a stepping stone > towards 4 (I guess the '"half-hearted" comment was a bit of a > give-away ;-) ). I agree it's not ideal from a modularity perspective > but it does have the advantage that I think it could be introduced a > lot sooner than 4 and would therefore accelerate sensitizing folks to > the issues. > > Regards, Graham. > > 2008/5/2 Rajini Sivaram <[EMAIL PROTECTED]>: > > On 5/1/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > > > > > Graham Charters 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. > > > > > > > > > > > Sounds good to me, with the following comments: > > > > > > When you have (1) + (3) you can already run a continuum OSGi build, > before > > > attacking (2). I'd actually suggest to start building on continuum as > soon > > > as we have (1). > > > > > > - I'm not clear on what you meant by 'use the Maven bundle plugin'. > Will > > > we write something like this for example: > > > <project> > > > ... > > > <packaging>bundle</packaging> > > > ... > > > <plugin> > > > <groupId>org.apache.felix</groupId> > > > <artifactId>maven-bundle-plugin</artifactId> > > > <extensions>true</extensions> > > > <configuration> > > > <instructions> > > > <Export-Package>org.apache.tuscany.sca.foo</Export-Package> > > > <Import-Package>org.apache.tuscany.sca.bar</Import-Package> > > > > <Private-Package>org.apache.tuscany.sca.impl.*</Private-Package> > > > </instructions> > > > </configuration> > > > </plugin> > > > ... > > > > > > > > I think we have four options on how we start bundle-izing Tuscany > modules, > > using maven-bundle-plugin. > > > > > > 1. Use the manifest goal to generate the manifest entry in all module > jars, > > with <Export-Package>*</Export-Package> and > > <Import-Package>*</Import-Package>, which export all the packages from > the > > module and import everything used by the module. The Export-Package and > > Import-Package statements in the generated manifest will use explicit > > package import/exports like: > > > > Import-Package: > > > > > javax.xml.namespace,javax.xml.parsers,org.apache.tuscany.sca.contribution.resolver,... > > Export-Package: > > > > > org.apache.tuscany.sca.implementation.osgi;version="2.0";uses:="o.a.t.s.assembly",/... > > > > > > The analysis of Import/Export will be done by the maven-bundle-plugin > in > > this case. The actual generation of the module jar will remain the same > as > > now, the only addition will be a new generated manifest file. > > > > We might not use <Export-Package>*</Export-Package> , but instead it > would > > be something more like > > > > > <Export-Package>org.apache.tuscany.sca.implementation.osgi.*</Export-Package>, > > where the packages are wildcarded, but no assumptions about modularity > are > > made. > > > > 2. Use bundle goal with Import/Export as above (generated by > > maven-bundle-plugin rather than explicitly specified). In this case the > jar > > itself will be generated using maven-bundle-plugin. The output jar > should be > > identical to 1. > > > > 3. Use manifest goal with explicitly listed <Export-Package/>, > > <Import-Package/> as in Sebastien's example. All exported and (maybe) > > imported packages are explicitly specified in the pom. Everytime a > > new package is added, the pom should be updated. > > > > 4. Use bundle goal with explicitly listed <Export-Package/>, > > <Import-Package/> and <Private-Package/> as in Sebastien's example. > This > > option corresponds to Sebastien's example. In this case both the > contents of > > the jar, as well as the manifest are based on the explicitly listed > > packages. > > > > > > 1. is the easiest to implement. It makes no assumptions about > modularity, > > and will not have any impact on non-OSGi applications since only the > > manifest entry is affected. From an OSGi point of view, this gives all > we > > need for osgi-tuscany. > > > > 2. does not add any value over 1. > > > > 3. This is a half-hearted attempt to enforce modularity. osgi-tuscany > will > > break everytime someone introduces a new package and doesn't update > the > > pom. But Tuscany will continue to operate without OSGi since only the > > manifest is broken. 3. is not a requirement for OSGi-based Tuscany, but > > merely the use of OSGi technology to improve modularity. osgi-tuscany > will > > take on the role on policing modularity(apart from testing that Tuscany > can > > be run in an OSGi runtime). > > > > 4. This is OSGi best practice. If a new package is introduced and the > pom is > > not updated, the jar itself will be unusable. Basically this requires > all > > developers to be OSGi-aware. The value-add of this option over 1. is > the > > enforcement of modularity, and like 3, this is not a requirement for > > OSGi-based Tuscany. I am not sure we are ready for this yet. I think > there > > is a real risk that frequent breakages will create the perception that > OSGi > > integration is impossible to maintain, even though this is more to do > with > > enforcing modularity rather than OSGi. > > > > > > I would like to suggest that we start with 1., use the generated > manifest > > files to understand and improve modularity and jump to 4. to enforce > > modularity when we are ready for it. > > > > > > > > > > > > > > > or did you mean something else? > > > > > > -- > > > Jean-Sebastien > > > > > > > > > > > -- > > Thank you... > > > > Regards, > > > > Rajini > > > -- Thank you... Regards, Rajini
