OK, I understand better now, I think. Did you experience the problems you have exposed ? Or is it an anticipation of problems ?
If so, can you expose the tests data, so that one can also experiment with them ? 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 ) 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
