ThirdParty Jars in GData

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

ThirdParty Jars in GData

Simon Willnauer
Hi all,
I just started to work on the todo list @ GData Server to add Admin
Interface and some major refactoring. GData server will be based on
the Apache Hivemind Microkernel and will make extensive use of these
libs including hive-utils and the hessian webservice integration
(caucho.com). Even apache hivemind includes a couple of third - party
jars like javaassist.jar which is also distributed in the release. So
I'm a bit curious about the fact that non ASF - licenced jars are
included in asf products.
In the end there will be a couple of jars I need for the GData server
at least at runtime. ASF Jars like hivemind core and libs won't be a
problem inside the svn repos. But whats the best way to get the other
jars. I had a look at the hivemind build file, they defined a macro to
fetch the jars from http://www.ibiblio.org/. This seems to be a nice
solution to fetch these jars via a simple ant get task.


Any other ideas / suggestions?

regards simon

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ThirdParty Jars in GData

Grant Ingersoll-2
OK, disclaimer first: I'm not a lawyer and I am not 100% sure on all  
of this, but here are some things I found while digging into this:

I did some digging and there is a _DRAFT_ policy at http://
people.apache.org/~cliffs/3party.html

See also:
http://www.apache.org/legal/
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ 
(particularly March of 2006, where the draft policy was first discussed.

I don't know if any of this answers your question or not.  Your best  
bet, most likely, is to start with the ANT download approach.  You  
might also want to indicate what the licenses are of the other  
libraries, so that others with more knowledge could give you more info.

Also, check how contrib/db/bdb does it, which uses Berkeley DB, which  
is under the Sleepycat license, which is one of the licenses  
_excluded_ by the draft above.  I am not saying this means it is  
correctly done, just that there is some precedent for it.

-Grant

On Nov 8, 2006, at 6:36 AM, Simon Willnauer wrote:

> Hi all,
> I just started to work on the todo list @ GData Server to add Admin
> Interface and some major refactoring. GData server will be based on
> the Apache Hivemind Microkernel and will make extensive use of these
> libs including hive-utils and the hessian webservice integration
> (caucho.com). Even apache hivemind includes a couple of third - party
> jars like javaassist.jar which is also distributed in the release. So
> I'm a bit curious about the fact that non ASF - licenced jars are
> included in asf products.
> In the end there will be a couple of jars I need for the GData server
> at least at runtime. ASF Jars like hivemind core and libs won't be a
> problem inside the svn repos. But whats the best way to get the other
> jars. I had a look at the hivemind build file, they defined a macro to
> fetch the jars from http://www.ibiblio.org/. This seems to be a nice
> solution to fetch these jars via a simple ant get task.
>
>
> Any other ideas / suggestions?
>
> regards simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--------------------------
Grant Ingersoll
Sr. Software Engineer
Center for Natural Language Processing
Syracuse University
335 Hinds Hall
Syracuse, NY 13244
http://www.cnlp.org




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ThirdParty Jars in GData

Otis Gospodnetic-2
In reply to this post by Simon Willnauer
Simon,

Before starting work on all this, could you please share some of your plans with us?  For example, I'm curious why Hivemind is needed.

Thanks,
Otis

----- Original Message ----
From: Simon Willnauer <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 8, 2006 6:36:31 AM
Subject: ThirdParty Jars in GData

Hi all,
I just started to work on the todo list @ GData Server to add Admin
Interface and some major refactoring. GData server will be based on
the Apache Hivemind Microkernel and will make extensive use of these
libs including hive-utils and the hessian webservice integration
(caucho.com). Even apache hivemind includes a couple of third - party
jars like javaassist.jar which is also distributed in the release. So
I'm a bit curious about the fact that non ASF - licenced jars are
included in asf products.
In the end there will be a couple of jars I need for the GData server
at least at runtime. ASF Jars like hivemind core and libs won't be a
problem inside the svn repos. But whats the best way to get the other
jars. I had a look at the hivemind build file, they defined a macro to
fetch the jars from http://www.ibiblio.org/. This seems to be a nice
solution to fetch these jars via a simple ant get task.


Any other ideas / suggestions?

regards simon

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ThirdParty Jars in GData

Simon Willnauer
Sure I can and I will :)

The main reason why this refactoring takes place is that currently
there are heaps of "hard" dependencies created by the "service" model
gdata-server uses. Services are accessed by calling a registry similar
to JNDI without a a container. The services are configurable like a
lot classes inside the server. It gives me, and it would do to other
developers as well, a hard time to implement test cases because the
registry is needed and wired to tight into the server.
That's why I evaluated some IoC DI container like spring, hivemind,
pico and Felix (Apache OSGi). Hivemind felt good to me due to some
reasons (some more on this later @siren I will send a separate email
on this topic).
So on the todo list are some other things like webservice integration
for admin actions and exposing Services and monitoring data to JMX .
Hivemind offers a very nice JMX integration which is plugable and with
hive-utils comes a ready to use damned fast hessian webservice impl.
which I used for another project. No wsdl / wsdd overhead, no
descriptors just an Infterface and your ws is ready to go. Client
API's for almost every lanugages (python ruby php java c#...) which
enables users to integrate admin func. in their application which
could be a pain with axis as I experienced.
Further on is a lot of configuration needed for some services which is
currently handled by commons digester which is alright but hard to
test and hivemind offers easy way to define default configurations and
let users override these in top level descriptors.
Another reason is that my professor granted me exemption from
university courses to work on GData which gives me the possibility to
do such a comprehensive refactoring.

After all this will improve test / software quality reuseablity and
gives me a lot of tools to offer nice administration access without
reinventing the wheel.

best regards
Simon

On 11/8/06, Otis Gospodnetic <[hidden email]> wrote:

> Simon,
>
> Before starting work on all this, could you please share some of your plans with us?  For example, I'm curious why Hivemind is needed.
>
> Thanks,
> Otis
>
> ----- Original Message ----
> From: Simon Willnauer <[hidden email]>
> To: [hidden email]
> Sent: Wednesday, November 8, 2006 6:36:31 AM
> Subject: ThirdParty Jars in GData
>
> Hi all,
> I just started to work on the todo list @ GData Server to add Admin
> Interface and some major refactoring. GData server will be based on
> the Apache Hivemind Microkernel and will make extensive use of these
> libs including hive-utils and the hessian webservice integration
> (caucho.com). Even apache hivemind includes a couple of third - party
> jars like javaassist.jar which is also distributed in the release. So
> I'm a bit curious about the fact that non ASF - licenced jars are
> included in asf products.
> In the end there will be a couple of jars I need for the GData server
> at least at runtime. ASF Jars like hivemind core and libs won't be a
> problem inside the svn repos. But whats the best way to get the other
> jars. I had a look at the hivemind build file, they defined a macro to
> fetch the jars from http://www.ibiblio.org/. This seems to be a nice
> solution to fetch these jars via a simple ant get task.
>
>
> Any other ideas / suggestions?
>
> regards simon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ThirdParty Jars in GData

peter royal
On Nov 8, 2006, at 11:43 AM, Simon Willnauer wrote:
> That's why I evaluated some IoC DI container like spring, hivemind,
> pico and Felix (Apache OSGi). Hivemind felt good to me due to some
> reasons (some more on this later @siren I will send a separate email
> on this topic).

would it be possible to fashion the GData server such that it is a  
set of POJO's (one logical module), and then there is another logical  
module that wires them up in a usable fashion using Hivemind (another  
logical module). That way if someone wanted to use pico/spring/
whatever, they could, since the core components are container-
independent.

since HiveMind services are POJO's, this should be possible, as long  
as no hivemind magic is required for the system to function.

-pete


--
[hidden email] - http://fotap.org/~osi




smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ThirdParty Jars in GData

Simon Willnauer
First it is / would be possible to just replace all the wireing
descriptors to spring configurations as the most ( all?!) of the IoC
DI containers use external descriptors. There is a central point ( the
servlet) where a single direct reference to hivemind will be hard
coded just to access the first reference to the hivemind managed
modules. Every servlet in the container is a subtype of an Basic
abstract servlet class which has a abstract method to obtain the first
reference. If you wanna switch to another IoC container the
replacement of the servlet in the web.xml file should be sufficient.
All the external jar / libs like the caucho WS impl. are also
integrated in Spring (not sure about pico but it won't be a problem).
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?

Yesterday I checked out the ASF third party licensing policy...
The lists below declare which licenses are authorized and which
licenses are excluded from applying to any part of a product
distributed by an ASF PMC.
Authorized:
    * Apache License 2.0
    * ASL 1.1
    * BSD
    * MIT/X11
    * NCSA
    * W3C Software license
    * X.Net
    * zlib/libpng


Binary only:
    * CDDL 1.0
    * CPL 1.0
    * EPL 1.0
    * IPL 1.0
    * MPL 1.0 and MPL 1.1
    * SPL 1.0


So hivemind (requieres some other jars like javaassist it MPL and
apache oro is ASF) is ASF, Easymock is MIT, the caucho Hessian WS is
ASF.

So keep on downloading these libs for a build but it won't be a
problem to include these distributions inside a gdata distribution.

best regards Simon

On 11/9/06, peter royal <[hidden email]> wrote:

> On Nov 8, 2006, at 11:43 AM, Simon Willnauer wrote:
> > That's why I evaluated some IoC DI container like spring, hivemind,
> > pico and Felix (Apache OSGi). Hivemind felt good to me due to some
> > reasons (some more on this later @siren I will send a separate email
> > on this topic).
>
> would it be possible to fashion the GData server such that it is a
> set of POJO's (one logical module), and then there is another logical
> module that wires them up in a usable fashion using Hivemind (another
> logical module). That way if someone wanted to use pico/spring/
> whatever, they could, since the core components are container-
> independent.
>
> since HiveMind services are POJO's, this should be possible, as long
> as no hivemind magic is required for the system to function.
>
> -pete
>
>
> --
> [hidden email] - http://fotap.org/~osi
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: ThirdParty Jars in GData

peter royal
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




--
[hidden email] - http://fotap.org/~osi




smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ThirdParty Jars in GData

Simon Willnauer
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 <[hidden email]> 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
>
>
>
>
> --
> [hidden email] - http://fotap.org/~osi
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]