On 26 jan, 13:29, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> Hello Gaetan,
>
> Thanks for the shared code. I think that for a first version in clojuredev,
> I'll too just implement the full builder, and wait for performance problems
> before writing an incremental one (thus saving development time for adding
> other functionalities right now).
>
> BUT I think I'll not follow the example in one place. I'd like to hear what
> you think about my arguments, though:
>
> I'll not use the clojure environment of the plugin to compile files. For at
> least two reasons :
> * if there is malicious or problematic code in the compiled files, I don't
> want the eclipse environment to hang, or to crash.
You are right, it may rise some problems as the compiled code is
loaded in the clojure runtime (I don't think that you have to bother
about malicious code). It would be nice in that case to be able to
unload code after compilation, I don't think that the current runtime
enable that. However it could be very useful to have the code loaded,
in order to perform syntactic analysis, re-factoring and other
operations.
> * to decouple the version of clojure needed by the plugin own needs (for
> the parts of the plugin written in clojure), from the version of clojure the
> user wants to use : I'll use the version of clojure the user wants.
That's true too. As Werner Schuster told me, it seems very difficult
to run two different versions of the clojure runtime in the same
process.
>
> But this will lead to another problem : we can't, for performance reason I
> fear, start a new JVM each time we want to compile a new file ! So there
> will be the need to share an instance at the project level, and be sure this
> instance is still alive (and in good conditions ...)
Maybe it is the best solution : using a specific JVM for a set of
project that work together and have a repl plug on it. However it may
rise a problem in the interaction with JDT.
Indeed, if you compile your code with gen-class to use it directly in
java, JDT needs the generated *.class file, otherwise the project
won't compile corectly.
>
> ==> Do you know how the JDT does for incremental compilation of java files
> (sensible when eclipse is running with JDK 6, but the project depends on
> e.g. JDK 1.4.2) ?
In fact JDT does not use the JDK to compile code : it embeds its own
compiler. So, I assume it can compile code for all Java versions
regardless the JDK on which it runs.
>
> Regards,
>
> --
> Laurent
>
> 2009/1/26 gaetan <gaetan.mor...@gmail.com>
>
>
>
> > 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
-~----------~----~----~----~------~----~------~--~---
