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 thought it would be very unfair of me to suggest that this is not a very big task, when you were the one who had to go and implement it. But now that you agree that it is not too much work, can I change my mind? Seriously though, I could help with getting something up and running quickly, and you could take over from there (I will continue to help if you run into problems). Let me take a look this weekend and see if I can get a quick build with OSGi manifest entries for the modules. There are some modules which require additional options like Require-Bundle for the split packages. Since I have done this once before (even though that was with different plugins) for running Tuscany using OBR, it may be quicker for me to add these (and you can refine them later). I will also try to update osgi-tuscany to use these with some basic support for virtual 3rd party bundles copied over from the existing code and see if they run into any problems. You could then take over and drive it forward, initially fine tuning the OSGi support (finalizing the design for 3rd party libs as well as reducing disk space for tests, getting them to run on Continuum etc) followed by improving modularity. I suspect modularity requires a lot more discussion since it affects everyone. You might want to start a new thread on the mailing list without including "OSGi" in the subject :-). 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. My problem with option 3. is purely psychological. It seems rather strange to have centralized control of modularity :-). And paranoia - who is going to maintain a continually breaking itest/osgi-tuscany? Probably you, still... I do completely agree that 3. will help us get there faster. But it could reduce the motivation for 4, and throw away the opportunity to involve the entire Tuscany community to drive the improvements in modularity. There was a purpose to writing itest/osgi-tuscany - and that was to ensure that Tuscany could run inside an OSGi runtime. It already has the responsibility to test classloader usage in Tuscany, other issues like URL handling, which used to break under OSGi, and OSGi-specific problems in Tuscany. It might collapse under pressure if also burdened with defining and maintaining Tuscany modularity. But honestly, I think you should choose whichever path makes it easiest for you to drive the modularity work. 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
