lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer" <>
Subject Re: ThirdParty Jars in GData
Date Thu, 09 Nov 2006 16:51:36 GMT
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 <> 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
> --
> -

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message