OK, I am building an uberjar for the untangled/todomvc app and a lot of namspace references don't match the final locations in the jar. todomvc.system ends up in server/todomvc/system, etc. I could go through and fix them but I want to maintain some continuity with the original code. I know this is a newb question, but I have spent some time researching and it's time to humble myself and ask.
I now realize that this is problematic and that I may have to either move stuff in the final jar or fix references. Maybe I can control lein better in the creation of the uberjar.
@fragmus so you git cloned the code and are now making an uberjar? and things ain't lein'n up?
well - the original app is wonderful and I want to run it on heroku as an uberjar; their buildpack for clojure makes one automatically BUT yeah the stuff is structured in the jar just the same as in github which is different than the namespace references. I am writing a hack that expands the jar and moves a few things and re-creates the jar. I call it jarjar because everyone will hate it.
Well jarjar seems to work; My process came up on heroku. The virtue of jarjar is that I can track the original untangled/todomvc project and just have a few things different rather than moving a lot of stuff.
@fragamus I can't think of a reason that you couldn't move stuff around so they match.
@fragamus I just checked out master on todomvc and uberjar works perfectly. Sounds like you messed with the project file.
my guess is you might have been triggering a pom generation and a maven package possibly? I think you have to tell heroku to use lein itself...I've done it before and don't remember having that problem.
I just found the project I have deployed there.
I’m using the clojure buildpack, this project and Procfile:
and the content of src/server/config/prod.edn is { :port :env.edn/PORT }
I’m deploying to heroku through a git remote
I have a vague memory of having to be sure :min-lein-version
was set, or it used too old of a lein…perhaps that is the problem
Yeah, I just looked through my old build logs. That was exactly my problem early on.
I just added an appendix to the Dev Guide on this. on develop and master…will deploy live asap
http://untangled-web.github.io/untangled/guide.html#!/untangled_devguide.Z_Deploying_To_Heroku
Trying to apply all of this to deploying untangled-todomvc on heroku.
should figwheel and figwheel-sidecar be a dev dependency and not an actual dependency? (completely guessing... take it for what it's worth)
just basing my comment off the figwheel-template example. https://github.com/bhauman/figwheel-template/blob/master/src/leiningen/new/figwheel/project.clj
you can see the dependency for sidecar is only in the dev profile, line 101
@fragamus One of your namespaces is asking for figwheel de stuff, AND is on your production build classpath. Make sure you don't have your user namespace as part of your primary source paths. You need to learn about the tools. None of these are Untangled issues.
you might find that adding :verbose true
to your cljs build might help with the error messages.
but in this case, I just suspect you have your dev user REPL namespace on the source path of your uberjar build
no, I even commented out all such builds
I will figure it out
git grep figwheel
something is asking for figwheel stuff in your production build
ok i shall look for that
Caused by: java.io.FileNotFoundException: Could not locate figwheel_sidecar/repl_api__init.class or figwheel_sidecar/repl_api.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name., compiling:(user.clj:1:1)
means that your user.clj namespace was attempted to be compiled, and that it has a require for sidecar repl
BUT, in production, your user.clj should not even be present
your problem is in your project.clj file.
your source path is including wherever user.clj is...OR you moved user.clj into your production source
either way you're getting code that is not meant for production into your production uberjar, and then when it tries to compile it tries to pull in dev-time stuff
which won't be there, because your classpath for production should not include it
:source-paths ["dev/server" "dev/watcher" "src/client" "src/server" "specs/client" "specs/server"]
is wrong
should be "src/server"
then in your profiles, put the other stuff on the source paths
https://github.com/technomancy/leiningen/blob/master/sample.project.clj
test source goes under :test-paths (specs)
the dev stuff never goes on anything in the top-level source-paths
So, in :profiles { :dev { :source-paths [...stuff for dev only...]}}
The todomvc project should probably be fixed. I didn't realize it did that.
yeah https://github.com/untangled-web/untangled-todomvc/blob/master/project.clj
Yeah, I see it
sorry about that
no worries I am just thrilled
That was built early on, mainly by a junior dev
I love this stack so much
never have gotten back to it for review. Untangled-template should be in better shape
@fragamus I'm glad these problems have not killed your enthusiasm 🙂
I'll update the master branch on todomvc to keep ppl from having similar problems with it...
@fragamus There is also not a main in todomvc
I guess you added one
so, fixed source paths, I don't have time to add an uberjar to that and test it...but at least it isn't as misleading anymore
i made a main for it yeah but I started over today... I'll got find that and add it to my fork
I seem to remember documenting what all the files/folders and such are for somewhere
probably in the doc for the template
yeah...that README.md
hm...in fact, that also include Heroku instructions
also just verified that this is set up properly for Heroku out of the box
Hi everyone. Happy New Year! I have a question. In Untangled is there a figwheel for the cljs side, and then a ring server for the "clj serverside" ? I am trying to create the scaffolding for a project that can seamlessly use (dom/render-to-string ..) and it seems like having a back-end server that runs off ring & http-kit with routing (bidi or compojure) and then having a client-side solution (via cljs) seems to be the best way. In this way, though, in production I'd only need the server to run, not a figwheel process to host my cljs as well, right?