Thanks for providing some background and cases where you ran into this as well - it's very helpful!
Thus far I've been able to justify adding clojure support to our build process in large part due to the fact that it integrates very well, and doesn't require changes to how our build process (or existing code) works. It's still very much being evaluated, and I think it would harm its longer-term chances (I'm speaking specifically of my workplace, and not in general) of acceptance if I have to make many changes to accommodate the clojure compiler specifically. On Jan 26, 3:51 pm, Luc Prefontaine <lprefonta...@softaddicts.ca> wrote: > At least, there's no bad side effects, we had an issue in 2008 > with a Spring context being loaded statically in a class called > at compile time oups :). Took us some time to realize what was going on, > it was exiting (System.exit) if the context could not be loaded. > > That's the worse case we hit but it was bad enough. > > Could you provide a System property to wrap the static code to detect > if it's compile time or runtime ? That could be a way to avoid > mouse traps... There's a special variable in Clojure set by the compiler > for this purpose but accessing it from java is another story I think. > Passing this to the JVM doing the compilation is by far easier. > > Of course it might be quite an amount of work to add this in all the classes > that do static inits but it could be a workaround for the most > problematic cases. > > Luc P. -- 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
