Simplifying contrib build with Maven (really!)

6 views
Skip to first unread message

Stuart Sierra

unread,
Jan 20, 2010, 5:12:34 PM1/20/10
to cloju...@googlegroups.com, clojure-ma...@googlegroups.com
In the process of creating clojure-contrib 1.0 and 1.1 releases, I ran
into a lot of problems with the Ant-based build.

I decided to try building contrib with Maven instead. The result was
a much cleaner, easier build process.

Don't take my word for it, checkout the "maven" branch of contrib and
see for yourself.

To compile and build a JAR, type "mvn package".
To run tests, type "mvn test".
To build distribution zip/tar, run "mvn assembly:assembly".
To start a REPL, run "mvn clojure:repl"

Generated files (JAR, zip, tar, ...) will be in the target/ directory.

Here are the benefits of using Maven:
1. No need to specify path to clojure.jar on command line.
2. Maven manages dependencies b/t contrib and clojure versions.
3. No need for a test driver script.
4. No logic needed to find/compile .clj sources.
5. Much simpler release/deployment process - "mvn deploy"
6. Easier version management for tools like lein.
7. The pom.xml is 87 lines; build.xml was 206 lines

There are some differences in the directory structure. There are now
3 main source directories:
src/main/clojure -- library sources
src/test/clojure -- test sources
src/examples/clojure -- example code

I would like to move to this exclusively Maven-based build for
clojure-contrib. Please consider it and let me know your thoughts.

-Stuart Sierra

Sean Devlin

unread,
Jan 20, 2010, 5:23:20 PM1/20/10
to cloju...@googlegroups.com
Why not lein?

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To post to this group, send email to cloju...@googlegroups.com.
To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.




Stuart Sierra

unread,
Jan 20, 2010, 5:33:41 PM1/20/10
to Clojure Dev
On Jan 20, 5:23 pm, Sean Devlin <francoisdev...@gmail.com> wrote:
> Why not lein?

Circularity. lein depends on clojure-contrib.

-SS

Meikel Brandmeyer

unread,
Jan 20, 2010, 5:50:05 PM1/20/10
to cloju...@googlegroups.com
Hello Stuart,

Am 20.01.2010 um 23:12 schrieb Stuart Sierra:

> I decided to try building contrib with Maven instead. The result was
> a much cleaner, easier build process.

I must confess I haven't looked at your proposal, yet. But I have a quick question: is the build still monolithic? I avoid depending on contrib partly because I have to get a huge blob for just c.c.def or c.c.condition.

Do you tackle this issue with your rework?

Sincerely
Meikel

Chas Emerick

unread,
Jan 20, 2010, 9:36:42 PM1/20/10
to cloju...@googlegroups.com, clojure-ma...@googlegroups.com

On Jan 20, 2010, at 5:12 PM, Stuart Sierra wrote:

> In the process of creating clojure-contrib 1.0 and 1.1 releases, I ran
> into a lot of problems with the Ant-based build.
>
> I decided to try building contrib with Maven instead. The result was
> a much cleaner, easier build process.

+1, all the way. Thanks, Stuart!

- Chas

Stuart Sierra

unread,
Jan 21, 2010, 9:16:40 AM1/21/10
to Clojure Dev
On Jan 20, 5:50 pm, Meikel Brandmeyer <m...@kotka.de> wrote:
> But I have a quick question: is the build still monolithic?

Yes, the build is still monolithic. That's a whole separate issue
that I would like to tackle in the future.

-SS

Meikel Brandmeyer

unread,
Jan 21, 2010, 5:13:09 PM1/21/10
to cloju...@googlegroups.com
Hi,

I worked on this previously in my Ivy branch. The basic idea was to generate ivy.xmls from a central script and then simply make a multiproject build with ant. Maybe it can serve as a starting point. I don't know how maven handles this, though.

By now, I would expect things to terribly out of date, but anyway...

Setup of subprojects:
http://github.com/kotarak/clojure-contrib/blob/ivy-dependency-management/build+ivy.xml

Generation script:
http://github.com/kotarak/clojure-contrib/blob/ivy-dependency-management/gen-modules.clj

Sincerely
Meikel

Stuart Sierra

unread,
Jan 22, 2010, 9:56:23 AM1/22/10
to Clojure Dev
On Jan 21, 5:13 pm, Meikel Brandmeyer <m...@kotka.de> wrote:
> Generation script:http://github.com/kotarak/clojure-contrib/blob/ivy-dependency-managem...

Manual dependencies - yikes! I'm impressed you made that work, but I
don't think it's a sustainable model.

Here's hoping that tools continue to mature -- clojure-maven-plugin,
Leiningen, Clojars, and maybe someday Maven 3.

-SS

Stuart Halloway

unread,
Jan 24, 2010, 2:53:07 PM1/24/10
to cloju...@googlegroups.com
+1, let's do this. I am not a huge fan of maven, but (a) conventions
are good, even when they aren't, and (b) when in Rome and all that.

Stu

Meikel Brandmeyer

unread,
Jan 25, 2010, 3:33:57 AM1/25/10
to Clojure Dev
Hi,

On Jan 22, 3:56 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote:

> Manual dependencies - yikes!  I'm impressed you made that work, but I
> don't think it's a sustainable model.
>
> Here's hoping that tools continue to mature -- clojure-maven-plugin,
> Leiningen, Clojars, and maybe someday Maven 3.

How do you want to change the manual deps handling? You cannot derive
from a namespace name in which package it is (and I'm not sure I want
to hard-wire rules for that). Let alone extracting the information
what namespaces are used. Rich clearly is not interested in this
problem, so situation won't get easier for the developer (and the
tools).

Most work is already done: as you said I made it work. This doesn't
change everyday. Keeping it now up to date should not really be a
problem. (Using maven instead of ant+ivy is a one time job.) I'll give
it a try and update my branch to work with gradle and clojuresque.
That should even remove the need for build.xml & friends generation.

Sincerely
Meikel

Stuart Sierra

unread,
Jan 25, 2010, 10:24:10 AM1/25/10
to Clojure Dev
On Jan 25, 3:33 am, Meikel Brandmeyer <m...@kotka.de> wrote:
> How do you want to change the manual deps handling?

I'm not much interested in splitting contrib into separate projects.
The clojure.lib effort seems more useful.

-SS

Meikel Brandmeyer

unread,
Jan 25, 2010, 2:19:57 PM1/25/10
to cloju...@googlegroups.com
Hi,

Am 25.01.2010 um 16:24 schrieb Stuart Sierra:

> I'm not much interested in splitting contrib into separate projects.
> The clojure.lib effort seems more useful.

I appreciate clojure.lib! This is a good effort to get the more often used modules into a form which is more tolerable. Why do I have to suck in datalog, dataflow, monads, generics, pprint,... if I just want c.c.condition? Even with clojure.lib a more modular contrib build would be useful.

Sincerely
Meikel

Stuart Halloway

unread,
Jan 25, 2010, 9:29:17 PM1/25/10
to cloju...@googlegroups.com
>> I'm not much interested in splitting contrib into separate projects.
>> The clojure.lib effort seems more useful.
>
> I appreciate clojure.lib! This is a good effort to get the more
> often used modules into a form which is more tolerable. Why do I
> have to suck in datalog, dataflow, monads, generics, pprint,... if I
> just want c.c.condition? Even with clojure.lib a more modular
> contrib build would be useful.

Rich wants both of these things: (1) clojure.lib and (2) a more
modular contrib build. An important part of both efforts will be
understanding intralib dependencies. Do any good tools exist for
tracking dependencies between libs? Such tools would themselves be a
welcome addition to contrib. Maybe one or more of the IDE plugins
could contribute code...

Stu

Laurent PETIT

unread,
Jan 26, 2010, 1:49:07 AM1/26/10
to cloju...@googlegroups.com
2010/1/26 Stuart Halloway <stuart....@gmail.com>:

I'd be happy to contribute ccw's dependency tracking system,
... if only it had one currently ;-)

>
> Stu

Stuart Sierra

unread,
Jan 26, 2010, 9:41:15 AM1/26/10
to Clojure Dev
On Jan 25, 9:29 pm, Stuart Halloway <stuart.hallo...@gmail.com> wrote:
> Do any good tools exist for tracking dependencies between libs?

Maven will do that if you split each lib into a separate module.
That's not difficult, just means lots of subdirectories.

-SS

Reply all
Reply to author
Forward
0 new messages