Or you can help out with Polyglot Maven for which there is preliminary Clojure support:
http://github.com/sonatype/polyglot-maven/blob/master/pmaven-clojure/src/test/resources/org/sonatype/maven/polyglot/clojure/test1.clj I've tried to put the infrastructure in place in Maven to use dynamic languages. Mark Derricut has taken the time to try and implement something with Clojure. The Polyglot Maven work is meant to be more then a simple dynamic language representation of the POM. Polyglot Maven is meant to provide complete access to Maven's internals in ways that may potentially alter the way Maven works by default. From an interoperability perspective this may not be ideal from a purely Maven POV, but will allow dynamic language folks to leverage the existing infrastructure and tools which are likely to be used for quite a while. We have working implementations for Ruby, Groovy, Scala and Clojure and I'm happy to help anyone expand the support for Clojure. I think leveraging Maven's existing infrastructure either through the existing plugins or by trying to help expand the Clojure support in Polyglot Maven is likely to serve you better in long run. I think it's the ideal hybrid and compromise. You can use Clojure as you wish, because really anyone here can change/improve the implementation at this point, and benefit from the existing tooling. There are a few places in the Maven ecosystem where XML got hardcoded but this is almost entirely in plugins, and one fragment in a configuration type system. Maven was designed to be model source agnostic and language agnostic. XML is not hardcoded anywhere in the internals and Polyglot Maven displays this fact well. Even in Maven 2.x this wasn't that hard to use a different model source but is not as easy as it is with Maven 3.x, and Maven 3.x goes further with an API was designed for embedding. Maven 3.x is more of a library then a tool now. Ultimately I don't care what anyone uses to build. Use what works for you, but it would be a shame to lose repository interoperability to tools that insist on rewriting the existing infrastructure. People always underestimate infrastructure and there's a lot that can be leveraged in Maven. Maybe you don't like XML but that is the front-end of Maven which is completely decoupled from the core. Things like Leinigen seem to be going the right way using existing tooling where possible because the metadata formats and repository APIs in Maven are advancing quickly. Sonatype has hired Pascal Rapicault who is the lead of the P2 project which is the provisioning and repository structure Maven is likely to use in the future. So reading the repository structures and metadata directly are likely to put you in a shit-out-of-luck situation in the future. Bottom line is that Maven will be around for a while, Maven repositories even longer and there's been a massive amount of work in Maven 3.x to help out the dynamic language folks. Jason van Zyl (The creator of Maven -- that won't be apologizing anytime soon you smart ass) On Mar 26, 4:33 am, Chas Emerick <[email protected]> wrote: > 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> > <id>generate-design-doc-json</id> > <phase>compile</phase> > <goals> > <goal>run</goal> > </goals> > <configuration> > <script>${basedir}/src/main/clojure/com/snowtide/couchdb.clj</ > script> > <args>assemble-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 [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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.
