On 2/22/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > >> Jean-Sebastien Delfino wrote: > >> Great to see a *test* case for cycles, but my question was: Do you > >> have a *use* case for cycles and partial packages right now or can > it >> be fixed later? > > > Rajini Sivaram wrote: > > No, I dont have an use-case, at least not an SCA one. But there are > plenty > > of them in OSGi - eg. Tuscany modules cannot run in OSGi without support > for > > split-packages. Of course you can fix it later. > > I'm not arguing for or against fixing it now or later, I'm trying to get > the real use case to make a decision based on concrete grounds. Can you > point me to your OSGi use cases, or help me understand "Tuscany modules > cannot run in OSGi without support for split packages"?
Tuscany node and domain code are split into three modules each for API, SPI and Implementation eg. tuscany-node-api, tuscany-node and tuscany-node-impl. The API module defines a set of classes in org.apache.tuscany.sca.node and the SPI module extends this package with more classes. So the package org.apache.tuscany.sca.node is split across tuscany-node-api and tuscany-node. If we used maven-bundle-plugin to generate OSGi manifest entries for Tuscany modules, we would get three OSGi bundles corresponding to the node modules. And the API and SPI bundles have to specify that they use split-packages. It would obviously have been better if API and SPI used different packages, but the point I am trying to make is that splitting packages across modules is not as crazy as it sounds, and split packages do appear in code written by experienced programmers. IMO, supporting overlapping package import/exports is more important with SCA contributions than with OSGi bundles since SCA contributions can specify wildcards in import.java/export.java. eg. If you look at packaging tuscany-contribution and tuscany-contribution-impl where tuscany-contribution-impl depends on tuscany-contribution, there is no clear naming convention to separate the two modules using a single import/export statement pair. So if I could use wildcards, the simplest option that would avoid separate import/export statements for each subpackage (as required in OSGi) would be to export org.apache.tuscany.sca.contribution* from tuscany-contribution and import org.apache.tuscany.sca.contribution* in tuscany-contribution-impl. The sub-packages themselves are not shared but the import/export namespaces are. We need to avoid cycles in these cases. Again, there is a way to avoid sharing package spaces, but it is simpler to share, and there is nothing in the SCA spec which stops you sharing packages across contributions. I dont think the current model resolver code which recursively searches exporting contributions for artifacts is correct anyway - even for artifacts other than classes. IMO, when an exporting contribution is searched for an artifact, it should only search the exporting contribution itself, not its imports. And that would avoid cycles in classloading. I would still prefer not to intertwine classloading and model resolution because that would unnecessarily make classloading stack traces which are complex anyway, even more complex that it needs to be. But at least if it works all the time, rather than run into stack overflows, I might not have to look at those stack traces.... and this will convince me to help fix it now :) Thanks. It is not broken now - you have to break it first and then fix it :-). > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thank you... Regards, Rajini
