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
