This is exactly the way it works. The new (Hivemind related) logic/sources/descriptors etc. will be jared in a separate archive and the already implemented logic you called it gdata-core stays in it's own jar file. The core impl. on its own is not "runnable" it needs to be wired together by a container. This could be Hivemind, Spring or Pico. I can not 100% guarantee that every single construct can be mapped with every container but this can be fixed in the core if the problem occurs ( I do have a single construct in mind which could turn out in a problem...). I do have to do some modifications in the core especially within creational patterns. These pattern might be obsolete with a container / micro kernel like hivemind. I will keep the aspect of "no special hivemind magic" in mind! Good point thank you!
best regards Simon On 11/9/06, peter royal <[EMAIL PROTECTED]> wrote:
On Nov 9, 2006, at 12:29 AM, Simon Willnauer wrote: > So except of the meta data work people would have to do it is just a > replacement e.g reimplementation of a single method. > > Instead of Registry.getService() it would be > ApplicationContext.getBean() > > is it that what you are alluding to? kinda, but at a level one below that.. You have all of these services/beans that live in the container. I'd make them one logical module in the project. They have zero dependencies on any specific container. Call it gdata-core Then, you have another module, gdata-hivemind. This takes the components from gdata-core, and wires them up in a usable fashion with hivemind, puts them into the servlets, does the soap/etc exporting. Now, say someone comes along and wants to integrate the gdata work into their spring container.. they have two choices. They can just take the core components from gdata-core, and drop them into their existing spring container. Or, perhaps someone wants to make a gdata- spring module, since they want to use some whizzy feature spring may have over hivemind. It may make sense to share some details of the wiring/etc with gdata-hivemind, or it may not. But they still share the same underlying components via gdata-core. Or, to try to put it succinctly worded in another way... I'm advocating a separation of concerns: 1) The "work" components that do all of the heavily lifting. (gdata-core) 2) The assembly of said components into a functional application. (gdata-hivemind) Given #1, you can make multiple versions of #2, using various assembly styles. -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
