Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (herse.apache.org: domain of simon.willnauer@googlemail.com
 designates 66.249.92.174 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=DOq6pxb5m4VxS1Q2uSyZS4VRz3VV5eUKAMXYCptEo4BhUuYGxj1qEsJFjG1XoAIdeG2GZRv6zzqjJv18CXE4pHc57F6+LYNL8qMkCXDTBNhMKL6AlrLQ65p0LcXcf/d6jWYbcVdjTxiKVkQqKj6DK5Fpo47rGRGihvo11r4/zGo=
Message-ID: <f18c9dde0611090851j6e2addb3t8d32436e733b471@mail.gmail.com>
Date: Thu, 9 Nov 2006 17:51:36 +0100
From: "Simon Willnauer" <simon.willnauer@googlemail.com>
Reply-To: simon.willnauer@gmail.com
To: java-dev@lucene.apache.org
Subject: Re: ThirdParty Jars in GData
In-Reply-To: <AB88D292-C9C2-49BC-83A1-0D6C738A601A@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20061108190520.18823.qmail@web50311.mail.yahoo.com>
	 <f18c9dde0611081143m64a640deve740e4fa9a4abded@mail.gmail.com>
	 <5CD1A536-8269-483F-B39A-96DEA8AC1374@apache.org>
	 <f18c9dde0611090029r1acbec28w5b26f78dbb198e2d@mail.gmail.com>
	 <AB88D292-C9C2-49BC-83A1-0D6C738A601A@apache.org>

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 <proyal@apache.org> 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
>
>
>
>
> --
> proyal@apache.org - http://fotap.org/~osi
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org