Lee Spector <lspec...@hampshire.edu> writes: > FWIW for some JVM newcomers (like me when I started) #6 involves some > mysteries related to where exactly the jar should be saved and how > exactly the other code can be told to find it. It varies depending on > how you run your code (e.g. whether you have to figure out how to > construct a -cp argument or do other non-obvious things in a complex > IDE, etc.) and then there's the hierarchical namespace/directory > structure correspondence, which I found initially surprising and > confusing. > > Bottom line is that I agree that leiningen makes all of this simpler, > assuming that your editor and other tools play nice with > leiningen. I'm just pointing out that the manual method is actually a > little worse than you've implied, for people new to JVM programming.
Oh I totally agree. Perhaps I was being misleading there. I was replying to Mikal's hypothesis that if library authors used a manual release process instead of version control and build tools everything would be considerably simpler for library consumers who know how to feed jars to the JVM. It's definitely worth questioning your assumptions from time to time and I'm glad he brought it up, it is giving me some ideas. I don't think it's a good solution though because the tools at the very least give us consistency. I don't think the maven standard is perfect. The whole "group id" thing in my opinion is confusing and not quite right (which is why with Clojars I deviated from how Maven Central uses it). But at least we have a way that all the tools (and people) can interoperate with each other and I'm willing to live with some warts in order to get that. The JVM does not make things fun. It was only in Java 6 that the ability to use wildcards in the classpath (-cp lib/*) was added for example, in earlier versions you had to specify every single jar file one by one. But that's not the fault of build tools, the tools exist precisely because the JVM does not ship with a good solution to this problem. Tools with a system install model like RubyGems and ez_install seem deceptively easier when you're a beginner. I think they do work well in a highly structured and well curated ecosystem (eg Debian) but that takes serious commitment. Unfortunately once you get past the beginner stage and start dealing with multiple versions of libraries and such it quickly turns into a huge headache and you end up with awful workarounds like RVM. I work at a shop that uses both Ruby and Java. For our Ruby projects after much frustration we've just resorted to chucking all the gems for a project into the project's version control and pointing at them with GEM_HOME. Some of our developers try to use Bundler but I find it to be more trouble than it's worth (particularly when deploying to JRuby). It's amazing how much time someone can waste messing around trying to get Bundler to behave right. Compared to that the Leiningen model as a default is downright blissful. Clojure/core are pushing a third model. Get all the good stuff into contrib. I guess you could compare that to something like FreeBSD and in a sense the way the Linux kernel project works. Ultimately that very likely will result in higher quality output and is not bad for beginner users. But to get that quality it necessarily means a bigger commitment and a higher barrier to entry for authors. http://groups.google.com/group/clojure/browse_thread/thread/c40ff3e876b4b370 I'm glad to see that core are trying to make contrib model more accessible. For a long time with Rich as the sole gatekeeper it was a pretty select club. Even now though it could be better communicated, the references to contrib on the website are pretty vague if you don't already know what it is. I've been fairly heavily following Clojure for a couple of years now, I have signed the CA and I'm still not completely sure if I'd be welcome to contribute to contrib. It's intimidating. Maybe that's just timidity on my part though. -- 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
