I've not used lein-voom, but from a brief glance at its README, it seems to be an attempt at solving "the SNAPSHOT problem", i.e. the nightmare of multiple interdependent projects living in different git repos all under active development by multiple collaborators.
The scope of lein-modules is smaller: it's about organizing your code within a single git repo. With lein-modules, you can organize it as interdependent Leiningen projects. For example, you might have a multi-module project that builds an bizbaz.war and another that builds an admin.war and another that builds the bizbaz.jar containing the business logic shared by the first two. So you clone their repo locally, containing all three "modules" each with its own project.clj, and you can either build 'em all in one shot from the root or just work on one at a time. Either way, your common config for all three is maintained in one place: the "parent" project.clj. Hope that helps, Jim On Mon, Feb 10, 2014 at 3:42 PM, dgrnbrg <dsg123456...@gmail.com> wrote: > Could you compare lein-modules with lein-voom? I can see that they have > different features, but I'm trying get a handle on when each might be > appropriate. > > This looks like a great tool for large projects. Thank you! > > > On Monday, February 10, 2014 9:36:13 AM UTC-5, Jim Crossley wrote: >> >> Maven multi-module projects provide support for project aggregation, >> letting you define parent-child relationships among a group of projects to >> achieve interdependence-based build ordering, limited project inheritance, >> and centralized dependency management. >> >> Maven's pom.xml files are verbose, error-prone, and just generally gross, >> especially for multi-module projects, so I wanted to see if I could provide >> the above features using Leiningen. The fruit of my labor thus far is this >> plugin: >> >> https://github.com/jcrossley3/lein-modules >> >> Project inheritance is achieved using Leiningen profiles. This is more >> flexible than Maven, where the values subject to inheritance are >> hard-coded. And profiles defined in your project's ancestors are activated >> appropriately for each task, as you would expect. >> >> Dependency management is a lot simpler, too: it's just a map of >> dependency symbols to version strings, from which your dependency specs are >> populated by Leiningen middleware. >> >> See the README for more details and an example. >> >> Love, >> Jim >> >> -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
