On 23 jan, 20:57, Laurent PETIT <laurent.pe...@gmail.com> wrote: > OK, I understand better now, I think. > > Did you experience the problems you have exposed ? Or is it an anticipation > of problems ? >
Yes I directly experience the problem when I first implement a Clojure REPL inside Eclipse and do not have access to some resources of other plugins. The best way to reproduce the problem is to implement the use case I described : two plugins with dependencies. > If so, can you expose the tests data, so that one can also experiment with > them ? > I can provide a simple example with a hello world action. > 2009/1/23 Gaetan Morice <gaetan.mor...@gmail.com> > > > > > Hello Laurent, > > thank you for your interest. > > > 2009/1/23 Laurent PETIT <laurent.pe...@gmail.com> > > >> Hello Gaetan, > > >> I'm one of the core developers of clojuredev, an open source project whose > >> goal is to provide clojure support for the Eclipse IDE. > >> What you say below is interesting, please see what I have noted inline --> > > >> 2009/1/23 gaetan <gaetan.mor...@gmail.com> > > >>> Hi everybody, > > >>> I am working in a software company specialized in Eclipse based > >>> product development (and member of the Eclipse Fundation). We are very > >>> interesting in clojure features and we plan to use it in some of our > >>> products. I am currently working on clojure integration in OSGi > >>> Bundles in order to embed code in Eclipse plugins. As mentioned in > >>> some posts the biggest problems is class loading. Indeed in OSGi each > >>> bundle has its own class loader and class loading is not based on the > >>> application classpath or on the current thread class loader. > >>> Consequently, it is very difficult to make clojure work with java code > >>> and to use OSGi visibility and dependencies system inside clojure. > > >> For mere mortals like me, could you explain the problem via an example ? > >> (I understand there is a problem, I don't exactly understand what it > >> really is) > > >> Concerning clojuredev, we provide clojure as a separate plugin, which > >> exposes everything to plugins that depend on it. > >> Currently, clojuredev plugin is successful in calling clojure core > >> functions defined in clojure plugin, as well as loading new functions and > >> namespaces from clojuredev plugin. > > > I will try to give an example (I hope it will be understandable). > > First has you may now in OSGi (and therefor in Eclipse) each bundle declare > > its dependencies toward others in the MANIFEST.MF file. If you > > are developing a bundle "a" that needs a class in a bundle "b" you have to > > update the MANIFEST.MF file of "a" to said that it depends on "b" and "b" > > has to export the package that contains the class (this information is in > > the MANIFEST.MF file of b). Under the hood, each bundle has its own class > > loader that is fully aware of the dependencies and export of the plugin. So > > in the example above, at runtime the class loader of "a" will be able to use > > the class loader of "b" (thanks to the dependency declaration) and this one > > will be able to load the class for an external bundle (thanks to the export > > declaration). Now if you want to use clojure code in your OSGi instead of > > java. First you will embed clojure core in a specific bundle called "c". You > > write a clojure lib in "a" that use another clojure lib in "b". What > > will happen? To load code of "b" the lib in "a" will use the "use" (or > > "require") function of clojure core. This function use a specific class > > loader (called DynamicClassLoader) that use the class path of > > the bootstrapping thread. However this class path is not aware of the > > bundles inside the application and so the clojure class loader will not be > > able to find the lib in "b". Another case is if you want to use clojure code > > in "a" that use java code in "b". In this case clojure code use the "import" > > function of clojure core. This function use the Class#forName method that is > > based on the caller class loader. In this case the caller is clojure core > > and so its class loader is the class loader of "c". As this class loader as > > no dependencies toward "b", it will not be able to load the java class. > > As you can see the problem is a little tricky :-). That's why I think the > > best way to use clojure in OSGi bundles is to enable clojure to use bundles' > > class loader, it is flawless and understandable as it mimics java behavior. > > To do this I use clojure namespaces. In the example above the clojure lib in > > "a" must have a namespace that start with "a" so the clojure class loader > > can find and use the class loader of bundle "a" to load its dependencies. > > Thanks, I now see what you mean. > > > > > > >>> I > >>> think the best solution is to use bundles class loader inside clojure > >>> class loading system. I developed a proof of concept that uses a new > >>> class loader that extends clojure.lang.DynamicClassLoader with bundle > >>> class loading capability. To know which bundle use to load classes or > >>> script file the class loader uses the current namespace which has to > >>> reflect the bundle name (this is the java convention for bundles). In > >>> order to use this new class loader I had to modified > >>> clojure.lang.RT#baseLoader and makeClassLoader and > >>> clojure.lang.core#import. Moreover to test this I made a experimental > >>> Eclipse Builder that enable AOT compilation of mixed clojure and java > >>> plugin. So far it seems to work well: clojure and java interact > >>> seamlessly and it is very fun to interact dynamically with an Eclipse > >>> instance! > > >>> I had some questions to the clojure community: > >>> * Whether it is possible to overload clojure class loading without > >>> introducing dependencies in clojure's core? > >>> * If their are some people interested in this application of clojure? > >>> (I can made my sources available) > > >> We currently don't have made the AOT version of the eclipse builder, so if > >> you could publish what you've done so far that would be great, because we > >> could work on it, or it could give us some hints to make our own. > > >> Is it possible for you to publish it, maybe via the EPL, which seems to be > >> the 'defacto' Open source license to use when creating code around clojure > >> ? > > > No problem I will release the code under EPL. However you must be aware > > that it is a proof of concept and there is a lot of things to fix and > > re-factor. I just have one question what is the best place to share the code > > ? > > I don't have the rights to make you a commiter of clojuredev (not the > project owner), so I don't know ... maybe you could just place your > copyright + EPL on your files, and attach it to issue 3 in clojure-dev > bugtracker ? (http://code.google.com/p/clojure-dev/issues/detail?id=3) > I attach my builder and visitor to the issue 3 of clojure-dev (tp:// code.google.com/p/clojure-dev/issues/detail?id=3). > Thanks in advance, > > -- > Laurent > > > > > > >> Regards, > > >> -- > >> Laurent > > >>> Moreover I will made a post on Eclipse E4 project mailing list (work > >>> on the future of Eclipse) as they are very interested in dynamic > >>> languages. > > >>> BR, > > >>> Gaetan > > >> Cheers, > > Gaetan > > -- > Cordialement, > > Laurent PETIT Gaetan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
