Hi, Am 14.04.2009 um 17:17 schrieb Laurent PETIT:
It will be very difficult to speak about it without the discussion switching to a dependency management tool war .... OR to keep things simple, add the dependencies (if their license allow it *OUCH*) in some libs/ directory in clojure-contrib itself.I guess Meikel Brandmeyer somewhat started to show the path by already offering a split of clojure-contrib in several more modular units.AGAIN, I would be very unhappy to have to download even one or two jars from the web in order to be able to compile clojure-contrib if I just want to use a namespace of it that has nothing to do with the downloaded jar, either directly or indirectly ...
I think splitting into modules is the key here. While experimenting with Ivy I got a setup where really only what is needed is downloaded.I can specify dependencies like eg. a test library or a source jar, which
are only used while I develop the library. The user of the library only really gets the runtime dependencies. I also don't understand the distaste which is exhibited for such buildsystems. Eg. with Ivy I can specify a hierarchy of repositories. If I don't
want to download stuff, I simply remove the public repository. And only the local repositories are searched for dependencies. I have the flexibility to decide. Nothing is forced. However this is at the moment based on pre-compiled jars. On the build machine all dependencies (eg. miglayout) must be available. This might not be viable when compiling itself must be done, eg. for a different host VM. So a more modularised build should be also possible. I'm a bit amazed, that the build systems today go away from really building what's necessary to go to some targets which are purely PHONY (in make terms). Make is not perfect, but it does have a point! Sincerely Meikel
smime.p7s
Description: S/MIME cryptographic signature
