Clojurians Log v2

I'll take a look at that, thanks.

https://github.com/practicalli/clojure-deps-edn/tree/qualified-alias-keywords-and-new-flags is a refactor of the project wide aliases in light of the changes coming in Clojure CLI tools (version 1.10.1.681 onwards). This will go live when the Clojure CLI changes go live. The aliases are using the -X flag for executing functions and providing default hash-map arguments (where the library supports this) and using -M flag for clojure-main (replacing -A and -R). Where chained aliases in a command have multiple main namespaces, the alias that should have its main run is added last in the chain. Alias namespaces have been upgraded to be qualified names, further defining their purpose and making them easy to understand without looking at the details (at least that is the intent). https://gist.github.com/jr0cket/ae7dd745eb45870109ace59fe835ce80 contains notes to be added to the Practicalli Clojure book on using the Clojure CLI tools with the recent changes. Any feedback on this is welcome, especially on how clear an accurate this is. Thank you.

-P can be used with -X too

re "The order in which repositories are consulted is not guaranteed", recently I changed this to actually guarantee that the first two repos consulted are central and clojars (no guarantee after that). central and clojars are listed in the root deps.edn so do not need to be added to deps.edn or settings.xml unless you add mirrors etc.

"`business-area**" looks like bad markup

the automatically included "central" and "clojars" repos can be removed from consideration by nil'ing them in deps.edn {:mvn/repos {"central" nil}}

curl -O <https://download.clojure.org/install/linux-install-1.10.1.681>
chmod +x linux-install-1.10.1.681.sh
sudo ./linux-install-1.10.1.561.sh

Run project with or without an alias:

`clojure -M:alias -m domain.app-name`
`clojure -M -m domain.app-name

:project/outdated-mvn - check for newer dependencies (maven only) The other two lines above this have the alias as code (with backticks) but this third one does not.

https://cljdoc.org/d/seancorfield/next.jdbc/1.1.588/doc/getting-started#create--populate-a-database I think it would be better to use CURRENT instead of a specific version there, unless you plan to ensure that you update the README any time you update the next.jdbc version used in any of your aliases?

clojure -M:inspect/portal-cli ClojureScript node.js REPL with Portal dependency That should be :inspect/portal-node

Add Reveal as tap> source I thought Reveal did that automatically? I don't recall having to do this manually when I've used Reveal. Depends on how you start it. If you start it with vlaaad.reveal/repl the add-tap is automatic. Perhaps make it clearer that this section only applies if you have started the REPL some other way than via Reveal itself? Or maybe it was just my misreading of what's being discussed at this point in the README?

"DEPRICATED" => "DEPRECATED"

I found several other aliases further down the README that are not highlighted as code with backticks.

https://github.com/practicalli/clojure-deps-edn/blob/qualified-alias-keywords-and-new-flags/deps.edn#L444 -- midje-runner is not unqualified in the alias -- but should be midje-runner/midje-runner (since unqualified lib names just double up in the group and artifact slot), otherwise you might cause a clash with any midje-runner lib that actually ends up with the midje group ID.

https://github.com/practicalli/clojure-deps-edn/blob/qualified-alias-keywords-and-new-flags/deps.edn#L575-L590 -- the documented -X entry points are hf.depstar/jar and hf.depstar/uberjar (the ones you have still exist for backward compatibility but are not documented).

Thank you Alex, Sean, most helpful and much appreciated.

Very cool @jr0cket! Not sure if anyone mentioned what looks like a typo:

* deps = `:deps`, `:extra-deps`, `replace-paths`
* path = `:path`, `:extra-paths`, `replace-deps

Good catch. @lee , I'll fix that copy past error, thanks.

Posting here because it there's a larger audience who might have more insight into Maven and its shade plugin behavior: The next version of depstar will preserve license/copyright files coming from dependencies by concatenating them (but omitting exact duplicates). As far as I can tell from inspection of several "uber" JAR files I found in the wild, this is the behavior of Maven with the shade plugin, with the additional license resource transformer (which omits duplicates). I couldn't find anything in Maven's documentation about this behavior, and looking at the source of the shade plugin didn't help much. If anyone here has deep insight into that aspect of Maven and can confirm its actual behavior, that would be very helpful (otherwise I'll just run with the depstar behavior I described).

I've used the shade stuff several times and I'm not sure it is anything mandated by maven either way, you're in making stuff up territory :)

I actually have come to think that the "right" way to do this is store things like that in lib-specific sub dirs under META-INF

I don't think concatenating is wrong though

Yeah, my inspection of various "uber" JAR files seemed to confirm that if maven shade finds META-INF/LICENSE or META-INF/LICENSE.txt in multiple dependencies, it simply concatenates them together in the resulting JAR file. My reading of the Apache license resource transformer seemed to confirm that it attempts to avoid duplicating the text of any license.

But this is definitely all "undocumented territory" as far as I can tell.