On Tue, Oct 13, 2009 at 22:25, B Smith-Mannschott <bsmith.o...@gmail.com> wrote: > I am attempting to use clojure-maven-plugin 1.0 and discovered that I > can crash the compile by inserting a newline in the ns declaration > between "ns" and the symbol naming the namespace: > > (ns > somenamespace) > > This produces the following stack trace: > > Compiling to /home/smithma/w/minimal/target/classes > Exception in thread "main" java.io.FileNotFoundException: Could > not locate __init.class or .clj on classpath: > at clojure.lang.RT.load(RT.java:402) > at clojure.lang.RT.load(RT.java:371) > at clojure.core$load__6347$fn__6356.invoke(core.clj:4072) > at clojure.core$load__6347.doInvoke(core.clj:4071) > at clojure.lang.RestFn.invoke(RestFn.java:413) > at clojure.core$load_one__6277.invoke(core.clj:3908) > at clojure.core$compile__6362$fn__6364.invoke(core.clj:4082) > at clojure.core$compile__6362.invoke(core.clj:4081) > at clojure.lang.Var.invoke(Var.java:359) > at clojure.lang.Compile.main(Compile.java:56) > > Remove the line break so that somenamespace.clj consists of just > > (ns somenamespace) > > and the exception does not occur. > > This build of clojure-lang is being used by clojure-maven-plugin: > > clojure-lang-1.1.0-alpha-20091013.093205-73.jar > sha1 = d02209bf56d1b2fb0849926bf62ad38a89000dae
This appears to have been a bug in clojure-maven-plugin 1.0, as editing pom.xml to use clojure-maven-plugin 1.1 fixed the problem. :o) So, what can we conclude from this? That version 1.0 "parsed" the clj file with a parser that is not clojure -- probably just looking for a line that contains "(ns", tried to pull out the namespace's name, but failed and then failed to notice that it had failed and proceeded to call the compiler with a null or empty string as the name of the namespace?? Hmmm... tasty. Well, I'm glad it's fixed in 1.1, but I have to say I see these sorts of "phenomena" an awful lot when working (fighting?) with maven. Is there something about maven's architecture or development culture that encourages these kinds of errors? // Ben --- OT/RANT Here, one little story of many to illustrate the flavor of what I'm talking about: We were having trouble because our maven builds only contained *partial* debug information. (FileTable and LineNumberTable were being generated but LocalVariableTable as not.) The reason, I discovered, was that I'd configured maven-compiler-plugin as <debug>all</debug>, which is *of course* wrong, though finding the documentation that showed me that debug is in fact boolean and can only be "true" or "false" was non-trivial. (I'm not sure where I got the "all" from, probably some fragment of less-than-helpful maven advice off of the Interwebz.) So, ok, debug is a boolean that defaults to true, according to the documentation. If i set it to false, I get *no* debug information. If I set it to true I get *all* debug information. That all makes sense. I tried it out, and it works as expected. But, if I set it to "all", I get *some* debug information. No error, no exception. Maven just silently accepts it and then does something decidedly non-boolean with it's boolean: debug="66% true". I read the code of maven-compiler-plugin (there's not much of it) to understand how this behavior came about, and failed to be enlightened. I found the boolean field "debug", but of course, it doesn't get set anywhere in maven-compiler-plugin because there's some kind of plexus voodoo going on which osmoses values from pom.xml into plugin objects. What does it do when it expects a boolean and finds something else? No idea. The only thing that appears to actually happen is that this AbstractCompilerMojo copies the debug flag into an instance of org.codehaus.plexus.compiler.CompilerConfiguration, which is nowhere to be found. I've stopped looking. How can it be that I've been using maven for over three years now, and I still find it failing on me in the most bizarre ways and when I investigate their failures, I inevitably run up against code that is impenetrable or appears to *do nothing* other than mutate yet more values in yet more objects? (This is the the very antithesis of immutability-heavy functional programming as encouraged by clojure.) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
