Re: Polyglot (Clojure) Maven (Was: Re: Choosing a Clojure build tool)
On 28/03/2010, at 8:01 PM, B Smith-Mannschott wrote:
On Sun, Mar 28, 2010 at 08:39, Antony Blakey antony.bla...@gmail.com wrote:
On 28/03/2010, at 4:42 PM, Antony Blakey wrote:
(defproject main org.clojars.the-kenny:clojure-couchdb:0.2
:add-default-plugins true
:description Simple Clojure interface to Apache CouchDB, fork of the
original project with function arguments instead of *server* and some other
changes.
:dependencies [[org.clojure:clojure:1.1.0-master-SNAPSHOT]
[org.clojure:clojure-contrib:1.0-SNAPSHOT]
[org.clojure:clojure-http-client:1.0.0-SNAPSHOT]])
Actually, it's even simpler than that because the string-format coordinates
removes the need to wrap the coordinate in a vector:
True, but concatenating the three coordinates together into a single
string smells like a [first normal form][1NF] violation to me. I think
Leiningen's notation is a better fit and more idiomatic as Clojure,
even if it is a little more verbose to type.
Having completed this now, so I can read leningen files, the problem is that
the leiningen format needs to be quoted i.e the macro needs to transform
:dependencies [[a/b 1.0]]
into
:dependencies '[[a/b 1.0]]
which means that the dependencies list cannot be computed dynamically (well,
without extra syntax to unquote). It would have been ok if leiningen required
quoted symbols e.g.
:dependencies [['a/b 1.0]]
- Clojure code manipulating poloyglot's notation is more complex
because it must be parsed first, and then recombined. Leiningen's
notation already is 'parsed'.
Parsing is still required in order to deal with the optional nature of the
group id and version number e.g.
(defmulti parse-reference class)
(defmethod parse-reference clojure.lang.Symbol
[reference]
(let [artifact (name reference)
group (if-let [g (namespace reference)] g artifact)]
{:group-id group :artifact-id artifact}))
(defmethod parse-reference clojure.lang.PersistentVector
[reference]
(let [ga (parse-reference (reference 0))]
(if (and ( (count reference) 1) (= (class (reference 1)) String))
(assoc ga :version (reference 1))
ga)))
So the difference is minor.
- Editing just the version of a dependency (or the project itself) is
a fairly common occurrence and is somewhat more awkward if you're
editing only *part* of a string literal, rather than a single token.
Agreed.
Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Always have a vision. Why spend your life making other people’s dreams?
-- Orson Welles (1915-1985)
--
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
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On 29.03.2010, at 08:24, Mark Derricutt wrote: Why do you need to edit the settings twice a day? Strikes me as a problem. You could move the relevant mirror/ settings into a profile which is only activated based on network/env settings, so those changes are automatic? What I found about proxy configuration is this: http://maven.apache.org/guides/mini/guide-proxies.html It doesn't say anything about profiles, or about any other way to have multiple proxy configurations. Other sites I found just repeat the information from the manual. There may be ways to have more dynamic configurations, but I am not a Maven expert nor trying to become one. Life's too short for studying idiosyncratic build tools. Konrad. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Polyglot (Clojure) Maven (Was: Re: Choosing a Clojure build tool)
[I've cross posted because I think this is relevent to both lists] I've started fixing some bugs in the Clojure support in polyglot maven. I've sent pull requests upstream, but until then you can get it from http://github.com/AntonyBlakey/polyglot-maven. It works as my default maven (although there are some plugins such as the Atlassian stuff that doesn't work in Maven 3), and is self hosting. The simplest pom.clj, corresponding to this leiningen project: (defproject org.clojars.the-kenny/clojure-couchdb 0.2 :description Simple Clojure interface to Apache CouchDB, fork of the original project with function arguments instead of *server* and some other changes. :dependencies [[org.clojure/clojure 1.1.0-master-SNAPSHOT] [org.clojure/clojure-contrib 1.0-SNAPSHOT] [org.clojure/clojure-http-client 1.0.0-SNAPSHOT]] :dev-dependencies [[lein-clojars 0.5.0-SNAPSHOT] [org.clojure/swank-clojure 1.0]]) is: (defproject main org.clojars.the-kenny:clojure-couchdb:0.2 :add-default-plugins true :description Simple Clojure interface to Apache CouchDB, fork of the original project with function arguments instead of *server* and some other changes. :dependencies [[org.clojure:clojure:1.1.0-master-SNAPSHOT] [org.clojure:clojure-contrib:1.0-SNAPSHOT] [org.clojure:clojure-http-client:1.0.0-SNAPSHOT]]) The most obvious difference is in the coordinate syntax. Note that this includes the clojure-maven-plugin, so you get the following clojure-specific goals: clojure:compile clojure:test clojure:run clojure:repl clojure:swank clojure:nailgun You can package using mvn package, and install to the local repository using mvn install. There are many other things you can do using existing maven plugins. I have a branch that allows leiningen-format artifact references e.g. (defproject main org.clojars.the-kenny/clojure-couchdb 0.2 :add-default-plugins true :description Simple Clojure interface to Apache CouchDB, fork of the original project with function arguments instead of *server* and some other changes. :dependencies [[org.clojure/clojure 1.1.0-master-SNAPSHOT] [org.clojure/clojure-contrib 1.0-SNAPSHOT] [org.clojure/clojure-http-client 1.0.0-SNAPSHOT]]) The single benefit is that it would be easy to allow an existing unmodified project.clj to be used by maven, although without leiningen plugins. I'm not sure if it's worth it, and I'm interested in hearing arguments pro and con. My next step is to make sure it's easy to write polyglot maven plugins in Clojure, with easy deployment. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Polyglot (Clojure) Maven (Was: Re: Choosing a Clojure build tool)
On 28/03/2010, at 4:42 PM, Antony Blakey wrote: (defproject main org.clojars.the-kenny:clojure-couchdb:0.2 :add-default-plugins true :description Simple Clojure interface to Apache CouchDB, fork of the original project with function arguments instead of *server* and some other changes. :dependencies [[org.clojure:clojure:1.1.0-master-SNAPSHOT] [org.clojure:clojure-contrib:1.0-SNAPSHOT] [org.clojure:clojure-http-client:1.0.0-SNAPSHOT]]) Actually, it's even simpler than that because the string-format coordinates removes the need to wrap the coordinate in a vector: (defproject main org.clojars.the-kenny:clojure-couchdb:0.2 :add-default-plugins true :description Simple Clojure interface to Apache CouchDB, fork of the original project with function arguments instead of *server* and some other changes. :dependencies [org.clojure:clojure:1.1.0-master-SNAPSHOT org.clojure:clojure-contrib:1.0-SNAPSHOT org.clojure:clojure-http-client:1.0.0-SNAPSHOT]) Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Albert Einstein -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Polyglot (Clojure) Maven (Was: Re: Choosing a Clojure build tool)
My current proposal for the Clojure DSL for polyglot maven looks like this:
--
(defproject com.linkuistics.lamdras/website 1.0-SNAPSHOT
:model-version 4.0.0
:name Lamdras Website
:description Acumen / LRMDS Integration
:packaging war
:properties {:project.build.sourceEncoding UTF-8}
:dependencies [[ring/ring-servlet 0.2.0-RC2]
[ring/ring-devel 0.2.0-RC2]
[clj-routing/clj-routing 0.1.0-SNAPSHOT]
[clout/clout 0.2.0-SNAPSHOT]
[compojure 0.4.0-SNAPSHOT]
[hiccup 0.1.0-SNAPSHOT]
[org.clojure/clojure 1.2.0-master-SNAPSHOT]
[org.clojure/clojure-contrib 1.2.0-master-SNAPSHOT]
[congomongo 0.1.2-SNAPSHOT]]
:provided-dependencies [[org.mortbay.jetty/servlet-api-2.5 6.1.14]]
:final-name website
:plugins [[org.apache.maven.plugins/maven-war-plugin 2.1-beta-1]
[org.apache.maven.plugins/maven-compiler-plugin 2.1 :source
1.6 :target 1.6]
[com.theoryinpractise/clojure-maven-plugin 1.3.1
:sourceDirectories [src/main/java]
[:compile-clojure [compile [compile
[org.mortbay.jetty/maven-jetty-plugin 6.1.10
:scanIntervalSeconds 10 :stopKey foo :stopPort ]])
--
With logical extension to other maven properties. Note that the configuration
items for plugins and their executions are inlined, and the executions for
plugins appear as the vector item in the plugin declaration.
When the group id is the same as the artifact id you can omit the group id.
Configuration items such as :sourceDirectories that have a vector value are
equivalent to this xml:
sourceDirectoriessourceDirectorysrc/main/java/sourceDirectory/sourceDirectories
An example showing qualifiers and exclusions for dependencies (taken from the
pom.xml for the top level of polyglot maven itself) is:
--
(defproject org.sonatype.pmaven/pmaven 0.8-SNAPSHOT
:model-version 4.0.0
:parent [org.sonatype.forge/forge-parent 5]
:name Polyglot Maven
:packaging pom
:url http://polyglot.sonatype.org/;
:properties {:forgeSiteId forge-sites
:mavenVersion 3.0-alpha-7
:project.build.sourceEncoding UTF-8
:forgeSiteUrl
dav:http://repository.sonatype.org/content/sites/forge-sites/${project.artifactId}/${project.version}}
:scm {:connection scm:git:git://github.com/sonatype/polyglot-maven.git
:developer-connection
scm:git:ssh://g...@github.com/sonatype/polyglot-maven.git
:tag HEAD
:url http://github.com/sonatype/polyglot-maven}
:ci-management {:system Hudson
:url https://grid.sonatype.org/ci/job/Polyglot-Maven}
:issue-management {:system JIRA
:url https://issues.sonatype.org/browse/PMAVEN}
:dependency-management {:dependencies [[org.apache.maven/apache-maven
${mavenVersion} :classifier bin :type zip]
[org.apache.maven/maven-model-builder ${mavenVersion}]
[org.apache.maven/maven-embedder
${mavenVersion}]
[org.apache.maven/maven-plugin-api
${mavenVersion}]
[org.codehaus.groovy/groovy 1.7.0
:exclusions [jline junit org.apache.ant/ant org.apache.ant/ant-launcher]]
[com.google.inject/guice 2.0]
[org.sonatype.maven.shell/mvnsh-maven 0.10]
[org.sonatype.gshell/gshell-core
2.5 :classifier tests]
[org.sonatype.pmaven/pmaven-common
0.8-SNAPSHOT]
[org.sonatype.pmaven/pmaven-cli
0.8-SNAPSHOT]
[org.sonatype.pmaven/pmaven-maven-plugin 0.8-SNAPSHOT]
[org.sonatype.pmaven/pmaven-groovy
0.8-SNAPSHOT]
[org.sonatype.pmaven/pmaven-yaml
0.8-SNAPSHOT]
[org.sonatype.pmaven/pmaven-jruby
0.8-SNAPSHOT]
[org.sonatype.pmaven/pmaven-commands
0.8-SNAPSHOT]
[org.sonatype.pmaven/pmaven-clojure
0.8-SNAPSHOT]
[org.sonatype.pmaven/pmaven-scala
0.8-SNAPSHOT]]}
:test-dependencies [[junit 4.7]
org.codehaus.groovy/groovy]
:modules [pmaven-common pmaven-maven-plugin pmaven-groovy
pmaven-yaml pmaven-clojure pmaven-jruby pmaven-scala pmaven-cli
pmaven-commands]
:default-goal install
Re: Choosing a Clojure build tool
On Mar 26, 2010, at 12:59 AM, Per Vognsen wrote: On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick cemer...@snowtide.com wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is great. Integration tends to hamper reuse. This is likely wading into a silly semantic dispute re: integration, but I'd say exactly the opposite. When libraries are easily accessible within a common platform, it is easier to use them (assuming you are also participating in that platform). JVM libraries *could* be dis-integrated into separate executables or whatever, but that surely wouldn't encourage their reuse. Please note that Maven plugins are entirely, thoroughly optional -- you choose which ones to bring into your environment, exactly analogous to choosing libraries to be reused in an application. It's worth considering how things have played out in other contexts. Take ant, where there *are* plugins for doing a variety of interesting things, but because there is no baseline platform and mechanism for roping in those plugins in a consistent way from environment to environment, they've seen far, far less adoption and usage than the analogous maven plugins, where composition and reliable configuration is enabled by a consistent platform and defined points of integration. To take one of your examples, if I want to bundle my classes and dependencies into a Windows installer, I will call a function in a library (or a command line program in the Unix world) that does that. That's it. It doesn't need to be part of the build system and shouldn't be. I can call functions in the build system to supply the relevant arguments. If the build tool and library is well designed, the added value of integration in this example should be infinitesimal. Yeah, I think we're butting up against semantics (or we have very, very different world views! :-) I'd ask: what *does* belong in a build system? Should compilation be included (doesn't matter which language)? There are command line programs to compile source files, so why bother with make, ant, etc.? Aside from that extreme example (certain suggested only for illustration), how does your preferred approach fare when working with others, and vice versa? Should we all write our own one-off build scripts, each one different from the last, and require our collaborators to grok each one's unique subtleties as needed? Cheers, - Chas -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I'll have to agree with Brain here. As of now, all I need is Leiningen. It does what I want. Lein is a new project, and I'm fairly certain that it will be much more useful in the future. I don't think I've ever seen a language in which part of the community shunned build tools written in the language itself. It's quite hilarious. On Mar 25, 5:17 pm, Brian Carper briancar...@gmail.com wrote: On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Ruby: gem install X Perl: perl -MCPAN -e shell, then install X Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. My dream tool would be: 1) Platform-agnostic (for us sorry souls stuck on Windows at work) 2) IDE-agnostic (make a Netbeans project is great, but Emacs users need some love too) 3) Easy to understand and use for the kinds of tasks Lein covers (I don't want to have to study a Maven book(!) if I can avoid it) 4) Able to handle most or all Clojure and Java libraries I want to install (I don't want to have to circumvent the build tool and do things manually if I can help it) 5) Able to easily browse or search for packages in remote repositories, would be nice Rubygems and Perl's CPAN can handle those kinds of things, for example. If Maven can be those things, I'll have an XML sandwich for lunch with a smile if necessary. : ) Maybe it can and the community just needs to standardize around Maven and provide good documentation and community support for using it with Clojure. I just hope the community standardizes around something; any standard is better than everyone using a different tool. Thanks --Brian -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On 26/03/2010, at 4:37 PM, Rayne wrote: I don't think I've ever seen a language in which part of the community shunned build tools written in the language itself. It's quite hilarious. I've seen many examples where an overwhelming Not-Invented-Here attitude lead to failure. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Isn't it enough to see that a garden is beautiful without having to believe that there are fairies at the bottom of it too? -- Douglas Adams -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On 26/03/2010, at 4:37 PM, Rayne wrote: I don't think I've ever seen a language in which part of the community shunned build tools written in the language itself. It's quite hilarious. People aren't shunning anything because it's written in Clojure. I think that reinventing all that Maven can do, all of the IDE support, tools, documentation etc is misdirected effort. Especially given the appearance of polyglot Maven (Maven 3), which is Maven recast as a Java library that can be driven by languanges such as Clojure. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 12:59 PM, Chas Emerick cemer...@snowtide.com wrote: On Mar 26, 2010, at 12:59 AM, Per Vognsen wrote: On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick cemer...@snowtide.com wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is great. Integration tends to hamper reuse. This is likely wading into a silly semantic dispute re: integration, but I'd say exactly the opposite. When libraries are easily accessible within a common platform, it is easier to use them (assuming you are also participating in that platform). JVM libraries *could* be dis-integrated into separate executables or whatever, but that surely wouldn't encourage their reuse. Please note that Maven plugins are entirely, thoroughly optional -- you choose which ones to bring into your environment, exactly analogous to choosing libraries to be reused in an application. It's not semantic nitpicking. There's a clear-cut difference a piece of reusable code with a function that can be called to generate a bundled Windows installer based on a set of arguments versus something that only works as part of a build system like Maven. I never said they should be separate executables (that's a terrible fit for the JVM world). I mentioned that as an example of how composable systems are built in the Unix world. It's a good conceptual model. In the Clojure world, functions (not necessarily pure, though pure functions play an important role in idempotent building) are the obvious counterparts. It's worth considering how things have played out in other contexts. Take ant, where there *are* plugins for doing a variety of interesting things, but because there is no baseline platform and mechanism for roping in those plugins in a consistent way from environment to environment, they've seen far, far less adoption and usage than the analogous maven plugins, where composition and reliable configuration is enabled by a consistent platform and defined points of integration. I can't comment on Ant as my experience in the Java world is limited to non-existent. To take one of your examples, if I want to bundle my classes and dependencies into a Windows installer, I will call a function in a library (or a command line program in the Unix world) that does that. That's it. It doesn't need to be part of the build system and shouldn't be. I can call functions in the build system to supply the relevant arguments. If the build tool and library is well designed, the added value of integration in this example should be infinitesimal. I'd ask: what *does* belong in a build system? Should compilation be included (doesn't matter which language)? There are command line programs to compile source files, so why bother with make, ant, etc.? No, compilation should not be included. You mention make; it is a macro language, dependency graph walker, shell executor and up-to-dateness checker. It doesn't do any compilation. It's very bare bones. It's not at all perfect but it's much closer to what I want from a build system than something like Maven. Aside from that extreme example (certain suggested only for illustration), how does your preferred approach fare when working with others, and vice versa? Should we all write our own one-off build scripts, each one different from the last, and require our collaborators to grok each one's unique subtleties as needed? The same way it works with any well-written software. When I want to build the bundled Windows installer, I import the library (which knows nothing about my build system) and call a single function, passing along whatever configuration information is appropriate. Done. -Per -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Is there a tool which takes a simple config file as input in some human readable format (like below) and generate mavel pom xml? name: foobar version: x.y.z dependencies: clojure (= 1.1.0), clojure-contrib (= 1.1.0) ... ... Ramakrishnan -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On 26 Mar 2010, at 05:50, Chas Emerick wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is fine, libraries are fine. But Maven seems to be a monolithic beast that does a zillion things automatically and without telling me. Sure, I can always add some magic incantations on the command line to change whatever I want, but I need to know and understand all that. What I like is the Unix approach: each tool does one thing but does it well, and a flexible combination method (shells and pipes in the Unix case) permits everyone to customize the operations as necessary. That doesn't prevent anyone from providing easy-install scripts for end users, of course. My two biggest gripes with Maven (which may be due to my ignorance) are: 1) No clear separation between building and dependency resolution. I want to be able to build and test my code with known versions of everything that are on my machine. This seems to be possible with Maven, but it's not made easy, and I haven't yet figured out how to verify that a build uses my versions instead of the versions downloaded from some repository that I didn't even pick myself. 2) Bad system integration. Maven is the only tool on my Mac that has its own proxy configuration. Everything else uses either the system settings (ideal) or takes the proxy from an environment variable. All those tools adapt automatically when I change networks (twice a day). Only Maven requires me to edit $HOME/.m2/settings.xml twice a day. Konrad. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 1:06 PM, Konrad Hinsen konrad.hin...@fastmail.net wrote: On 26 Mar 2010, at 05:50, Chas Emerick wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is fine, libraries are fine. But Maven seems to be a monolithic beast that does a zillion things automatically and without telling me. Sure, I can always add some magic incantations on the command line to change whatever I want, but I need to know and understand all that. What I like is the Unix approach: each tool does one thing but does it well, and a flexible combination method (shells and pipes in the Unix case) permits everyone to customize the operations as necessary. That doesn't prevent anyone from providing easy-install scripts for end users, of course. Yes, I have exactly same feelings as well. IMHO, ant fits the task of the build tool very well. I never really understood why clojure-contrib moved to maven. What is needed is a tool to handle just the dependencies part. -- Ramakrishnan -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Fully agree, reinventing the wheel is not a good time investment. Ant has been there for years, why not reuse it ? Why reinvent Ant (or Maven) in Clojure ? The fact that they may look ugly and cumbersome to use has to be separated from the benefits they provide. We switched to Leiningen here and created an internal Maven repository with Archiva for our own components. Leiningen implements in Clojure a simplified build interface, this is where the niceties are for users. It take cares of the house keeping for you and this is where we want a tool to save us time. Aside from resolving our dependencies in Maven repositories on the net and loading a few unknowns to our internal repository, we did not have anything else to do build wise. We have around 100 dependencies here and were looking for a way to simplify this management. Leiningen does it. If Ant or Maven changes, most of these impacts will most probably be hidden in Leiningen. We could not care less about the internal details... that's not where we see the added value of a build/deployment tool, it's in the day to day use by normal developers (non-Maven/Ant experts). Leiningen can handle simple projects as well as complex ones, why create yet another tool/tool-set ? For the sake of having it written 100% in Clojure ? Efforts should be focused on improving Leiningen when needed, not on creating another gizmo. As for the obsessive desire to get an integrated build/deployment tool, picture this, we need to manage all the above dependencies plus our own components AND multiple costumer site configurations. Having some simple automation here is an absolute requirement. We will add a deployment plugin to Leiningen this year to manage our deployments at customer sites. A Rails/Ruby one is also on the table. I do not call this hilarious (or obsessive), it's called common sense. Humans could still be reinventing fire every century but there's no added value to this process. Luc P. On Fri, 2010-03-26 at 16:49 +1030, Antony Blakey wrote: On 26/03/2010, at 4:37 PM, Rayne wrote: I don't think I've ever seen a language in which part of the community shunned build tools written in the language itself. It's quite hilarious. I've seen many examples where an overwhelming Not-Invented-Here attitude lead to failure. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Isn't it enough to see that a garden is beautiful without having to believe that there are fairies at the bottom of it too? -- Douglas Adams -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 26, 8:53 am, Per Vognsen per.vogn...@gmail.com wrote: It's not semantic nitpicking. There's a clear-cut difference a piece of reusable code with a function that can be called to generate a bundled Windows installer based on a set of arguments versus something that only works as part of a build system like Maven. I think this is mistaken. Your piece of reusable code still needs to know enough about the build system used to build the bundled windows application. Sure, the maven plugins can't be used unless you also use maven itself, but the advantage is that you don't need to configure the plugin to work with the build system... That's automatic. You could always write a maven plugin that invokes your function and configures it properly for the maven build in question. The point still remains that anyone using maven need not care about those details, as they're the plugin's responsibility. No, compilation should not be included. You mention make; it is a macro language, dependency graph walker, shell executor and up-to-dateness checker. It doesn't do any compilation. It's very bare bones. It's not at all perfect but it's much closer to what I want from a build system than something like Maven. Again, I think this is mistaken. Make alone, as you describe it, is *not* a build system. You have to do lots of manual work to make your application build if you use plain make, most of which a system like maven can do for you, since it's configured declaratively. With maven, you don't usually tell it what to do, you need to tell it what you want; and I think that is how a build system should be. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Hello Brian Carper at Thu, 25 Mar 2010 15:17:10 -0700 (PDT) wrote: BC On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. BC Ruby: gem install X BC Perl: perl -MCPAN -e shell, then install X BC Why does building and installing dependencies have to be harder than BC this? Lein right now tries to fill this niche of being braindead easy BC to use, and comes pretty close. I realize Maven does a lot more than BC build and install dependencies, but for some of us, that's all we want BC out of life, and it's pretty nice when it's that easy to do so. Maven is good because of many plugins written for it. I know some peoples who are using maven to build projects written in mix of erlang, flash, etc. I use maven to automatically generate installers using izpack plugin, for example. May be we'll need to provide better documentation for work with Clojure from maven. -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://alexott.net http://alexott-ru.blogspot.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 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I often want to add a custom task to a build, just as an example, I might want to call a Java method in my code after it has built which will generate a property file to be included in the distribution. If this was just a make file or some sort batch file, then that would just be an extra line in the build file. In ant, yeah, it would be padded out with lots of XML, but it would still be the addition of a fairly simple ant task. In leiningen, it seems that I can create a leiningen/*.clj file with a clojure function in it which will call my task. In Maven, it seems that I have to go through this procedure? http://maven.apache.org/guides/plugin/guide-java-plugin-development.html ... creating a Java class, annotating it with metadata, creating an XML manifest file for it, packaging it in a jar file, installing it in the local maven repository, referring to it from the project's pom. Is it really that complicated? -- Dave -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
2010/3/26 David Powell djpow...@djpowell.net: I often want to add a custom task to a build, just as an example, I might want to call a Java method in my code after it has built which will generate a property file to be included in the distribution. If this was just a make file or some sort batch file, then that would just be an extra line in the build file. In ant, yeah, it would be padded out with lots of XML, but it would still be the addition of a fairly simple ant task. In leiningen, it seems that I can create a leiningen/*.clj file with a clojure function in it which will call my task. In Maven, it seems that I have to go through this procedure? http://maven.apache.org/guides/plugin/guide-java-plugin-development.html ... creating a Java class, annotating it with metadata, creating an XML manifest file for it, packaging it in a jar file, installing it in the local maven repository, referring to it from the project's pom. Is it really that complicated? Maybe, so you could do this once and for all by writing the missing plugin which can take as an argument a command line, or best, which can take as an argument the name of a clojure script to play ? :-) And maybe contribute this to maven-clojure-plugin ? :-) -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Hi, On Mar 25, 11:17 pm, Brian Carper briancar...@gmail.com wrote: Ruby: gem install X Perl: perl -MCPAN -e shell, then install X Why does building and installing dependencies have to be harder than this? I think you got this backwards. With maven, ant (ie. Ivy), gradle and leiningen this similar easy to do. Just add the dependency to your configuration file. What is complicated about maven, ant (ie. Ivy), gradle and leiningen (in various degrees) is the other part: the build process itself. And this isn't solved by gems, easy_install or CPAN neither. (configure scripts, native compilation problems (esp. on Windows), ) Sincerely Meikel -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 26, 2010, at 5:35 AM, David Powell wrote:
I often want to add a custom task to a build, just as an example, I
might want to call a Java method in my code after it has built which
will generate a property file to be included in the distribution.
If this was just a make file or some sort batch file, then that would
just be an extra line in the build file.
In ant, yeah, it would be padded out with lots of XML, but it would
still be the addition of a fairly simple ant task.
In leiningen, it seems that I can create a leiningen/*.clj file with a
clojure function in it which will call my task.
In Maven, it seems that I have to go through this procedure?
http://maven.apache.org/guides/plugin/guide-java-plugin-development.html
Is it really that complicated?
No. :-)
If you're looking to simply run a function after the build, if you're
using maven, then you can either use the exec plugin (which can invoke
any command line you like, or start up java with any options you want
-- including all of your build and/or test dependencies, or not).
If you're looking to run a clojure script, clojure-maven-plugin has a
'run' goal that is a thin wrapper around the exec plugin's
functionality. Thus, here's a chunk our of one of our pom.xml files
that runs a script during the compile phase to generate a file we
include in our .war file (we have others that run in other phases,
such as to prep and tear down databases around functional tests, etc):
execution
idgenerate-design-doc-json/id
phasecompile/phase
goals
goalrun/goal
/goals
configuration
script${basedir}/src/main/clojure/com/snowtide/couchdb.clj/
script
argsassemble-ddoc-json/args
clojureOptions-Ddb.dir=databases -Ddb.assembly.target=$
{project.build.directory}/classes//clojureOptions
/configuration
/execution
Certainly, this is not something that requires creating a new plugin
-- just re-using the entry points that are there already.
... creating a Java class, annotating it with metadata, creating an
XML manifest file for it, packaging it in a jar file, installing it in
the local maven repository, referring to it from the project's pom.
Now, it *would* be nice, when it's really called for, to be able to
create a maven plugin using clojure. The API is just a pile of
interfaces, so it's fundamentally the same as implementing any other
Java API. As for having to package it -- if you're using maven,
that's trivial. ;-) (And a good thing to do regardless, so as to,
again, promote reuse.)
Cheers,
- Chas
--
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
To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or
reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 26, 2010, at 4:33 AM, Jarkko Oranen wrote: No, compilation should not be included. You mention make; it is a macro language, dependency graph walker, shell executor and up-to-dateness checker. It doesn't do any compilation. It's very bare bones. It's not at all perfect but it's much closer to what I want from a build system than something like Maven. Again, I think this is mistaken. Make alone, as you describe it, is *not* a build system. You have to do lots of manual work to make your application build if you use plain make, most of which a system like maven can do for you, since it's configured declaratively. With maven, you don't usually tell it what to do, you need to tell it what you want; and I think that is how a build system should be. I would add to this that Maven, if one wants to be (IMO) pedantic about it, isn't a build system at all -- it's a shell that includes the bits needed for dependency resolution and command execution. Everything else comes down as plugins (which is where the hyperbole comes in about maven downloading the internet). Of course, everyone uses it as a build system, just like everyone uses make as a build system. Cheers, - Chas -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 7:33 AM, Chas Emerick cemer...@snowtide.com wrote: Now, it *would* be nice, when it's really called for, to be able to create a maven plugin using clojure. The API is just a pile of interfaces, so it's fundamentally the same as implementing any other Java API. As for having to package it -- if you're using maven, that's trivial. ;-) (And a good thing to do regardless, so as to, again, promote reuse.) Cheers, - Chas FWIW, this is trivial with Leiningen. Another reason I won't be moving to a Maven setup until things are further along there. If the legwork is done to make Maven fun to use when hacking on Clojure, people will use it. Keyword fun. David -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 26, 2010, at 10:18 AM, David Nolen wrote: Now, it *would* be nice, when it's really called for, to be able to create a maven plugin using clojure. The API is just a pile of interfaces, so it's fundamentally the same as implementing any other Java API. As for having to package it -- if you're using maven, that's trivial. ;-) (And a good thing to do regardless, so as to, again, promote reuse.) Cheers, - Chas FWIW, this is trivial with Leiningen. Another reason I won't be moving to a Maven setup until things are further along there. If the legwork is done to make Maven fun to use when hacking on Clojure, people will use it. Keyword fun. AFAICT, the situation is exactly the same, except maven has a Java API whereas lein is pure-clojure. I hope implementing a Java API isn't considered legwork. ;-) - Chas -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On 25 March 2010 22:17, Brian Carper briancar...@gmail.com wrote: On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. Agreed. I know next to nothing about maven, other than it scared me back in my java days. It seems at first glance to be pretty impenetrable (at least in terms of how it is documented), and that's not say that I wasn't blown away by Chas's screencast. I'd certainly consider maven now or at least try it when my projects get bigger and require more than lein has to offer. Is there not an analogy to be drawn here between labrepl and lien? It seems both are targetted at being approachable to Clojure beginners (and in the case of lein small projects). labrepl isn't aiming to be the environment you run complex clojure projects with, and in the same way it seems that at some point you might want to migrate from lein to maven. I'd assumed that migrating a lein based project to a maven one (if required) would be as simple as running: $ lein pom Then when you're ready you can rm project.clj and just tweak your pom.xml for a pure maven build. If this is the case then lein seems to allow people to delay learning maven, which is a complex or at least daunting moving part in a complex environment. Not something you want to have to learn or adopt whilst straining to understand Clojure. Maven seems to be a polarising tool, some people love it and others hate it... This much we know. So anything we can do to prevent clojure being tarnished by the maven haters, the better. lein seems to be a good step in this direction, and is possibly even a gentle introduction to maven for those wishing (or requiring) to make the jump. Is it possible for us as a community to agree on this much? R. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I'm not familiar with labrepl (except by name), but I think this is *exactly* right, as long as people do realize that maven is the next natural step from lein as soon as they have build requirements beyond running repls and maybe wrapping up a jar. Insofar as any higher- level tool provides UIs (text and script-based, like lein and other clojure build tools, or graphical, as with the NetBeans maven UI) that people are happy with, I think they're fabulous. I only take issue with the reimplementation of functionality that is otherwise ready-at- hand and any barriers that might be erected that prevent interoperability and collaboration. A semi-final thought: Clojure is a JVM language. This fact is inescapable, and implies a lot of things (for good, and very, very occasionally, for ill). One implication IMO is that we should collectively aim to cooperate, collaborate, and interoperate with the rest of the JVM world, for our own benefit as well as for our neighbors'. We gain a lot by being able to develop on and deploy to the JVM, and like any other software community, part of the culture has to do with how software is built, deployed, and managed. This is all completely orthogonal to the utility of Clojure as a programming language, and is a predominantly social concern. Most of us already know the relative joy that comes with being able to drop our Clojure- based application off in a client or customer's hands as a jar or war file, without the consternation or difficulties that might ensue if Clojure were a platform-less island. There's a great deal of currency that also comes with being able to hand a project that contains Clojure code off to another JVM developer and have confidence that they'll be able to build, configure, and deploy that project without special intervention using tools they're familiar with. That's a win for Clojure, and therefore very much in our interest. A P.S. on that thought is that I'd expect ClojureCLR projects to use whatever it is they use in .NET-land for building, configuring, and deploying projects and applications, for all the same reasons. Cheers, - Chas On Mar 26, 2010, at 11:13 AM, Rick Moynihan wrote: On 25 March 2010 22:17, Brian Carper briancar...@gmail.com wrote: On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. Agreed. I know next to nothing about maven, other than it scared me back in my java days. It seems at first glance to be pretty impenetrable (at least in terms of how it is documented), and that's not say that I wasn't blown away by Chas's screencast. I'd certainly consider maven now or at least try it when my projects get bigger and require more than lein has to offer. Is there not an analogy to be drawn here between labrepl and lien? It seems both are targetted at being approachable to Clojure beginners (and in the case of lein small projects). labrepl isn't aiming to be the environment you run complex clojure projects with, and in the same way it seems that at some point you might want to migrate from lein to maven. I'd assumed that migrating a lein based project to a maven one (if required) would be as simple as running: $ lein pom Then when you're ready you can rm project.clj and just tweak your pom.xml for a pure maven build. If this is the case then lein seems to allow people to delay learning maven, which is a complex or at least daunting moving part in a complex environment. Not something you want to have to learn or adopt whilst straining to understand Clojure. Maven seems to be a polarising tool, some people love it and others hate it... This much we know. So anything we can do to prevent clojure being tarnished by the maven haters, the better. lein seems to be a good step in this direction, and is possibly even a gentle introduction to maven for those wishing (or requiring) to make the jump. Is it possible for us as a community to agree on this much? R. -- 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 To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- You received this message because you are subscribed to the Google Groups Clojure
Re: Choosing a Clojure build tool
On Mar 25, 7:55 pm, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Read on:http://muckandbrass.com/web/x/AgBV The article reads to me as, don't reinvent the wheel, everyone should use maven. Personally I disagree with this because maven configuration is much harder than it needs to be. About an hour ago I had to add the hierarchy, executions/execution/goals/goal to a pom.xml file and found it needlessly tedious and wholly dependent on copy and pasting from a webpage. I also don't think it is necessary to choose a single build tool. I've used different ones at various times. Leiningen works for me, is easy to understand and extend, and interoperates well with maven -- everyone using clojure could standardise on leiningen and my existing maven builds would still work. I also have a small bit of code using ant/ivy and that would build fine too in a leingingen only world. Saul -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 25, 3:42 pm, Chas Emerick cemer...@snowtide.com wrote: I'm not entirely sure what would be required from clojure-maven-plugin (for example) for maven to achieve greater acceptance in the community... I think all it takes is getting the word out. Ease of use matters to me, but sexp vs. XML or simple interface vs. complex is only one part of ease of use. Another part is community support and availability of documentation. It's easy to learn any tool when lots of people are using it and writing about it. Your article was enough to convince me and apparently a few others to give Maven a chance. If a section appeared on clojure.org called Installing clojure and clojure-contrib via Maven with a sample POM and simple instructions for starting a REPL, that'd probably help. Is build.clojure.org linked to from anywhere on clojure.org? I only know about it from your blog post and from having read through IRC logs, and it's mentioned in the clojure-contrib README but there's no example of how to use it. Your article is the first I've seen Clojure installed directly via Maven. --Brian -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 10:31 AM, Saul Hazledine shaz...@gmail.com wrote: The article reads to me as, don't reinvent the wheel, everyone should use maven. Personally I disagree with this because maven configuration is much harder than it needs to be. I think there's a misconception that's been spread that since Leiningen is written in Clojure, it's a break from the existing ecosystem. In truth Leiningen is mostly just a wrapper around Stuart Halloway's Lancet library (to use ant tasks) and the maven-ant-tasks library that provides dependency management. There are a few tasks that are implemented from scratch like clean because it's so trivial or compile, new, and test because they're Clojure-specific, but the rest of them rely on existing implementations. For the record, Leiningen is currently around 700 lines of code and was basically feature-complete after two weeks of evening and weekend work. It is true that projects that need to produce output that's more complicated than a jar or uberjar right now aren't served well by Leiningen out of the box, but that's simply because my own needs haven't included that and I haven't gotten to it yet, not because I believe that relying on ant or maven APIs is icky somehow. Some people have taken steps towards reimplementing this in pure-Clojure, and that may or may not be wise depending on the trade-off of how much time it takes to implement vs how much time it would take to leverage an existing solution. Ant tends to have the advantage over Maven in that case because Maven's dependency injection framework makes it rather hostile to call out to from Clojure, but the Ant ecosystem is rich enough that it should provide enough for most projects. -Phil -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I'm now using polyglot maven for a project in both NetBeans/Enclojure and
Intellij/LaClojure. The pom.clj for one of my subprojects looks like this:
--
(defproject main com.linkuistics.lamdras:website:1.0-SNAPSHOT
:model-version 4.0.0
:name Lamdras Website
:description Acumen / LRMDS Integration
:packaging war
:properties {:project.build.sourceEncoding UTF-8}
:dependencies [[ring:ring-servlet:0.2.0-RC2]
[ring:ring-devel:0.2.0-RC2]
[clj-routing:clj-routing:0.1.0-SNAPSHOT]
[clout:clout:0.2.0-SNAPSHOT]
[compojure:compojure:0.4.0-SNAPSHOT]
[hiccup:hiccup:0.1.0-SNAPSHOT]
[org.clojure:clojure:1.2.0-master-SNAPSHOT]
[org.clojure:clojure-contrib:1.2.0-master-SNAPSHOT]
[congomongo:congomongo:0.1.2-SNAPSHOT]
[jline:jline:0.9.94]]
:provided-dependencies [[org.mortbay.jetty:servlet-api-2.5:6.1.14]]
:final-name website
:plugins [[org.apache.maven.plugins:maven-war-plugin:2.1-beta-1]
[org.apache.maven.plugins:maven-compiler-plugin:2.1
{:configuration {:source 1.6 :target 1.6}}]
[com.theoryinpractise:clojure-maven-plugin:1.3.1 {:executions
[{:id compile-clojure :phase compile :goals [compile]}]}]
[org.mortbay.jetty:maven-jetty-plugin:6.1.10 {:configuration
{:scanIntervalSeconds 10 :stopKey foo :stopPort }}]])
--
which isn't at all painful. It's early days yet, and neither IDE picks up the
pom.clj, so I have to run the translator to get a pom.xml, but that's trivial -
the command to produce pom.xml from pom.clj (and the translation is
bidirectional) is this:
translate pom.clj newpom.xml
assuming the polyglot maven translate command is on your path. Note that you
can use either maven 2 or 3 to run the resultant pom.xml.
You can use either declarative or imperative code in the pom.clj i.e. you can
call methods on the pom's object model to build up a project definition, which
you can then run using polyglot maven or translate to a pom.xml which can then
be run.
Antony Blakey
-
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
On the other side, you have the customer and/or user, and they tend to do what
we call automating the pain. They say, What is it we're doing now? How would
that look if we automated it? Whereas, what the design process should properly
be is one of saying, What are the goals we're trying to accomplish and how can
we get rid of all this task crap?
-- Alan Cooper
--
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
To unsubscribe from this group, send email to
clojure+unsubscribegooglegroups.com or reply to this email with the words
REMOVE ME as the subject.
Choosing a Clojure build tool
I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Read on: http://muckandbrass.com/web/x/AgBV Feedback welcome, either here or in the comments on the post. Cheers, - Chas -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Chas Emerick cemer...@snowtide.com writes: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Read on: http://muckandbrass.com/web/x/AgBV Feedback welcome, either here or in the comments on the post. No, XML is not the worst thing (at least for me). The real problem is here: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Let's suppose that from time to time I'd like to package a few class files (e.g. Java subpackage) to jar without repeated compilation and without running tests of the whole project? How to do that with Maven? It should be easy, right? Are you sure that it is a no-brainer? Br, Rob -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Ruby: gem install X Perl: perl -MCPAN -e shell, then install X Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. My dream tool would be: 1) Platform-agnostic (for us sorry souls stuck on Windows at work) 2) IDE-agnostic (make a Netbeans project is great, but Emacs users need some love too) 3) Easy to understand and use for the kinds of tasks Lein covers (I don't want to have to study a Maven book(!) if I can avoid it) 4) Able to handle most or all Clojure and Java libraries I want to install (I don't want to have to circumvent the build tool and do things manually if I can help it) 5) Able to easily browse or search for packages in remote repositories, would be nice Rubygems and Perl's CPAN can handle those kinds of things, for example. If Maven can be those things, I'll have an XML sandwich for lunch with a smile if necessary. : ) Maybe it can and the community just needs to standardize around Maven and provide good documentation and community support for using it with Clojure. I just hope the community standardizes around something; any standard is better than everyone using a different tool. Thanks --Brian -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 25, 2010, at 6:08 PM, Rob Wolfe wrote: No, XML is not the worst thing (at least for me). The real problem is here: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html I'm not sure what you're referring to there. :-) Let's suppose that from time to time I'd like to package a few class files (e.g. Java subpackage) to jar without repeated compilation and without running tests of the whole project? How to do that with Maven? It should be easy, right? Are you sure that it is a no-brainer? You can disable all tests in a maven build with the - Dmaven.test.skip=true option. No compilation will occur if no changes have been made to your source files. - Chas -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Mar 25, 2010, at 19:55 , Chas Emerick wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. I slowly get the feeling that build tools are too much in the focus. Why don't we start up with a good shell integration, being able to run clj my script go nice and including dependencies in jars and stuff. Making it easy to work with plain .clj files to include, load, run them would get us a huge way ahead and I think kind of freeing us from what I feel as the burden of the java world. Regards, Heinz -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Brian, FWIW, I'd claim that maven does deliver on all five points you list. Of note is that it absolutely is IDE-agnostic (I used NetBeans in the screencast because that's what I use -- you can load up maven-defined projects in Eclipse and IntelliJ just as easily). I'm not an emacs user, so I'm unsure what love would mean there, but I'd be surprised if there wasn't a maven mode somewhere, etc. The package browsing/searching story is probably the weakest. There's http://mvnrepository.com , which I just found 2 minutes ago. We have an internal Nexus installation (which caches all of the dependencies we've ever retrieved, so that our builds won't fail if the 'net is down, maven central is down, build.clojure.org is down, etc), which provides a very nice search interface. I'm not entirely sure what would be required from clojure-maven-plugin (for example) for maven to achieve greater acceptance in the community...as I mentioned, I'm relatively new to maven myself (~ 6 months in), and I paved the rough spots that I hit, but it's hard to speculate because people's workflows and specific requirements are so different. My guess is that once the Clojure-flavored Polyglot Maven project becomes fully-baked, it will become the de facto standard, as XML allergies really are the biggest deterrent right now IMO. Cheers, - Chas On Mar 25, 2010, at 6:17 PM, Brian Carper wrote: On Mar 25, 11:55 am, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Ruby: gem install X Perl: perl -MCPAN -e shell, then install X Why does building and installing dependencies have to be harder than this? Lein right now tries to fill this niche of being braindead easy to use, and comes pretty close. I realize Maven does a lot more than build and install dependencies, but for some of us, that's all we want out of life, and it's pretty nice when it's that easy to do so. My dream tool would be: 1) Platform-agnostic (for us sorry souls stuck on Windows at work) 2) IDE-agnostic (make a Netbeans project is great, but Emacs users need some love too) 3) Easy to understand and use for the kinds of tasks Lein covers (I don't want to have to study a Maven book(!) if I can avoid it) 4) Able to handle most or all Clojure and Java libraries I want to install (I don't want to have to circumvent the build tool and do things manually if I can help it) 5) Able to easily browse or search for packages in remote repositories, would be nice Rubygems and Perl's CPAN can handle those kinds of things, for example. If Maven can be those things, I'll have an XML sandwich for lunch with a smile if necessary. : ) Maybe it can and the community just needs to standardize around Maven and provide good documentation and community support for using it with Clojure. I just hope the community standardizes around something; any standard is better than everyone using a different tool. Thanks --Brian -- 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 To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Thu, Mar 25, 2010 at 6:17 PM, Brian Carper briancar...@gmail.com wrote: Ruby: gem install X Perl: perl -MCPAN -e shell, then install X If you're just installing CPAN module X, then on most installations all you need to run is this: cpan X You can still go into the interactive shell if you want, usually by just running cpan with no args. You don't have to do that to install a module, but if you need to find a module whose exact name you don't know, or if a module fails to build and you want to poke around the build tree, etc, the cpan shell is handy. And other languages have their own flavors - PHP has PEAR/PECL, while Python is trying to get there with PyPI, but it's not quite there yet. The problem with CPAN is that many modules require compiling native code (C in this case), which means that just running cpan won't work if you don't have C dev tools installed. You can often get modules with prebuilt binaries, but the mechanism is platform-dependent. For instance, each module is its own apt package for Debian/Ubuntu, while ActivePerl on Windows uses its own Perl Package Manager (ppm.exe). -- Mark J. Reed markjr...@gmail.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 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
I am in complete agreement! Clojure continues to hinder itself by not providing an official executable. java -cp clojure.jar was good enough for Clojure 0.9, but that's not where it is anymore. Even simple things like submitting bug reports would be helped by having a default clj executable. It would avoid a lot of questions about system configuration when reporting a bug. So many people and projects have RE-implemented a clj script! Seth On Mar 25, 5:32 pm, Heinz N. Gies he...@licenser.net wrote: On Mar 25, 2010, at 19:55 , Chas Emerick wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. I slowly get the feeling that build tools are too much in the focus. Why don't we start up with a good shell integration, being able to run clj my script go nice and including dependencies in jars and stuff. Making it easy to work with plain .clj files to include, load, run them would get us a huge way ahead and I think kind of freeing us from what I feel as the burden of the java world. Regards, Heinz -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
For whats it worth here - IntelliJ IDEA will automatically add maven dependencies to you pom.xml file for unknown classes ( in java source, not the clojure plugin - yet), for example if you type com.cemerick.Foo in your source, and its an unknown class, the intention dialog gives you options of create class or search maven, it then gives you a list of artifacts containing that class for you to add to pom.xml. Woud be nice having that in the La Clojure plugin as well. -- Pull me down under... On Fri, Mar 26, 2010 at 11:42 AM, Chas Emerick cemer...@snowtide.comwrote: The package browsing/searching story is probably the weakest. There's http://mvnrepository.com, which I just found 2 minutes ago. We have an internal Nexus installation (which caches all of the dependencies we've ever retrieved, so that our builds won't fail if the 'net is down, maven central is down, build.clojure.org is down, etc), which provides a very nice search interface. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
One of the weirdest things coming to the Java world is to witness what strange things people take for granted should be in the build tool. All the example features you mention in your article are convenient, but I don't see why they belong in the build tool. They should be completely separate pieces of functionality that you happen to use the build tool to invoke. Why this obsession with integration and unified configuration? -Per On Fri, Mar 26, 2010 at 1:55 AM, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Read on: http://muckandbrass.com/web/x/AgBV Feedback welcome, either here or in the comments on the post. Cheers, - Chas -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Truly, maven is often referred to using various terms that are more expansive than build tool, as it aims to bring a degree of standardization and regularity to a variety of non-programming-related tasks associated with building, configuring, deploying, and releasing software. IIRC, even the simple notion of systematized dependency management was an alien notion in the JVM world until maven came around (which, if I have my timeline right, later inspired ivy due to shortcomings in maven v1?). I guess I would counter with: why would you want to reinvent your build/configuration/deployment practices for every project? Cheers, - Chas On Mar 26, 2010, at 12:33 AM, Per Vognsen wrote: One of the weirdest things coming to the Java world is to witness what strange things people take for granted should be in the build tool. All the example features you mention in your article are convenient, but I don't see why they belong in the build tool. They should be completely separate pieces of functionality that you happen to use the build tool to invoke. Why this obsession with integration and unified configuration? -Per On Fri, Mar 26, 2010 at 1:55 AM, Chas Emerick cemer...@snowtide.com wrote: I published a blog post earlier today, along with a short screencast that might be of interest: Like any group of super-smart programmers using a relatively new language, a lot of folks in the Clojure community have looked at existing build tools (the JVM space is the relevant one here, meaning primarily Maven and Ant, although someone will bark if I don't mention Gradle, too), and felt a rush of disdain. I'd speculate that this came mostly because of XML allergies, but perhaps also in part because when one has a hammer as glorious as Clojure, it's hard to not want to use it to beat away at every problem in sight. Read on: http://muckandbrass.com/web/x/AgBV Feedback welcome, either here or in the comments on the post. Cheers, - Chas -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- 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 To unsubscribe from this group, send email to clojure +unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
Re: Choosing a Clojure build tool
On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick cemer...@snowtide.com wrote: Because they're common processes that are ideally built once, and then reused with minor variation. Library reuse is generally considered to be a good thing in software development, so it strikes me as odd that many think that such practices should stop at the build's edge, as it were. Reuse is great. Integration tends to hamper reuse. To take one of your examples, if I want to bundle my classes and dependencies into a Windows installer, I will call a function in a library (or a command line program in the Unix world) that does that. That's it. It doesn't need to be part of the build system and shouldn't be. I can call functions in the build system to supply the relevant arguments. If the build tool and library is well designed, the added value of integration in this example should be infinitesimal. -Per -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
