On 10/18/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > > Folks, > > Comments inline > > Simon Laws wrote: > > Hi Rajini > > > > Re. 4 on Simon's list. Maybe it is useful to more clearly distinguish > > between those Tuscany modules that are expect to be loaded statically, > > assembly, core, etc and those that expected to be loaded dynamically, > > binding.?, implementation.? etc. I find the term "module" a little > > unsatisfactory. Raymond, in his diagram, used Tuscany core and Tuscany > > extension and in a previous post used Tuscany runtime and Tuscany > > extension. I prefer the latter pair just because we have a maven module > > called core. > > +1 > > > > > This leads to a 4a and 4b based on Raymond's post/diagram > > > > 4a Tuscany extension module code shouldn't be able to see other > extension > > modules (not sure what the dotted line on the diagram implies but I > expect > > that it's to do with modules like binding-ws-axis2 and binding-ws > > interacting) or application code or Tuscany runtime code other than via > the > > SPI. > > Hmm, first, this ain't the case today and it will need some thought. > > The "Java" extensions do share code and it would be crazy for them not > to share the code. So, Spring uses stuff out of the base Java extension > - and I am sure that other "Java" type extensions would want to do the > same. > > In an OSGi world, it would be fine to express the dependency in a simple > way. For non-OSGi I'm not sure of the best route. > > I suspect that other extension types may want to share stuff as well.
Agreed. Hence I pointed out the relationship between binding-ws-axis2 and binding-ws. There are loose groups of software spread across multiple maven modules that just represent modularization of the software for clarity and reuse purposes. Then there are the modules that are intended to be loaded as extensions. Not all maven modules are create equal :-) The non OSGi world is managed by the dependencies that appear in out maven pom files. Without this dependency tree you just have to know that, for example, binding-ws has to be on the classpath when you also include binding-ws-xml which is in turn a dependency of binding-ws-axis2. Nothing too unusual there until you start talking about having separate class loaders for each extension as has been discussed previously in this thread. You really need to understand what an extension is, i.e. it is unlikely to be a single maven module. > 4b Tuscany runtime code shouldn't be able to see Tuscany extension code or > > application code. > > That sounds a bit odd. Perhaps I've not got the right end of the stick, > but the some code - either core and or extensions has to get very > intimate with the application code. Introspection, instantiation, > injection - all has to be done either by core code or extension code. > > Perhaps I've not understood the separation you're looking for? This should say "shouldn't be able to statically see..". I had imagined that these are all of the implementation modules that sit behind the SPI > > > Then, from reading your comments, we have to be clearer about what the > SPI > > is providing an interface to because it current includes interfaces to > the > > underlying runtime modules but also the host-embedded classes which > strike > > me as being more API than SPI. We are reorganizing the domain/node > > interfaces at the moment so hopefully we can clear this last point up as > > part of that. > > > > Regards > > > > Simon > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
