Embracing Maven may sound like madness for a dynamic language when you are trying to break free from Static Languages Land. There _ARE_ compelling arguments for using simple maven pom files though.
1 - You get access to repository managers like http://archiva.apache.org/ 2 - You get access to automated build tools like https://hudson.dev.java.net/ and http://continuum.apache.org/ 3 - IDEs can pick up pom.xml files and "just work" 4 - DRY project structure. Not reinventing the wheel for every module you write. 5 - Lots of other reasons. On Apr 2, 7:39 am, Jason Sankey <ja...@zutubi.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
