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 >
