There should be an issue open for this. It is something I want to fix. I don't want to require AOT from users, so I want to patch onejar a little to support a default param to clojure.main.

There is certainly value for newcomers.

Atm Lein is probably good for them

But tools-deps is the first system that let me understand wtf was going on when starting up

sooo..

Yeah, I’m all for tools.deps for dependencies and classpath stuff.

I've been recommending clj to newcomers -- with the caveat that most books/tutorials use lein. At least with clj, you can point newcomers at "official" documentation in a central place and you know the tooling is both simple and well-supported.

As a relative newcomer, clj is just so much less cognitive overhead than Lein.

+1 for building uberjars

Share notes perhaps? Any attempt to explore the space is very valuable.

Krei.alpha and kick.alpha are the two attempts by JUXT. We also did mach in the past which we used for alternative purposes.

@U064X3EF3 keeps mentioning that builds are programs, so I suspect that both of those attempts to be data driven are fatally flawed. I've been thinking of implement a paper by peyton jones for creating build systems a la carte, maybe that will unlock the pieces needed, but I'm not sure yet.

My naive attempt so far is to just invoke some namespaces - either external or my own via aliases. My need is for more well rounded and robust libraries to do things like jars and so on.

Caching. Minimal builds. Early cut off. These are the general problems to solve. Cloud building is a nice to have in some contexts, but none I'm in.

I’ll look at krei and kick, thanks.

I don’t think that there is any way around the current slow startup of clojure, is it? Even with precompiled stuff, you will get at least a handful of seconds which is already too much. Hard stuff.

you could always fire up a build-tooling repl once, that puts you in a namespace with functions like (build) (test) (do-everything)

@orestis Have you seen the results people are getting with GraalVM?

Something quite hard to build at a REPL is AOT-compiling namespaces. You have to start a new JVM to do that. You might be able to get away with something like a pod, but that's the best I have. Just as a result of how it decides to cache/skip namespaces.

Right, which is why it's important that adding the minimal manifest is optional. depstar specifically excludes META-INF/*.MF files from the classpath so the resulting JAR is guaranteed to have no manifest. My fork allows users to conditionally add a minimal manifest that specifies Main-Class (only). That seems to be such a common need -- for java -jar ... -- that baking it in as an option seems worthwhile.

The code is based on Boot's create-manifest so it could also take a hash map of key/value pairs to add as extra manifest attributes, but that's not exposed to the command-line in my fork (yet).

I see. That seems quite wrong. It also removes license files which is not allowed under some licenses like Apache

Fun fact: run manifest doesn't capture the full capabilities of manifests!

Yeah, I noticed that and thought it was weird. I don't know why it does that (and Ghadi hasn't responded to any of my questions about it yet).

We're not redistributing our JARs so the license issue isn't a problem -- and depstar filters out a lot of other stuff too so it's pretty brutal in that respect.

The hard thing is proving that letting Maven potentially solve range constraints instead of using deps’ behavior for everything can’t produce a different final dependency solution 😕

Maven will produce a different solution, and we don’t want it

Ah. Yeah if you have a non-Maven pinning (or even just winning coordinate) for a dep, and Maven resolves something else, you can’t really back the transitive consequences of that out of Maven’s solution so you loose minimality for sure which can have other consequences.

The order independence of -M winning when -A and -M is present is probably worth documenting.

So yes IMO.

I would prefer to see it fixed, but documentation would be an improvement over the current situation.

Personally I'd like to see the behavior change. The reason why is this:

: I have a :dev alias that is only ever project-local. I use it for example to require my namespace when starting up an nrepl in cider. This requires a :main-opts key, making it of the -M type, but as per the documentation, only the last -M type is ever used. I also want to compose this with a debugging alias to say depend on and require spyscope with another alias. Currently this is impossible without putting that in the :dev alias and thus copying it to be project-local instead of a global alias.

Unless there is some other way to compose a global main-opts with a project local one that I do not know of

Maybe I'm just asking too much from this too new tool?

FWIW, I only ever use -A and I split aliases out so I run into this issue (downside: you need to specify multiple aliases for some things).

Perhaps @U064X3EF3 can weigh in here as I see he is the project lead. When i get home later I'll open an issue if only to document this edge case so other newcomers don't bang their heads like I did.

It is better to ask about whether it can change when things are still alpha, than later. It is really up to folks like Alex, Rich, and Stu Halloway on how they choose to make the tool work, so don't be surprised with the answer "doc enhancement, please"

My sense is that it is "by design" that aliases are combined in order, left-to-right and that -A:foo is just shorthand for -R:foo -C:foo -M:foo ... -- so the behavior you observe is intentional and likely considered to be already well-documented.

If you specify your project-local alias with -R and/or -C instead of -A then you'll get the behavior you want.

The confusing bit is that -M is documented as only the last one being used, but if -A is indeed shorthand for that, an -A after an -M needs to have a note mentioning that only the last explicit -M is applied, and -A is ignored.

The -A is not ignored -- the aliases are all combined left-to-right, but with :main-opts it's always last one wins.

But that is not the case.

-M:foo -A:bar, when both foo and bar have :main-opts keys, then foo wins.

Ah, gotcha. Here's why:

val="$(join '' ${resolve_aliases[@]})|$(join '' ${classpath_aliases[@]})|$(join '' ${all_aliases[@]})|$(join '' ${jvm_aliases[@]})|$(join '' ${main_aliases[@]})|$deps_data"

So -M is always applied last. OK, yes, that should be documented. Do you want to create a JIRA ticket for that (against the CLJ JIRA project I believe)?

I'm happy to create the ticket if you want me to.

I very much want to so others don't run into the headaches I did. I won't be able to do that until tonight or tomorrow though when I'm at my dev machine, unless you don't mind.

I'll go ahead and create it... against the website since it's really an error in the Reference page for the CLI

Thanks @seancorfield!

This is a bug, not a doc issue. Order matters, should be respected.

OK, good to know. So the shell script would need to expand each -A as it encountered it, adding the aliases as if all four were really specified explicitly?

Do you want a JIRA issue (and maybe a patch) against CLJ for that instead?

Jira yes, patch if you like. I suspect it affects the scripts too so may require some coordination

Ugh! Yes, fixing the clojure script would solve one side of things -- that's easy -- but tools.deps also needs to be fixed too. OK. JIRA for now. I'll look at a patch if I get enough free time but it's a bigger change than I had initially thought.

Thank you everyone.