Simplifying contrib build with Maven (really!)
Stuart Sierra
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
--
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
> Why not lein?
Circularity. lein depends on clojure-contrib.
-SS
Meikel Brandmeyer
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
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
> 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
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
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
are good, even when they aren't, and (b) when in Rome and all that.
Stu
Meikel Brandmeyer
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
> 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
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
>> 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
I'd be happy to contribute ccw's dependency tracking system,
... if only it had one currently ;-)
>
> Stu
Stuart Sierra
> 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