FAQ
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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Sam Ritchie at Feb 10, 2014 at 3:36 pm
    Nice, this looks great! SBT has a great multi-module story; this was the
    only thing I've missed, moving back from Scala. Thank you!
    Jim Crossley February 10, 2014 7:36 AM
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    Sam Ritchie (@sritchie)
    Paddleguru Co-Founder
    703.863.8561
    www.paddleguru.com <http://www.paddleguru.com/>
    Twitter <http://twitter.com/paddleguru>// Facebook
    <http://facebook.com/paddleguru>

    --
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dgrnbrg at Feb 10, 2014 at 8:42 pm
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jim Crossley at Feb 10, 2014 at 10:31 pm
    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 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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jim Crossley at Feb 10, 2014 at 10:54 pm
    I didn't communicate this as well as I would've liked, probably due to
    overloaded terminology.

    The contrived example multi-module "project" would generate 3 artifacts.
    And the source code for those artifacts would be contained within 3
    Leiningen "projects", which I refer to as "modules" to avoid the confusion
    of also identifying the git repo as a "project".

    So one git repo, identified as a conceptual project, would be organized as
    3 Leiningen projects, aka "modules".

    I hope I didn't make things worse,
    Jim
    On Monday, February 10, 2014 5:31:27 PM UTC-5, Jim Crossley wrote:

    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 <dsg123...@gmail.com<javascript:>
    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 clo...@googlegroups.com<javascript:>
    Note that posts from new members are moderated - please be patient with
    your first post.
    To unsubscribe from this group, send email to
    clojure+u...@googlegroups.com <javascript:>
    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+u...@googlegroups.com <javascript:>.
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupclojure @
categoriesclojure
postedFeb 10, '14 at 2:36p
activeFeb 10, '14 at 10:54p
posts5
users4
websiteclojure.org
irc#clojure

People

Translate

site design / logo © 2022 Grokbase