On Thu, Feb 28, 2008 at 9:30 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> Rajini Sivaram wrote: > > 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.nodeand > > 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 :-). > > > > I have reviewed the model resolution and classloading code and found the > following: > > - Split namespaces are currently supported (for example by the WSDL and > XSD resolvers). The model resolver mechanism does not have an issue with > split namespaces. > > - The Java import/export resolvers do not seem to support split packages > (if I understood that code which was quite tricky), but that's an issue > in that Java import/export specific code, which just needs to be fixed. > I'll work on it. > > - The interactions between the Java import/export listener, the model > resolvers and the ContributionClassLoader are way too complicated IMHO. > That complexity is mostly caused by ContributionClassLoader, I'll try to > show a simpler implementation in a few days. > > - Dependency cycles are an exception in Java as build tools like Maven > don't support them, but can exist in XSD for example. Supporting cycles > just requires a simple fix to the import model resolvers, I'll help fix > that too. > > Hope this helps. > -- > Jean-Sebastien > > It doesn't feel like there is agreement on the approach yet so would you hold off committing changes to see if we can get better consensus? Reading through the thread I'm not sure that I properly understand exactly what it is thats broken with the code as it is, would you be able to create a testcase that shows what it is that is broken to help us better understand? ...ant
