Huh, and clojure.xml generates similar warnings as well. Feels strange.

Don't use clojure.xml, use org.clojure/data.xml instead.

@U2FRKM4TW What features of Capsule are you using? There are quite a few uberjar builders out there.

Yeah, I'm not using clojure.xml myself, but some thirdparty lib does. Interestingly, the traceback created by --illegal-access=debug is not very useful in that regard, but there's just one such lib that my project uses. I'll probably end up creating a PR at some point. Regarding features - no idea. The only reason I started using it is because it's alphabetically the first one among others that https://github.com/juxt/pack.alpha supports. And I just use it, it just works (and I haven't a clue on how). But given the nature of uberjars, I suspect that reflection is really useful for that, if not obligatory. Hence the question. I was about to ask you what you'd recommend for uberjars, but I see that you maintain depstar, so I should probably give it a try.

It will surprise no one that we use depstar at work to create all our production artifacts 🙂

I have an extremely low opinion of capsule, the layers of indirection they impose are silly if you only have java deps, and are not as well designed as docker if you have non-java deps

also the fact that capsule creates jars that can't be directly put on your classpath to run a repl that accesses the resources in the jar is simply offensive to me

with most uberjars java -cp uber.jar clojure.main gives me a usable repl, breaking that is frustrating

Thanks! Oh yeah, I stumbled upon the REPL issue as well.

depstar does it right, and capsule doesn't for my use cases

Certainly making it 100% free would increase it's usage, but would that make Datomic better? Would that foster more support contracts? Would the economic return for the hard work of creating the product be returned to its creators? I dont undstand the econmics enough... but as a user I wish I could use it everywhere with wild abandon.

Congrats. Hope it will work out great!

I have been looking for a schemaless datastore and the only thing that keeps me away from that are references across entities. Can you resolve / join them reasonably with Crux? I am especially interested in common stuff like entities per user.

Yep that works just fine but your traversal logic is in the application or library layer, since something has to be aware of the shape of your data. I store references as either IDs or "idents" [:entity/id #uuid "id123"] and then invoke crux/entity on that id or ident when traversing references. It is also in the application layer where you have to enforce that references are not transacted as nested entities (maps) and are instead stored as ids or idents. I think a common pattern for crux use is a layer in your application code that enforces your schema constraints - this is at least the design I landed upon. I am very happy with this trade-off because you get extreme agility in evolving your data system, combined with spec or malli at the data layer you can add on schema constraints as much or as little as you wish. For executing queries, in my application I am using pathom to perform the id->entity traversal, but I also created a pull api (https://github.com/dvingo/my-clj-utils/blob/master/src/main/dv/crux_pull.clj) that is client code on top of the base crux API, so you can use that if pathom doesn't fit your needs. Both of these solutions support graph traversal/unbounded recursion which as far as I can tell are not present in any storage + query system other than datomic

Thanks for your explanation, nice to hear that. I think a lot of database logic is mirrored in application code either way, so I never saw that as a big disadvantage. I tried datomic a few years back when it was pretty new and loved it, it's just that there was no real open source option that drove me away.