benedekfazekas / mranderson Goto Github PK

View Code? Open in Web Editor NEW

151.0 151.0 14.0 203 KB

Dependency inlining and shadowing

License: Eclipse Public License 1.0

Java 13.98% Clojure 83.22% Shell 1.36% Mustache 0.69% Makefile 0.75%

mranderson's People

Contributors

Stargazers

Watchers

Forkers

expez typedclojure severeoverfl0w sumbach linpengcheng radicalzephyr cichli gaybro8777 liquidz pink-junkjard jarohen reducecombine lread r0man

mranderson's Issues

Error inlining cljfmt 0.7

I ran into the following problem when trying to release cider-nrepl 0.25.6:

lein with-profile +1.10,+plugin.mranderson/config deploy clojars
OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Compiling cider.nrepl.inlined-deps.cljfmt.v0v7v0.cljfmt.main
Syntax error macroexpanding at (diff.clj:1:1).
Execution error (ClassNotFoundException) at java.net.URLClassLoader/findClass (URLClassLoader.java:435).
cidernrepl0256.difflib.DiffUtils

It doesn't seem to be a regression in the most recent mranderson, as I got the same problem with the previous release as well. I've reverted to cljfmt 0.6.8, so I can release something but ideally we should fix this problem somehow.

You can easily reproduce this by running on the current master of cider-nrepl. I'm using JDK 14, but I'm not sure if that's relevant or the problem's there for every JDK.

Handle a version named "n/a" gracefully

When a given project's version is "n/a", mranderson will keep the "/", resulting in a head-scratching error related to imports:

Probably the / is safe to drop.

(As a workaround I ended up choosing 0.0.0 as a "n/a")

Cheers - V

fails with leiningen 2.6.0

clojure.lang.Compiler$CompilerException: java.lang.RuntimeException: Too many arguments to throw, throw expects a single Throwable instance, compiling:(mranderson/move.clj:106:5)
 at clojure.lang.Compiler.analyzeSeq (Compiler.java:6875)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler$IfExpr$Parser.parse (Compiler.java:2805)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6001)
    clojure.lang.Compiler$LetExpr$Parser.parse (Compiler.java:6319)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6001)
    clojure.lang.Compiler$FnMethod.parse (Compiler.java:5380)
    clojure.lang.Compiler$FnExpr.parse (Compiler.java:3972)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6866)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.access$300 (Compiler.java:38)
    clojure.lang.Compiler$DefExpr$Parser.parse (Compiler.java:589)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler.eval (Compiler.java:6931)
    clojure.lang.Compiler.load (Compiler.java:7379)
    clojure.lang.RT.loadResourceScript (RT.java:372)
    clojure.lang.RT.loadResourceScript (RT.java:363)
    clojure.lang.RT.load (RT.java:453)
    clojure.lang.RT.load (RT.java:419)
    clojure.core$load$fn__5677.invoke (core.clj:5893)
    clojure.core$load.invokeStatic (core.clj:5892)
    clojure.core$load.doInvoke (core.clj:5876)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.core$load_one.invokeStatic (core.clj:5697)
    clojure.core$load_one.invoke (core.clj:5692)
    clojure.core$load_lib$fn__5626.invoke (core.clj:5737)
    clojure.core$load_lib.invokeStatic (core.clj:5736)
    clojure.core$load_lib.doInvoke (core.clj:5717)
    clojure.lang.RestFn.applyTo (RestFn.java:142)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$load_libs.invokeStatic (core.clj:5774)
    clojure.core$load_libs.doInvoke (core.clj:5758)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$require.invokeStatic (core.clj:5796)
    clojure.core$require.doInvoke (core.clj:5796)
    clojure.lang.RestFn.invoke (RestFn.java:805)
    leiningen.source_deps$eval1023$loading__5569__auto____1024.invoke (source_deps.clj:1)
    leiningen.source_deps$eval1023.invokeStatic (source_deps.clj:1)
    leiningen.source_deps$eval1023.invoke (source_deps.clj:1)
    clojure.lang.Compiler.eval (Compiler.java:6927)
    clojure.lang.Compiler.eval (Compiler.java:6916)
    clojure.lang.Compiler.load (Compiler.java:7379)
    clojure.lang.RT.loadResourceScript (RT.java:372)
    clojure.lang.RT.loadResourceScript (RT.java:363)
    clojure.lang.RT.load (RT.java:453)
    clojure.lang.RT.load (RT.java:419)
    clojure.core$load$fn__5677.invoke (core.clj:5893)
    clojure.core$load.invokeStatic (core.clj:5892)
    clojure.core$load.doInvoke (core.clj:5876)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.core$load_one.invokeStatic (core.clj:5697)
    clojure.core$load_one.invoke (core.clj:5692)
    clojure.core$load_lib$fn__5626.invoke (core.clj:5737)
    clojure.core$load_lib.invokeStatic (core.clj:5736)
    clojure.core$load_lib.doInvoke (core.clj:5717)
    clojure.lang.RestFn.applyTo (RestFn.java:142)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$load_libs.invokeStatic (core.clj:5774)
    clojure.core$load_libs.doInvoke (core.clj:5758)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$require.invokeStatic (core.clj:5796)
    clojure.core$require.doInvoke (core.clj:5796)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    leiningen.core.utils$require_resolve.invokeStatic (utils.clj:89)
    leiningen.core.utils$require_resolve.invoke (utils.clj:82)
    leiningen.core.utils$require_resolve.invokeStatic (utils.clj:92)
    leiningen.core.utils$require_resolve.invoke (utils.clj:82)
    leiningen.core.main$lookup_task_var.invokeStatic (main.clj:68)
    leiningen.core.main$lookup_task_var.invoke (main.clj:64)
    leiningen.core.main$pass_through_help_QMARK_.invokeStatic (main.clj:78)
    leiningen.core.main$pass_through_help_QMARK_.invoke (main.clj:72)
    leiningen.core.main$task_args.invokeStatic (main.clj:81)
    leiningen.core.main$task_args.invoke (main.clj:80)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:327)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
    leiningen.do$do.invokeStatic (do.clj:40)
    leiningen.do$do.doInvoke (do.clj:32)
    clojure.lang.RestFn.invoke (RestFn.java:486)
    clojure.lang.Var.invoke (Var.java:401)
    clojure.lang.AFn.applyToHelper (AFn.java:171)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$partial_task$fn__5837.doInvoke (main.clj:272)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$apply_task.invokeStatic (main.clj:322)
    leiningen.core.main$apply_task.invoke (main.clj:308)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:328)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
    leiningen.core.main$_main$fn__5903.invoke (main.clj:401)
    leiningen.core.main$_main.invokeStatic (main.clj:394)
    leiningen.core.main$_main.doInvoke (main.clj:391)
    clojure.lang.RestFn.invoke (RestFn.java:482)
    clojure.lang.Var.invoke (Var.java:401)
    clojure.lang.AFn.applyToHelper (AFn.java:171)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.main$main_opt.invokeStatic (main.clj:314)
    clojure.main$main_opt.invoke (main.clj:310)
    clojure.main$main.invokeStatic (main.clj:421)
    clojure.main$main.doInvoke (main.clj:384)
    clojure.lang.RestFn.invoke (RestFn.java:551)
    clojure.lang.Var.invoke (Var.java:419)
    clojure.lang.AFn.applyToHelper (AFn.java:186)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.main.main (main.java:37)
Caused by: java.lang.RuntimeException: Too many arguments to throw, throw expects a single Throwable instance
 at clojure.lang.Util.runtimeException (Util.java:221)
    clojure.lang.Compiler$ThrowExpr$Parser.parse (Compiler.java:2428)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler$IfExpr$Parser.parse (Compiler.java:2805)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6001)
    clojure.lang.Compiler$LetExpr$Parser.parse (Compiler.java:6319)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler$BodyExpr$Parser.parse (Compiler.java:6001)
    clojure.lang.Compiler$FnMethod.parse (Compiler.java:5380)
    clojure.lang.Compiler$FnExpr.parse (Compiler.java:3972)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6866)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6856)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.access$300 (Compiler.java:38)
    clojure.lang.Compiler$DefExpr$Parser.parse (Compiler.java:589)
    clojure.lang.Compiler.analyzeSeq (Compiler.java:6868)
    clojure.lang.Compiler.analyze (Compiler.java:6669)
    clojure.lang.Compiler.analyze (Compiler.java:6625)
    clojure.lang.Compiler.eval (Compiler.java:6931)
    clojure.lang.Compiler.load (Compiler.java:7379)
    clojure.lang.RT.loadResourceScript (RT.java:372)
    clojure.lang.RT.loadResourceScript (RT.java:363)
    clojure.lang.RT.load (RT.java:453)
    clojure.lang.RT.load (RT.java:419)
    clojure.core$load$fn__5677.invoke (core.clj:5893)
    clojure.core$load.invokeStatic (core.clj:5892)
    clojure.core$load.doInvoke (core.clj:5876)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.core$load_one.invokeStatic (core.clj:5697)
    clojure.core$load_one.invoke (core.clj:5692)
    clojure.core$load_lib$fn__5626.invoke (core.clj:5737)
    clojure.core$load_lib.invokeStatic (core.clj:5736)
    clojure.core$load_lib.doInvoke (core.clj:5717)
    clojure.lang.RestFn.applyTo (RestFn.java:142)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$load_libs.invokeStatic (core.clj:5774)
    clojure.core$load_libs.doInvoke (core.clj:5758)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$require.invokeStatic (core.clj:5796)
    clojure.core$require.doInvoke (core.clj:5796)
    clojure.lang.RestFn.invoke (RestFn.java:805)
    leiningen.source_deps$eval1023$loading__5569__auto____1024.invoke (source_deps.clj:1)
    leiningen.source_deps$eval1023.invokeStatic (source_deps.clj:1)
    leiningen.source_deps$eval1023.invoke (source_deps.clj:1)
    clojure.lang.Compiler.eval (Compiler.java:6927)
    clojure.lang.Compiler.eval (Compiler.java:6916)
    clojure.lang.Compiler.load (Compiler.java:7379)
    clojure.lang.RT.loadResourceScript (RT.java:372)
    clojure.lang.RT.loadResourceScript (RT.java:363)
    clojure.lang.RT.load (RT.java:453)
    clojure.lang.RT.load (RT.java:419)
    clojure.core$load$fn__5677.invoke (core.clj:5893)
    clojure.core$load.invokeStatic (core.clj:5892)
    clojure.core$load.doInvoke (core.clj:5876)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.core$load_one.invokeStatic (core.clj:5697)
    clojure.core$load_one.invoke (core.clj:5692)
    clojure.core$load_lib$fn__5626.invoke (core.clj:5737)
    clojure.core$load_lib.invokeStatic (core.clj:5736)
    clojure.core$load_lib.doInvoke (core.clj:5717)
    clojure.lang.RestFn.applyTo (RestFn.java:142)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$load_libs.invokeStatic (core.clj:5774)
    clojure.core$load_libs.doInvoke (core.clj:5758)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$require.invokeStatic (core.clj:5796)
    clojure.core$require.doInvoke (core.clj:5796)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    leiningen.core.utils$require_resolve.invokeStatic (utils.clj:89)
    leiningen.core.utils$require_resolve.invoke (utils.clj:82)
    leiningen.core.utils$require_resolve.invokeStatic (utils.clj:92)
    leiningen.core.utils$require_resolve.invoke (utils.clj:82)
    leiningen.core.main$lookup_task_var.invokeStatic (main.clj:68)
    leiningen.core.main$lookup_task_var.invoke (main.clj:64)
    leiningen.core.main$pass_through_help_QMARK_.invokeStatic (main.clj:78)
    leiningen.core.main$pass_through_help_QMARK_.invoke (main.clj:72)
    leiningen.core.main$task_args.invokeStatic (main.clj:81)
    leiningen.core.main$task_args.invoke (main.clj:80)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:327)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
    leiningen.do$do.invokeStatic (do.clj:40)
    leiningen.do$do.doInvoke (do.clj:32)
    clojure.lang.RestFn.invoke (RestFn.java:486)
    clojure.lang.Var.invoke (Var.java:401)
    clojure.lang.AFn.applyToHelper (AFn.java:171)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$partial_task$fn__5837.doInvoke (main.clj:272)
    clojure.lang.RestFn.applyTo (RestFn.java:139)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:648)
    clojure.core$apply.invoke (core.clj:641)
    leiningen.core.main$apply_task.invokeStatic (main.clj:322)
    leiningen.core.main$apply_task.invoke (main.clj:308)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:328)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:324)
    leiningen.core.main$_main$fn__5903.invoke (main.clj:401)
    leiningen.core.main$_main.invokeStatic (main.clj:394)
    leiningen.core.main$_main.doInvoke (main.clj:391)
    clojure.lang.RestFn.invoke (RestFn.java:482)
    clojure.lang.Var.invoke (Var.java:401)
    clojure.lang.AFn.applyToHelper (AFn.java:171)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invokeStatic (core.clj:646)
    clojure.main$main_opt.invokeStatic (main.clj:314)
    clojure.main$main_opt.invoke (main.clj:310)
    clojure.main$main.invokeStatic (main.clj:421)
    clojure.main$main.doInvoke (main.clj:384)
    clojure.lang.RestFn.invoke (RestFn.java:551)
    clojure.lang.Var.invoke (Var.java:419)
    clojure.lang.AFn.applyToHelper (AFn.java:186)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.main.main (main.java:37)

illegal reflective access operation

When starting lein repl I get a number of warnings:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson049.orchard.v0v4v0.dynapath.v0v2v5.dynapath.defaults$eval3663$fn__3664 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson049.orchard.v0v4v0.dynapath.v0v2v5.dynapath.defaults$eval3663$fn__3664
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

My profiles.clj:

{:system {:jvm-opts ["-Duser.timezone=UTC"]}
 :user  {:plugins  [[lein-ancient "0.6.15" :exclusions [org.clojure/clojure]]
                    [thomasa/mranderson "0.5.1"]
                    [cider/cider-nrepl "0.21.1"]
                    [lein-pprint "1.2.0"]
                    [jonase/eastwood "0.3.3"]
                    [lein-try "0.4.3"]]
         :dependencies [[com.bhauman/rebel-readline "0.1.4"]]
         :aliases {"rebl" ["trampoline" "run" "-m" "rebel-readline.main"]}
         :injections []}}

Big slowdown on Java 16

Comparing Java 11 to Java 16, it seems on the latter MrAnderson is an order of maginitude slower than on the former.

Using sdkman

$ sdk use java 11.0.10.hs-adpt
$ /usr/bin/time lein test
73.42user 1.79system 0:28.42elapsed 264%CPU (0avgtext+0avgdata 926716maxresident)k
27088inputs+37504outputs (126major+262412minor)pagefaults 0swaps

$ sdk use java 16.0.1.hs-adpt 
$ /usr/bin/time lein test
700.25user 1363.14system 5:06.12elapsed 674%CPU (0avgtext+0avgdata 393300maxresident)k
0inputs+18000outputs (157major+156929minor)pagefaults 0swaps

So 5 minutes instead of 28 seconds. A cider-nrepl build is taking half an hour on my machine.

Not sure if this is a red herring, but on the latter I'm getting this warning

OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 an
d will likely be removed in a future release.

Fix broken cljdoc api analysis

Problem

The MrAnderson readme has a cljdoc badge which is showing "API import failed":

I assume that we'd like to fix this.

Diagnosis

Cljdoc is barfing when trying to load mranderson.util namespace.
It references leiningen.core.main which is not on the classpath during cljdoc analysis.

Public API

Cljdoc API docs ideally document the public API of a library.

I don't know what the public API of mranderson is, but once I do, we can tell cljdoc to ignore mranderson internals via :no-doc metadata on mranderson namespaces and vars that are considered internal.

This might well be enough to fix cljdoc API analysis.
If not we can explore further.

My current guess a public supported nses:

mranderson.core
mrnaderson.plugin

Next Steps

I am happy to follow up with a PR once we agree on an approach.

clean up and finalise API

so MrAnderson can be used by a third party, maybe from the REPL to pull in a dep and shadow it.

resource directories not repackaged

This is easy to reproduce with the lein-collisions plugin in a project depending on cider and cljfmt:

$ lein collisions
cljfmt/indents/clojure.clj -- 2  collisions:
  -- /home/user/.m2/repository/cider/cider-nrepl/0.9.1/cider-nrepl-0.9.1.jar
  -- /home/user/.m2/repository/cljfmt/cljfmt/0.2.0/cljfmt-0.2.0.jar
...

make lein plugin a separate, optional artifact

almost all leinigen specific code is already in leiningen.inline-deps, however mranderson.util still references leiningen for logging. if this latter is eliminated leiningen could be excluded when mranderson is used directly

related to #35

Handle deftype and java class with the same prefix in an import

example from here from claypoole

 (:import
    [com.climate.claypoole.impl
     PriorityThreadpool
     PriorityThreadpoolImpl]
[...])

this import prefixes two classes of claypoole itself. One of those classes is created with a deftype, the other one is created by a java class. MrAnderson prefixing deftype based classes in imports is a separate step from prefixing java class based classes in imports. The logic prefixing them is also different resulting in different prefixes. This means that inlining this library breaks now because the deftype prefixing "wins" for this import but this would render the java class based import wrong.

To fix either aline the two steps so they generate the same prefix or split this import into two so they can have different prefixes.

Pomegranate is moving to Eclipse Aether (RFC)

There's a RFC on this pull request on pomegranate. Will this affect mranderson?

Add option to print only resolved/unresolved deps tree and exit

Spin off `mranderson.move` into a separate lib

As it is a touched up version of clojure.tools.namespace.move could be used separately from MrAnderson

`:import` of records breaks

I have the following project.clj

(defproject positano "0.3.0-SNAPSHOT"
  :description "Provenace system for Clojure"
  :url "https://github.com/stathissideris/positano"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.8.0"]
                 ^:source-dep [datascript "0.15.0"]
                 ^:source-dep [org.clojure/core.async "0.2.385"]
                 ^:source-dep [org.clojure/tools.analyzer.jvm "0.6.10"]]

  :plugins [[thomasa/mranderson "0.4.7"]]
  :profiles {:dev {:source-paths ["src" "dev"]
                   :dependencies [[org.clojure/tools.namespace "0.2.11"]]}})

Running the tests with mranderson, results in this exception:

➜  positano lein with-profile +plugin.mranderson/config test
Exception in thread "main" java.lang.ClassNotFoundException: datascript.pull_parser.PullSpec, compiling:(mranderson047/datascript/v0v15v0/datascript/pull_api.cljc:1:1)

PullSpec is a record defined in a different namespace of datascript:

https://github.com/tonsky/datascript/blob/master/src/datascript/pull_parser.cljc

You can try my project here:

https://github.com/stathissideris/positano

Set metadata to identify inlined namespaces

Tools like https://cljdoc.org that generate API documentation will see inlined deps namespaces like any other namespace. This makes it hard to exclude namespaces from inlined dependencies from API documentation; making the API docs harder to read for end users.

It would be great of MrAnderson could attach some metadata to inlined namespaces so that those namespaces can be identified and excluded from API documentation. Perhaps just :no-doc is fine but something more MrAnderson specific would also be reasonable and useful enough.

Here's an example of how this affects the cider-nrepl API docs.

cljdoc/cljdoc#195

shorten leiningen profile name `plugin.mranderson/config`

Not replacing imports in top-level namespaces

Hey again 😄

clj-tuple (a transient dependency of clj-http, in my case) has a top-level clj-tuple namespace, which isn't getting included in :import replacements. I reckon it's because clj-files->dirs has a (remove str/blank?), but removing this leads to target/srcdeps being included in clj-dirs, and I wasn't satisfied that I understood all the impacts of this before naively removing it :)

James

clean up opts in terms of CLI and project file

provide options to define them in the project file or on CLI where the option is missing and makes sense

tests which require mrandersoned dependencies of a project fail

since those dependencies are prefixed by mranderson but the test files are processed at the moment.

see a particular case of this: clojure-emacs/cider-nrepl#183

intermitent broken files when inlining

sometimes files in dependencies come out broken (part of the file is missing therefore parens are not closed). gut feeling is that something goes wrong when files are processed in parallel.

example

fazekasbenedek@scatha:~/projects/cider-nrepl (master)$ make test
lein with-profile -user inline-deps
project prefix:  cider.nrepl.inlined-deps
retrieve dependencies and munge clojure source files
in RESOLVED-TREE mode, working on a resolved dependency tree
 [cljfmt "0.8.0" :exclusions [[org.clojure/clojure] [org.clojure/clojurescript]]]
   [com.googlecode.java-diff-utils/diffutils "1.3.0"]
   [org.clojure/tools.cli "1.0.206"]
   [rewrite-clj "1.0.605-alpha"]
 [org.clojure/tools.namespace "1.0.0" :exclusions [[org.clojure/clojure]]]
   [org.clojure/java.classpath "1.0.0"]
 [compliment "0.3.11" :exclusions [[org.clojure/clojure]]]
 [org.clojure/tools.trace "0.7.10" :exclusions [[org.clojure/clojure]]]
 [org.rksm/suitable "0.4.0" :exclusions [[org.clojure/clojure] [org.clojure/clojurescript]]]
 [cider/orchard "0.7.1" :exclusions [[org.clojure/clojure]]]
   [org.tcrawley/dynapath "1.1.0" :exclusions [[org.clojure/clojure]]]
 [org.clojure/tools.reader "1.3.2" :exclusions [[org.clojure/clojure]]]
 [fipp "0.6.24" :exclusions [[org.clojure/clojure]]]
   [org.clojure/core.rrb-vector "0.1.1"]
 [thunknyc/profile "0.5.2" :exclusions [[org.clojure/clojure]]]
 [mvxcvi/puget "1.3.1" :exclusions [[org.clojure/clojure]]]
   [mvxcvi/arrangement "1.2.0"]
unzipping [ orchard  [ v0v7v1 ]]
unzipping [ profile  [ v0v5v2 ]]
unzipping [ dynapath  [ v1v1v0 ]]
unzipping [ toolsnamespace  [ v1v0v0 ]]
unzipping [ cljfmt  [ v0v8v0 ]]
unzipping [ rewrite-clj  [ v1v0v605-alpha ]]
unzipping [ toolsreader  [ v1v3v2 ]]
unzipping [ suitable  [ v0v4v0 ]]
unzipping [ puget  [ v1v3v1 ]]
unzipping [ fipp  [ v0v6v24 ]]
unzipping [ corerrb-vector  [ v0v1v1 ]]
unzipping [ javaclasspath  [ v1v0v0 ]]
unzipping [ diffutils  [ v1v3v0 ]]
unzipping [ arrangement  [ v1v2v0 ]]
unzipping [ toolstrace  [ v0v7v10 ]]
unzipping [ toolscli  [ v1v0v206 ]]
unzipping [ compliment  [ v0v3v11 ]]
  munge source files of compliment artifact on branch [] exposed false.
  munge source files of toolscli artifact on branch [] exposed false.
  munge source files of toolstrace artifact on branch [] exposed false.
  munge source files of arrangement artifact on branch [] exposed false.
  munge source files of diffutils artifact on branch [] exposed false.
  munge source files of javaclasspath artifact on branch [] exposed false.
  munge source files of corerrb-vector artifact on branch [] exposed false.
  munge source files of fipp artifact on branch [] exposed false.
  munge source files of puget artifact on branch [] exposed false.
  munge source files of suitable artifact on branch [] exposed false.
  munge source files of toolsreader artifact on branch [] exposed false.
  munge source files of rewrite-clj artifact on branch [] exposed false.
  munge source files of cljfmt artifact on branch [] exposed false.
    prefixing imports in clojure files in 'target/srcdeps/cljfmt' ...
    prefixing imports: done
  munge source files of toolsnamespace artifact on branch [] exposed false.
  munge source files of dynapath artifact on branch [] exposed false.
  munge source files of profile artifact on branch [] exposed false.
  munge source files of orchard artifact on branch [] exposed false.
jaring all class file dependencies into target/class-deps.jar
prefixing #{"difflib"} in target/class-deps.jar with cidernrepl0270SNAPSHOT
deleting directories with class files in target/srcdeps...
   difflib  deleted
unzipping repackaged class-deps.jar into target/srcdeps
touch .inline-deps
lein with-profile -user,+1.10,+test,+plugin.mranderson/config test
Compiling 3 source files to /Users/fazekasbenedek/projects/cider-nrepl/target/classes
Syntax error reading source at (cider/nrepl/inlined_deps/toolsreader/v1v3v2/clojure/tools/reader/reader_types.clj:251:82).
Unmatched delimiter: ]

Consider Bumping Deps

Currently

If I run antq:

clojure -Sdeps '{:deps {com.github.liquidz/antq {:mvn/version "RELEASE"} org.clojure/clojure {:mvn/version "1.11.1"}}}' -M -m antq.core

on MrAnderson, it reports:

:name	:current	:latest
com.cemerick/pomegranate	0.4.0	1.1.0
jonase/eastwood	0.9.9	1.3.0
lambdaisland/kaocha	0.0-418	1.69.1069
lambdaisland/kaocha-cloverage	0.0-32	1.0.75
leiningen-core/leiningen-core	2.9.1	2.9.10
org.clojure/clojure	1.10.3	1.11.1
org.clojure/tools.namespace	1.1.0	1.3.0
rewrite-clj/rewrite-clj	1.0.682-alpha	1.1.45

I wonder

If we should consider upgrading some of these old deps?

Pros:

I find a project easier to maintain when it uses current deps, you get to refer to current docs and get better support from library authors
Might pick up improvements, fixes, and security updates
Helps the Clojure community in that we are involved in using/testing current versions of libs

Cons:

There's the entirely valid argument: if it isn't broken do not touch it
Might pick up breakages

Notes

I did run nvd-clojure against MrAnderson, it found security issues in MrAnderson's transitive deps
com.cemerick/pomegranate is now under clj-commons/pomegranate
not listed above, but:
- me.raynes/fs is now under the clj-commons/fs. Frankly, I would recommend a switch to babashka/fs instead as it has a nice API and is under active development, but that would be a switch not a bump.
- org.pantsbuilt/jarjar is no longer maintained, should we explore jajar-abrams?
I can vouch for rewrite-clj! (I'm the primary maintainer on that project)
kaocha and eastwood libs are a safe bet since we only use them for testing/linting

Next steps

Lemme know how you feel, if any of this is interesting to you, I am happy to tackle this work.

Problem packaging refactor-nrepl

C:\git\refactor-nrepl>lein source-deps && lein with-profile plugin.mranderson/config install && lein localrepo coords target/refactor-nrepl-0.2.0-SNAPSHOT.jar | xargs lein localrepo install
retrieving tools.analyzer.jvm artifact. modified dependency name: toolsanalyzerjvm modified version string: v0v6v3
   modified namespace prefix:  deps.toolsanalyzerjvm.v0v6v3
java.lang.IllegalArgumentException: character to be escaped is missing
 at java.util.regex.Matcher.appendReplacement (Matcher.java:809)
    java.util.regex.Matcher.replaceAll (Matcher.java:955)
    clojure.string$replace.invoke (string.clj:105)
    deps.toolsnamespace.v0v2v5.clojure.tools.namespace.move$ns_file_name.invoke (move.clj:35)
    deps.toolsnamespace.v0v2v5.clojure.tools.namespace.move$move_ns_file.invoke (move.clj:76)
    deps.toolsnamespace.v0v2v5.clojure.tools.namespace.move$move_ns.invoke (move.clj:98)
    leiningen.source_deps$unzip_AMPERSAND_update_artifact_BANG_.invoke (source_deps.clj:99)
   clojure.lang.AFn.applyToHelper (AFn.java:165)
    clojure.lang.AFn.applyTo (AFn.java:144)
    clojure.core$apply.invoke (core.clj:630)
    clojure.core$partial$fn__4232.doInvoke (core.clj:2472)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.core$map$fn__4245.invoke (core.clj:2559)
    clojure.lang.LazySeq.sval (LazySeq.java:40)
    clojure.lang.LazySeq.seq (LazySeq.java:49)
    clojure.lang.RT.seq (RT.java:484)
    clojure.core$seq.invoke (core.clj:133)
    clojure.core$dorun.invoke (core.clj:2855)
    clojure.core$doall.invoke (core.clj:2871)
    leiningen.source_deps$source_deps.doInvoke (source_deps.clj:123)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.Var.invoke (Var.java:379)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invoke (core.clj:626)
    leiningen.core.main$partial_task$fn__6071.doInvoke (main.clj:253)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:29)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invoke (core.clj:626)
    leiningen.core.main$apply_task.invoke (main.clj:303)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:309)
    leiningen.core.main$_main$fn__6136.invoke (main.clj:377)
    leiningen.core.main$_main.doInvoke (main.clj:366)
    clojure.lang.RestFn.invoke (RestFn.java:408)
    clojure.lang.Var.invoke (Var.java:379)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.core$apply.invoke (core.clj:624)
    clojure.main$main_opt.invoke (main.clj:315)
    clojure.main$main.doInvoke (main.clj:420)
    clojure.lang.RestFn.invoke (RestFn.java:436)
    clojure.lang.Var.invoke (Var.java:388)
    clojure.lang.AFn.applyToHelper (AFn.java:160)
    clojure.lang.Var.applyTo (Var.java:700)
    clojure.main.main (main.java:37)

Trying to reproduce clojure-emacs/clj-refactor.el#86 on the windows machine at work.

Rename `source-dep` to `inline-dep`

  :dependencies [[nrepl "0.6.0"]
                 ^:source-dep [cider/orchard "0.4.0"]
                 ^:source-dep [thunknyc/profile "0.5.2"]
                 ^:source-dep [mvxcvi/puget "1.1.0"]
                 ^:source-dep [fipp "0.6.15"]
                 ^:source-dep [compliment "0.3.8"]
                 ^:source-dep [cljs-tooling "0.3.1"]
                 ^:source-dep [cljfmt "0.6.4" :exclusions [org.clojure/clojurescript]]

Related to changing source-deps to inline-deps. I think it'd be nice if you added an alias for this that's :inline (that'd be my preference) or :inline-dep. That won't break backwards compatibility, but would align the name of the task with the metadata.

Don't copy META-INF directories?

In re-frame-10x we go through a bit of work to delete the META-INF directories and then delete any empty directory paths left over after that.

https://github.com/Day8/re-frame-10x/blob/40d9ff3ddf52d0469555fb3b7356d6dcb940fc58/source-deps.sh#L10-L16

Would it make sense to have an option to not copy those directories in, or is there some other reason why they are needed?

Doesn't work with prefix libspecs?

I had to make this change to get the mranderson tests to pass, when writing find-unbound-vars for refactor-nrepl:

--- i/src/refactor_nrepl/analyzer.clj
+++ w/src/refactor_nrepl/analyzer.clj
@@ -1,9 +1,8 @@
 (ns refactor-nrepl.analyzer
   (:refer-clojure :exclude [macroexpand-1])
   (:require [clojure.tools.analyzer :as ana]
-            [clojure.tools.analyzer
-             [jvm :as aj]
-             [passes :refer [schedule]]]
+            [clojure.tools.analyzer.jvm :as aj]
+            [clojure.tools.analyzer.passes :refer [schedule]]
             [clojure.tools.analyzer.passes.jvm.validate :refer [validate]]
             [clojure.tools.namespace.parse :refer [read-ns-decl]])
   (:import java.io.PushbackReader))

rewrite README

current readme needs a big overhaul. maybe a bit less 'funny' and more informative?! :)

Intermittent broken file after mrandersoning

Occasionally after mrandersoning a file gets only half written on the disk causing compilation errors. Very likely related to the parallel file processing mranderson does on the 0.5.x branch -- however, as the problem occurred both with parallel and claypoole most likely mranderson itself is buggy somehow (missing with-open maybe...?!).

Needs a test first to reliably reproduce the problem.

Inconsistency with args pulled from project map vs CLI

In https://github.com/benedekfazekas/mranderson/blob/master/src/leiningen/inline_deps.clj#L16-L42, it seems that some of the options are pulled from the CLI, some from the project map, and some from both - is this intentional?

Caught me out when I tried to include flags from the README in the project map 😉

If not, happy to write up a quick PR :)

James

explore distribution as a GraalVM native imgs

depends on #35

Namespace alias regression

How to reproduce

project.clj

  :dependencies [[org.clojure/clojure "1.10.0"]
                 ^:source-dep [medley "1.1.0"]]

src/foo/core.clj

(ns foo.core
  (:require [medley.core :as medley]))

(defn foo []
  (medley/random-uuid))

In 0.4.9, target/srcdeps/foo/core.clj will be the following I expected.

(ns foo.core
  (:require [mranderson049.medley.v1v1v0.medley.core :as medley]))

(defn foo []
  (medley/random-uuid))

In 0.5.0, medley alias has changed and code is broken.

(ns foo.core
  (:require [mrandersonf85dac82.medley.v1v1v0.medley.core :as mrandersonf85dac82.medley.v1v1v0.medley]))

(defn foo []
  (medley/random-uuid))

Consider adding some brief docs for MrAnderson developers

Currently

While making some changes to MrAnderson, I was curious to know the best way to build and install locally.

I stumbled on the Makefile.
And looked at what MrAnderson does for CircleCI.

And figured things out. Maybe.

I think...

Some dev docs would be helpful for those who want to contribute to MrAnderson.

This could either be in a separate dev.md doc or directly in the current README.md.

Also...

Even after looking at the Makefile several times, I'm not sure I understand how to build and install a version of MrAnderson with inlined deps to my local maven repo.

I tweaked the Makefile:

-.PHONY: install inline test integration-test deploy clean
+.PHONY: boostrap-install inline test integration-test install deploy clean

# Note that `install` is a two-step process: given that mranderson depends on itself as a plugin,
# it first needs to be installed without the plugin, for bootstrapping this self dependency.
-install:
+bootstrap-install:
	lein clean
	lein with-profile -user,-dev install
	lein with-profile -user,-dev,+mranderson-plugin install

-.inline: install
+.inline: bootstrap-install
	rm target/*.jar
	rm pom.xml
	lein with-profile -user,-dev,+mranderson-plugin inline-deps :skip-javaclass-repackage true
	touch .inline

inline: .inline

test:
	lein test

integration-test:
	.circleci/integration_test.sh

+install: .inline
+	lein with-profile -user,-dev,+mranderson-profile install
+
deploy: .inline
	lein with-profile -user,-dev,+mranderson-profile deploy clojars

clean:
	lein clean
	rm -rf .inline

This seemed to work, but if it does not make sense please let me know so I can better understand.
If it does make sense I can include the change in the PR.

Next Steps

If adding some brief developer docs is something that interests you too, I'll follow up with a PR.

Over-zealous replacing imports inlining potemkin 0.4.5

Hey again @benedekfazekas 😄

Looks like mranderson is replacing imports that it shouldn't when it needs to rename only some classes within a package.

repro:

^:inline-dep [potemkin "0.4.5"] - this has dependencies on riddley "0.1.12" and clj-tuple "0.2.2"; it's the presence of both of these that causes the issue. (I'm trying to inline clj-http "3.12.2", but it seems potemkin is a smaller repro.)
lein inline-deps
check the outputted riddley.compiler - mranderson has prefixed clojure.lang.Var etc, but these don't appear prefixed in class-deps.jar.
check class-deps.jar - there are other clojure.lang classes present from clj-tuple.

I reckon this is something to do with prefix-dependency-imports! using a set of packages to replace - is there anything preventing us from using exact classes instead?

Thanks again!

James

Rewrites string literals

I'm not sure if this behavior is intended or not, but mranderson rewrites string literals if they contain a full namespace name. This affects this line in cider-nrepl:

https://github.com/clojure-emacs/cider-nrepl/blob/master/src/cider/nrepl/middleware/refresh.clj#L32

The comment above indicates that the code in cider-nrepl was written this way (constructing a keyword at runtime) specifically so that this rewriting would not happen.

The result is that cider-refresh unloads and reloads namespaces that it should not.

load statements aren't handled

I recently tried to inline tools.deps.alpha to get hotload-dependencies working again for cljr, but mranderson failed to consider these load statements in the middle of the file.

The system cannot find the file specified

Could someone please help me with the following error:

C:\git\databot2\databot\src\za\co\resbank>lein inline-deps
project prefix:  mrandersonb765aca7
retrieve dependencies and munge clojure source files
in RESOLVED-TREE mode, working on a resolved dependency tree
 [clj-http "3.10.0"]
   [commons-io "2.6" :exclusions [[org.clojure/clojure]]]
   [org.apache.httpcomponents/httpmime "4.5.8" :exclusions [[org.clojure/clojure]]]
   [potemkin "0.4.5" :exclusions [[org.clojure/clojure]]]
     [clj-tuple "0.2.2"]
     [riddley "0.1.12"]
   [org.apache.httpcomponents/httpclient "4.5.8" :exclusions [[org.clojure/clojure]]]
     [commons-logging "1.2"]
   [org.apache.httpcomponents/httpcore "4.4.11" :exclusions [[org.clojure/clojure]]]
   [slingshot "0.12.2" :exclusions [[org.clojure/clojure]]]
   [org.apache.httpcomponents/httpclient-cache "4.5.8" :exclusions [[org.clojure/clojure]]]
   [org.apache.httpcomponents/httpasyncclient "4.1.4" :exclusions [[org.clojure/clojure]]]
     [org.apache.httpcomponents/httpcore-nio "4.4.10"]
   [commons-codec "1.12" :exclusions [[org.clojure/clojure]]]
unzipping [ clj-http  [ v3v10v0 ]]
unzipping [ httpmime  [ v4v5v8 ]]
unzipping [ commons-io  [ v2v6 ]]
unzipping [ potemkin  [ v0v4v5 ]]
unzipping [ clj-tuple  [ v0v2v2 ]]
unzipping [ httpclient-cache  [ v4v5v8 ]]
unzipping [ httpasyncclient  [ v4v1v4 ]]
unzipping [ httpclient  [ v4v5v8 ]]
unzipping [ commons-logging  [ v1v2 ]]
unzipping [ commons-codec  [ v1v12 ]]
unzipping [ httpcore-nio  [ v4v4v10 ]]
unzipping [ httpcore  [ v4v4v11 ]]
unzipping [ slingshot  [ v0v12v2 ]]
unzipping [ riddley  [ v0v1v12 ]]
  munge source files of riddley artifact on branch [] exposed false.
java.io.FileNotFoundException: target\default\srcdeps\riddley\compiler.clj (The system cannot find the file specified)

My project.clj looks as follows:

(defproject za.co.resbank.databot "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :url "http://example.com/FIXME"
  :license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
            :url "https://www.eclipse.org/legal/epl-2.0/"}
  :dependencies [[org.clojure/clojure "1.10.0"]
                 [org.clojure/data.csv "0.1.4"]
                 [cheshire "5.8.1"]
                 ^:inline-dep [clj-http "3.10.0"]
                 [seesaw "1.5.0"]
                 [za.co.resbank/haverapi-java "2.1.0.0"]
                 [com.bloomberglp/blpapi "3.12.1-1"]
                 [clojure.java-time "0.3.2"]]
  :main ^:skip-aot za.co.resbank.databot
  :target-path "target/%s"
  :profiles {:uberjar {:aot :all}}
  :plugins [[thomasa/mranderson "0.5.1"]])

Investigate what happens when MrAnderson is used recursively

altho MrAnderson is mainly meant to be used on applications, inlining/shadowing their dependencies. it is possible to inline a library which has its dependencies inlined already. Wonder if this just works out of the box or breaks and if so how.

Since mranderson adds a meta now to the ns it is possible to avoid inlining already inlined stuff if needed

Handle ClojureScript files too

There was a confusing bug for a user of refactor-nrepl, who was trying to specify his own version of tools.reader. refactor-nrepl uses mranderson for shading it's version of tools.reader, but mranderson doesn't handle ClojureScript files. These got copied in whole, and caused hard to debug issues. More details are available at technomancy/leiningen#2097 (comment) and emezeske/lein-cljsbuild#439.

explore using tools.deps instead of pomegranate/aether

as means of resolving dependencies

mrandersoning tools.nrepl fails when trying to use transport

java.lang.IllegalArgumentException: No implementation of method: :send of protocol: #'deps.toolsnrepl.v0v2v3.clojure.tools.nrepl.transport/Transport found for class: clojure.tools.nrepl.transport.FnTransport
    at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:541) ~[clojure-1.5.1.jar:na]
    at deps.toolsnrepl.v0v2v3.clojure.tools.nrepl.transport$eval31768$fn__31769$G__31757__31776.invoke(transport.clj:16) ~[na:na]
    at refactor_nrepl.refactor$find_debug_fns_reply.invoke(refactor.clj:48) ~[na:na]
    at refactor_nrepl.refactor$wrap_refactor$fn__32157.invoke(refactor.clj:57) ~[na:na]
    at deps.toolsnrepl.v0v2v3.clojure.tools.nrepl.middleware$wrap_conj_descriptor$fn__31990.invoke(middleware.clj:17) ~[na:na]
    at clojure.tools.nrepl.server$handle_STAR_.invoke(server.clj:19) ~[na:na]
    at clojure.tools.nrepl.server$handle$fn__18490.invoke(server.clj:28) [na:na]
    at clojure.core$binding_conveyor_fn$fn__4107.invoke(core.clj:1836) [clojure-1.5.1.jar:na]
    at clojure.lang.AFn.call(AFn.java:18) [clojure-1.5.1.jar:na]
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [na:1.7.0_17]
    at java.util.concurrent.FutureTask.run(FutureTask.java:166) [na:1.7.0_17]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_17]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_17]
    at java.lang.Thread.run(Thread.java:722) [na:1.7.0_17]

this showing up at startup may be related:

[WARNING] No nREPL middleware descriptor in metadata of #'refactor-nrepl.refactor/wrap-refactor, see clojure.tools.middleware/set-descriptor!

Maybe transition to using maintained fork of jarjar

It looks like the com.googlecode.jarjar has been abandoned these last six years. Since then the pantsbuild developers have forked it for their own use at https://github.com/pantsbuild/jarjar

Their fork adds a few interesting features:

a much newer version of ASM (6.2) (which is maintained)
which adds support for working with Java 10 files (and many other improvements I'm sure)
buffered jar writes (== better performance!)
improved (and configurable) handling of "misplaced class files"

Might be worth a look at using! I may end up taking a look at updating it myself

Excluded or overriden transitive dependencies break topological sort

A project.clj such as this:

:dependencies [[org.clojure/core.memoize "0.5.6"]
               [org.clojure/core.cache "0.6.4"]]

ignores the fact that core.memoize must be processed before core.cache because pomegranate thinks core.cache does not appear in the dependencies of core.memoize.

This means core.memoize ends up with calls to clojure.core.cache, since core.cache can be processed first.

create CLI interface

lein plugin should be an optional wrapper really

No reader function for tag Inf in parallel library

Hi @benedekfazekas!

Opening an issue from clojure-emacs/cider-nrepl#594 because the problem does not seem to be solved:

clojure.lang.Compiler$CompilerException: clojure.lang.LispReader$ReaderException: java.lang.RuntimeException: No reader function for tag Inf, compiling:(mranderson/inlined/parallel/v0v10/parallel/core.clj:323:31)
 at clojure.lang.Compiler.load (Compiler.java:7386)
    clojure.lang.RT.loadResourceScript (RT.java:372)
    clojure.lang.RT.loadResourceScript (RT.java:363)
    ...

$ lein -v
Leiningen 2.8.3 on Java 1.8.0_191 OpenJDK 64-Bit Server VM

The tests there are running against clojure 1.10 by default.

spit out some meta info about a run

from the conversation with @Olical on slack:

Some meta output out of mranderson, either as it runs or at the end could be useful. "here's the files I read and wrote and what I renamed inside them". I could then do my ordering work with tools.namespace on that output and spit out the full report to use in the future.

Regression with Reagent macros in 0.5.0

Previously, mranderson rewrote https://github.com/reagent-project/reagent/blob/master/src/reagent/debug.clj#L7 from

(defmacro log
  "Print with console.log, if it exists."
  [& forms]
  `(when reagent.debug.has-console
     (.log js/console ~@forms)))

;; to

(defmacro log
  "Print with console.log, if it exists."
  [& forms]
  `(when mranderson048.reagent.v0v8v0.reagent.debug.has-console
     (.log js/console ~@forms)))

When using mranderson 0.5.0, the namespace form isn't rewritten, it stays exactly the same as the original.

Looking at the form, it is valid ClojureScript, though it may be more idiomatic to write reagent.debug/has-console.

I've noticed improvements elsewhere, "Expected a reagent component, not "
used to be rewritten to "Expected a mranderson048.reagent.v0v8v0.reagent component, not ", but is now left alone. I suspect this bug may be a side-effect of the change.

Fails to add prefix to Java classes compiled with Java >7

Hey @benedekfazekas 👋

repro:

new project, project.clj:

(defproject repro ""
  :dependencies [^:inline-dep [tech.droit/clj-diff "1.0.1"] ; example lib compiled with Java >7
                 ^:inline-dep [commons-codec "1.10"]] ; example lib compiled with Java <=7
  :plugins [[thomasa/mranderson "0.5.3"]])

lein inline-deps
jar -tf target/class-deps.jar

In the class-deps.jar file, we see the org.apache.commons classes correctly prefixed under repro, and the clj_diff class remaining unaltered - this unaltered class may well then clash with a different version included elsewhere.

This is caused by a check in com.tonicsystems.jarjar.asm.ClassReader from com.googlecode.jarjar/jarjar:1.3, which throws an IllegalArgumentException if the major number of the classfile is >51 - this exception is silently caught in com.tonicsystems.jarjar.ext_util.JarTransformer, and the class passes through the transformer unchanged.

Suspect that #17 is the solution to this (feel free to close this one) but wanted to write up this manifestation just in case it saves someone some time!

Cheers!

James

Support more than one `:source-paths` entry

Context

Projects can have arbitrarily many :source-paths. One can choose to do so for modularity reasons, or to decomplect intricacies related to Lein plugins, JDK compatibility, etc.

However mranderson only assumes one source path:

mranderson/src/mranderson/core.clj

Lines 290 to 292 in 57f01e2

    
           (defn copy-source-files 
        
             [source-paths target-path] 
        
             (fs/copy-dir (first source-paths) (str target-path "/srcdeps")))

So files from extra source paths will be silently dropped from a final artifact.

Proposal

Make mranderson able to handle multiple source paths.

There should be some 'merging' logic: given src1/foo/bar.clj and src2/foo/baz.clj, only one foo dir should be produced, it having two .clj files.

Backwards compatibility

Existing mranderson consumers may be implicitly dependent on the current behavior, i.e. maybe they had more configured source paths, and dropping them was fine. Perhaps starting to include them would break things downstream which is why I'd propose to offer a mandatory option named e.g. :included-source-paths with three acceptable values:

:first, preserves current behavior
:source-paths, uses all :source-paths as-is
["src" "foo" "bar"], uses a fixed list independent of :source-paths

WYDT?

Thanks - V

Make default project prefix unique

currently the default is generated based on the mranderson version used to do the inlining. This actually defeats dependency isolation in theory, eg projects mrandersoned with the same version of mranderson can still clash.

Make the prefix a bit more unique

As discussed here

In the referenced thread a desire to prefix the dependencies with the project name is expressed. I think this is a mistake. We want to eliminate dependency clashes, when several versions of a class is loaded into the classloader, but we don't want to load multiple versions of identical code under different names. If we use the project name as a prefix we won't be able to share the common code and the run time will grow unnecessarily large.

skip java class repackaging if there is nothing to repackage

see clojure-emacs/cider-nrepl#247 for context

	(defn copy-source-files
	[source-paths target-path]
	(fs/copy-dir (first source-paths) (str target-path "/srcdeps")))

benedekfazekas / mranderson Goto Github PK

mranderson's People

Contributors

Stargazers

Watchers

Forkers

mranderson's Issues

Problem

Diagnosis

Public API

Next Steps

Currently

I wonder

Notes

Next steps

How to reproduce

Currently

I think...

Also...

Next Steps

Context

Proposal

Backwards compatibility

Recommend Projects

Recommend Topics

Recommend Org