Using the decomposition I made earlier, I would refine my analysis a bit further and say: - the original problem lies mostly within the programming model: it's about resolving dependencies when reusing and composing deployable units, and how to avoid complexity and conflicts. - part of the problem also lies within the runtime model: as of yet Clojure core is not expressive enough to support the use of two versions of the same library at runtime. - the proposed solution belongs to the design paradigm: some form of heuristics on the number of dependencies, copying code, and the sense of having some sort of layer of utility libraries. So in fact the problem and proposed solution were already spread across all these domains to start with. Let's continue with more facts while summarizing what's already been discussed: - there is a difference between managing and resolving dependencies during development, and doing the same for preparing deployable units; lein uberjar and google closure dependency management and compilation/minification are great examples. - talking about leingingen and automating code copying/renaming is searching for a solution within the programming model. - talking about classloaders and using different versions at runtime is searching for a solution within the runtime model. - the homoiconic and dynamic nature of Clojure means that programming and runtime models are intimately related: classes are generated and loaded at runtime, and dependencies can be resolved at runtime (e.g. pomegranate). - not everyone and every host language use leiningen, so the solution cannot be about leiningen only, but the latter can certainly facilitate the process of applying a solution.
If we were to organize possible solutions at each level: 1. design paradigm: what the original post proposed, i.e. heuristic on dependencies, manually copying code, and the sense of having some sort of layer of utility libraries. 2. programming model: automate the copying and/or re-namespacing of code during the creation of deployable units, e.g. some form of :copy/:copy-as directives within the ns form; and/or we could bring version specification into the ns form, although ns has no knowledge of deployment units, so some form of mapping needs to be done and/or we need some cross-platform reification of deployment units (e.g. some generalization of jars, wars, ears, osgi bundles, modules in jigsaw, minified scripts, etc.). 3. runtime model: depends largely on the host language: classloaders in java, jigsaw later, closure minification in clojurescript, but that's a programming model solution. I'm sure there's more. And a combination of all these solutions certainly makes sense. We can start at level 1 with the original proposed solution, but the pressure of moving into solutions at level 2 is already felt in this discussion. Moving into level 3 solutions later on should be the natural continuation, and that should be present in our minds while working on other levels. -- -- 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.
