On Mon, Dec 14, 2009 at 11:31, Chas Emerick <cemer...@snowtide.com> wrote: > There are certainly binary incompatibility issues between the > different versions/branches -- that'll settle out as the core matures, > and IIUC, especially once c-in-c becomes a reality. > > However, only providing libraries as source (non-AOT-compiled) jars > whenever possible only shifts the problem around. Interop > requirements are often known of ahead of time (ha!), but many > "classloader issues" are totally in the hands of whomever is deploying > the end application, their java security policy, etc. In those > contexts, having only clojure source libraries available in maven > repos is an active hurdle to usage perhaps as irritating as having to > unwind "unnecessary" AOT compilation. Of course, people with a strict > AOT-compilation requirement can do the AOT-compilation on their own, > but I for one do not want to see Gentoo-esque norms emerge in the > Clojure community. > > A more general solution would be to encourage library authors to > produce and deploy both source *and* binary, AOT-compiled artifacts, > and leave the choice to the library's users. I set this up on > Saturday for clutch (a clojure couchdb library and view server) in the > process of mavenizing the project: > > http://github.com/cemerick/clutch/commit/aef461a6fd3c4797aef3b110677197f7351bb831 > > Then, to depend upon only the source jar in a downstream project, one > would simply add a 'classifier' element to the dependency element: > > <dependency> > <groupId>com.ashafa</groupId> > <artifactId>clutch</artifactId> > <version>1.0-SNAPSHOT</version> > <classifier>sources</classifier> > </dependency>
Hmmm... but in the Clojure world there's a third variant, isn't there? i.e. something like 'slim' which contains AOT only where required: namely in the case of genclass or such. > I think offering both types of artifacts is a much more user-friendly > approach, is *very* easy to do (assuming maven usage), and resolves > all of the issues in play here (modulo the clojure.lang binary > signature incompatibilities that exist, but those should resolve > themselves in due course). > > Cheers, > > - Chas > > On Dec 13, 5:44 pm, dysinger <t...@dysinger.net> wrote: >> So in my experiments with using clojure / contrib w/ the "new" branch, >> I've noticed a pattern of binary incompatibility. Jars pushed to >> clojars, maven repos and other places that are are unnecessarily >> AOTed, don't work with clojure "new". I noticed the same thing going >> from clojure 1.0 to clojure 1.1.0-SNAP. >> >> It doesn't really seem to matter if you include the src "clj" files >> along with the class files in your jar. As soon as clojure hits a >> classfile with an older AOTed namespace, it blows up. This isn't a >> criticism of clojure. Clojure needs it's freedom to innovate. >> >> ...but clojure, by default, JIT compile clj files. I would just like >> to start a conversation about using AOT sparingly if you publish your >> clojure project as a library. Ask yourself "why am I AOTing this >> namespace? Do I think JIT compiled dynamic clojure is dumb? Is this a >> gen-class I need outside clojure in some fancy XML config file? Is >> there some classloader issue that makes it necessary to compile AOT ?" >> If the answer is NO, then please don't AOT the code. >> >> I went through the pain of 3 days of on/off twiddling with libraries >> so our project could use clojure "new". The hair-pulling details >> where in all the code that was AOT when there was no reason to do >> this. 99% of time there were no gen-class or anything else to require >> it. People just like compiling stuff [ I get the feeling they think it >> has some sort of ricer benefit to AOT compile ]. Most clj files work >> great with all versions of clojure if you just jar the clj files and >> leave class generation for runtime. >> >> Don't get me wrong, there are places where a single namespace or two >> are necessarily AOTed for interop or for classloader issues. But just >> carte blanche AOT makes it harder on other people using your library - >> to the point of trying to remove your library from their dependencies >> (trust me - been there). >> >> Code that _could_ run perfectly on clojure 1.0, 1.1.0-SNAP and "new" >> are restricted to one version when AOTed and 99% for no reason. >> >> Maybe Rich can comment on where I am missing it. But I think this is >> my stance. >> >> -Tim > > -- > 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 > Note that posts from new members are moderated - please be patient with your > first post. > 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 -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
