OSGi

[jim]

Hi All,

In my Clojure work, I'm starting to move beyond what can easily be
contained in a single file and into areas that require directory trees
of source code and modules.

I'm starting to learn about OSGi and how (or if) it might be
integrated into Clojure.

Does anyone have any opinions on this or know enough about OSGi to
discuss the pro's and con's?

Jim

[czerwonka]

OSGi gives you finer grained control with visibility. Each plugin has
its own classloader, which is a gotcha for most people. Anyway, much
more that I can tell you in a post. You'll find a bunch of help on
the web.

[Neil Bartlett]

I'm also very interested in this combination. Unfortunately the
integration is not trivial, since Clojure is implemented entirely with
static methods and variables. I believe there is a solution and I am
working on it, however it might require me to submit patches back to
Rich. The problems at the moment seem to be as follows:

1) There doesn't seem to be a way to provide a classloader to the
compiler for proxy generation
2) The on-the-fly compilation module I think needs to be separated
from the runtime library, i.e. any classes in the clojure.lang package
that are depended on at runtime by compiled Clojure code.

Also there is the more philosophical question: if I have an OSGi
bundle implemented in Clojure, how on earth do I know in advance what
its dependencies are? With Java bytecode I can use a tool that
inspects the constant pools etc to discover dependencies, but with
Clojure I need to either process the source (well, thank goodness it's
a Lisp) or I need to "just know".

Regards
Neil

[Lau B. Jensen]

Hey all,

Does anybody here have a concrete example of a complex (or big at least) GUI
built in Swing/Matisse and then driven from Clojure? So far I've only done
the manual imports and declarations.

/Lau

[Rich Hickey]

On Jun 9, 4:41 pm, "Neil Bartlett" <njbartl...@gmail.com> wrote:
> I'm also very interested in this combination. Unfortunately the
> integration is not trivial, since Clojure is implemented entirely with
> static methods and variables. I believe there is a solution and I am
> working on it, however it might require me to submit patches back to
> Rich. The problems at the moment seem to be as follows:
>
> 1) There doesn't seem to be a way to provide a classloader to the
> compiler for proxy generation

I've added clojure/*use-context-classloader*, defaults to nil, which
can be dynamically bound to true to cause the thread's context
classloader to be the parent of the dynamic classloader used during
load. Note that the proxy class itself will still be loaded under the
Clojure classloader, but it is just a stub (i.e. it does not contain
the code you supply to proxy). The other code generated while *use-
context-classloader* is true (including the proxy bodies) will have a
classloader whose parent is the context classloader.

Let me know if that helps. I can say for sure that using a different
base classloader will not be compatible with add-classpath or gen-and-
load-class.

> 2) The on-the-fly compilation module I think needs to be separated
> from the runtime library, i.e. any classes in the clojure.lang package
> that are depended on at runtime by compiled Clojure code.
>

There isn't a significant difference that warrants this separation.

Rich