Hi Rajini just back in from vacation and catching up. I've put some comments in line but the text seems to be circling around a few hot issues:
- How closely class loading should be related to model resolution, i.e. options 1 and 2 from previously in this thread - Support for split namsepaces/shared packages - Recursive searching of contributions - Handling non-existent resources, e.g by spotting cycles in imports/exports. These are of course related but it may be easier if we address them independently. Simon > > > 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. The split packages across the various node/domain module was not by design. The code moved around and that was the result. We could go ahead and fix this. Are there any other explicit examples of split packages that you happen to know about > 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'm not sure if you are suggesting that we implement a wildcard mechanism or that we impose some restrictions, for example, to mandate that import.javashould use fully qualified package names (as it says in line 2929 of the assembly spec). Are wildcards already supported? The assembly spec seems to recognize that artifacts from the same namespace may appear in several places (line 2946) but it is suggesting that these multiple namespace references are included explicitly as distinct import declarations. > > 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.... > Looking at the assembly spec there is not much discussion of recursive inclusion. I did find line 3022 which describes the behaviour w.r.t"indirect dependent contributions" which to me implies that contributions providing exports should be recursively searched > > > 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 >
