it seems like there is some recent work in this direction in java land with javacpp and panama. does any of that look promising?

The most most promising stuff I've seen is some libraries the jruby guys have. jnr I think it is called. But I still found it to be pretty high friction it terms of figuring out dependencies to make it work. I'll evaluate Panama when it lands in a jvm

tnx

There have been various templates and sample applications published, but most I recall seeing were web server back end applications, sometimes with ClojureScript interactive front ends. If there were sample desktop applications published, there were definitely fewer of those (probably not 0).

At least as far as major libraries to consider, there is JavaFX GUI lib for Clojure/Java, and things like Electron with JavaScript that ClojureScript might work with.

A Google search for the terms clojure javafx turns up a Clojure wrapper library for javafx -- I did not notice if it had much example application code it referenced or included. Also a few web forum discussion about it, which would be good discussions to read through to see if anyone asked about, and or linked to, open source apps as examples.

There is also a Clojure/Java library called Swing that wraps a different Java GUI library, other than JavaFX.

There's a few macros in core that you could look at. Perhaps in spec too?

looks like the convention is * , so like for the macro foobar the function is foobar* . thanks!

That is one convention but there are even others used in core itself and certainly others used elsewhere, so don’t feel bound by that

The * functions are actually even more special in that they are the gateways into compiler special forms

It matters a lot whether you expect people to actively use both too. If so, I usually work harder at good names for both (like def (macro) and register (function) in spec 2)

I see, thanks @U064X3EF3!

you are right, I figured it out, I add to require the namespace from the symbol, and then everything started working as expected 🙂

Just a wild guess - if both src and src/java are indeed registered as source roots, you could end up with errors like "ns a.b has wrong path java/a/b.clj".

I've seen weirdness in editors from stuff like this

alright thanks, gonna follow re-frame template of src/{clj, cljs, java}/artifact/

FWIW, the author of shadow-cljs advocates against such splitting: https://shadow-cljs.github.io/docs/UsersGuide.html#_source_paths "It is not recommended to separate source files by extension (eg. src/clj, src/cljs, src/cljc). For some reason this is widely used in CLJS project templates but it just makes things harder to use."

And I tend to agree with him. It's a bit more pleasant to work with sources that are not split by file extension.

yet he doesn't provide an example of clj cljs and java fullstack project structure

how would i separate java packages from clojure, and where to define a line between backend and frontend

A middle ground seems to be src for , java for Java. Both at the project root. A bit asymmetrical, but also enjoyable?

> how would i separate java packages from clojure Why? I've used Java before, and IIRC I didn't have to separate anything. > where to define a line between backend and frontend Again, why? What purpose would such separation serve?

the purpose is having a structure to follow

If the Java code is intended to be called from Clojure, why not make it a separate project, build it as a Java project, and then just depend on it from Clojure.

But then I'm using CLI/`deps.edn` so don't expect to compile Java as part of a Clojure project 🙂

CLJ can have functionality that's used by both Clojure and ClojureScript (via macros), CLJC - same deal, only more that just macros could be used in CLJS. Java can be used by said macros. Everything is intertwined. Separation by file extension is no less arbitrary than separation by the number of lines in source files. Yes, the processing of said files is different. But it doesn't matter.

If you have to keep such separation in mind at all times, that's just extra cognitive load. An anecdote - I even store Python source files and ANTLR4 grammar definitions with the rest of the Clojure[Script] code. Works perfectly. And I don't have to think each time, what is located where.

Well, I have to, but in terms of packages. Which is a separation that makes sense.

@U2FRKM4TW, if you're putting .java and .clj in one source tree, does that mean you're not using deps.edn (based on the comment from @U04V70XH6)?

@UBRMX7MT7 No, it doesn't mean that. I'm gonna guess here and say that Sean meant that there are Lein/Boot plugins that compile Java for you, and that deps.edn doesn't have anything like it. That's true, but that doesn't prevent you from using Java in a deps.edn-based project. You can have a separate build step, you could integrate compilation into your app workflow manually, you could use https://github.com/ztellman/virgil. After all, that's more or less exactly what those Lein/Boot plugins do.

@U2FRKM4TW Thanks!

My biggest issues with Luminus as a beginner (this is a few years ago now) was that it was too complex for me to understand, and there was no easy way for me to integrate fixes that were in the original Luminus template I used.

As far as different design decisions, the things that aren’t covered by the different profiles that I would want to use are integrant (instead of mount) and deps.edn (instead of leiningen or boot) - most everything that I would want to use can be brought in as an extra profile.

As far as the bugs I ran into, I wanted all the bells and whistles right from the start and put a whole bunch of profiles in. There weren’t any direct conflicts but I think I was one of the first to try a particular combination and ran into some bugs. It’s been used by way more people by now and should be a lot more solid, but I would still err on the side of simplicity if you are just getting started.

I agree with Shaun here: Luminus is very complex for beginners -- when something goes wrong, which it usually does as they try to make changes.

If you’re looking for something to really understand the thought behind Luminus, https://pragprog.com/book/dswdcloj3/web-development-with-clojure-third-edition is written by the Luminus developer - reading the first and second editions of his book helped me a lot to understand where the design decisions came from.

Even the minimal template is pretty substantial.

Yeah, and when it goes wrong you have to start to learn how leiningen works in a lot more detail than should be expected of any beginner to Clojure.

I have nine years of production Clojure under my belt and I still think Luminus is "too much". It feels like Rails to me, and I never liked that, for much the same reasons.

(someone should really make you a Clojure cake for your 10th anniversary)

🎂

If you have some specifics of what kind of app you are trying to build, I bet you could get some good advice on where people would start. Biggest things in my mind is to try to keep it as simple as possible, make sure you have something that work well for configuration and keeping your passwords out of version control, and gear everything towards a good REPL workflow. There are different options for all of those and you will likely find something you really like after trying a few of them.

@U061KMSM7 Back to the original question: I'd want the template to use deps.edn instead and to not include anything not needed for the minimal web app to start up -- and have all the rest be optional.

(that means no Docker, no Procfile, no Capstanfile etc -- there's a lot of "noise" even in the minimal template project)

Well, I’m going to be handling a one-man contract, and in the past when I would ‘start from scratch’ I often found myself scrambling to add a library for some functionality I didn’t think I needed, figure out how to use it, then integrate it. Hopefully I’ve learned my lesson and won’t repeat that mistake.

Yes, I’d get rid of those extra files, and probably go with a straight clj based deployment. Maybe with capistrano? No Docker for me!

You'd still have to learn how all the libraries in the Luminus template work.

I’m not sure that using Luminus would actually solve that problem - it’s a lot harder to add new dependencies after that fact, so unless you pick the right profiles at the start you will still have an issue.

The base template has 25 libraries in the :dependencies vector 👀

And it's strange that the docs say Reitit is optional and it is added when you say +reitit but that is already listed in the dependencies.

Where I would use Luminus is if I knew what I needed, and when the documentation guided me to the same place I was looking to go (similar to the times when Rails and other large frameworks are great - when you’re trying to do what the template developers expected, you are probably going to have a smooth path to get there).

Yes, +reitit became standard, I saw the same thing. 🙂

As far as other changes, I would also never start with reitit as my first routing library - it is super complex and you have to understand way, way more than is necessary to do simple routing. Works great once you figure it out though 🙂

My base for a SSR (server-side rendered HTML) app would be Component, Selmer, Compojure, next.jdbc... I don't do cljs so I don't know what I'd want for that. Pretty sure I'd look at Shadow-cljs first. Reagent. Not sure what else.

I had one medium sized Luminus project that worked well, but that was a couple of years ago. So I need to refresh my memory and catch up on some new tech.

This project will be +reitit +postgres +re-frame +shadow-cljs +auth +site

In-house app. I’d use RoR except I don’t want to. 🙂

I’ve not tried Component yet, vs Mount.

I settled on Integrant with Aero, it is a nice combination when you get it working

Hmm, I’ll add them to my tech radar…

@U054BUGT4 psst, if you tried Edge and loved /hated it, I'd love some feedback (it's an integrant / aero starting point)

@U09LZR36F I haven't tried Edge, but I did look at it when it was first released and I think it was one of the reasons I took a look at aero.