Paul Stadig wrote: > This works great for Java libraries, but only libraries that are in a > maven repo. How hard is it to get code into a repo? What about java > libraries not in a maven repo, or clojure code like clojure-json on GitHub?
I don't think it is terribly hard to get in the repo, but there can be lag. > 1. You could set up your own repo. Ok. Cool, but not the easiest to > setup and maintain, plus you need a server. Actually, many Maven projects end up having to do exactly that, and indeed lots of people recommend doing so. The main reasons are: 1) Having an external dependency for your build is bad news: e.g. you don't want your builds to fail because the Maven repo is down. 2) Historically at least the Maven central repository contains projects with incorrect dependency information, so you need to correct that yourself anyway. 3) Just depending on the latest version of a module (or latest of a release stream) on the central repository means your build can break due to an unforseen external change. So while it might seem nice to keep magically up to date (without changing your own repository/poms) at first this is not something that works in practice. Maintaining your own repository takes work but makes these problems go away. On the flipside you have to ask if this work is yielding enough benefit over just getting the jars you need and dropping them in a directory. I think for small projects/companies it won't be, but for larger efforts and particularly where you have multiple modules of your own with their own interdepencies the balance tips. > 2. You could install dependencies in your local repo. Cool, if the > project happens to be using maven and you can to "mvn install". Uncool, > if you have to manually "install" it into your local repo. Also uncool, > because I see my local repo more as a cache that can sometimes get > crufty and can be cleared out if I need the disk space. Maven *should* > be able to re-download my dependencies and put them in my local repo, > but not so for these manual workarounds. In my experience for these other dependencies the trickiest part can be figuring out what they in turn depend on, which you have to do either way. Once you know that dropping them into a simple repository is not that hard. If you want to maintain this information that you derived manually, then you just can't expect to treat it like a cache. Keep One True copy somewhere, possibly in version control. > 3. ??? > > I'm not trying to be disparaging. If this works for someone, I think it > is pretty slick. I'm still of the mind that there could be something > better. Something that can pull from a maven repo as needed, but also > pull from other sources like github, sourceforge, google code, etc. I'm > just spoiled by rubygems. This is an existence proof that there can be a > simple way to download and setup dependencies (not without foibles). Other tools like apt/dpkg also come to mind as solving this reasonably well. I think a key thing in this case is a lot of effort goes into maintaining the packages and testing a full "distribution" of them together. This makes the dependency information and stability more reliable than the Maven central repo -- but it requires a lot of resources. > Perhaps if there was a Clojure Maven Repo (CMR) where people could > easily get their code distributed, then I would feel satisfied. Certainly a standardised way to specify your dependencies would be a good thing. I'm not sure it needs to be Maven based -- although interoperability with Maven would be a worthy goal. I am personally a happy Ivy user -- Ivy essentially does the dependency management part of Maven but (IMO): - with more flexibility; and - without the rest of the Maven baggage (or features depending on your perspective) Ivy interoperates with Maven, and also supports pluggable resolvers, so you can host your Jars/dependency information in multiple ways. > What happened to the ClojureForge idea from tech.coop > <http://tech.coop>? Did anything come about from that, Drew? Perhaps > just hosting CMR with some way to signup for an account to be able to > "mvn deploy"? A central place to at least look for Clojure libraries would be a great start. If it also hosted those libraries and included standardised dependency information, I think it would be helpful whether you just wanted to stick the jars in a directory or use a full-blown dependency management tool. Cheers, Jason > On Thu, Apr 2, 2009 at 1:25 AM, dysinger <dysin...@gmail.com > <mailto:dysin...@gmail.com>> wrote: > > > ...for easy dependency management and no-compile project setup. > https://github.com/dysinger/clojure-pom/tree > > Using maven only for the dependency management and to create a custom > repl script allows me to still use emacs/slime for dynamic development > of clojure code. > > My motivation is 3 fold: > > 1) I have lots of small modules and want convention over configuration > (no boiler plate ant scripts or other such cut and paste) > > 2) I want access to the kabazillion libraries in the maven repos - > just go look at mvnrepository.com <http://mvnrepository.com> for > example. > > 3) Although I spent 10 years on Java, I am a dynamic language fan. I > don't care or want to AOT compile at the moment. I just want to setup > the libraries that my clojure code depends on and start writing / > prototyping clojure code in Emacs SLIME. > > I would love to hear some feedback and/or what other people have been > working on. > > -Tim > > > > > -- Pulse - Continuous Integration made easy. Does your project have a pulse? Try it free at: http://zutubi.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
