I have a pretty standard Ring application with some Compojure RESTfull endpoints. We also have a frontend application based on Polymer, Bower and Gulp. So I thought it would be nice to distribute this application in one package (which means having a build which will in the end produce a WAR file consisting of both backend and frontend part which can be uploaded anywhere without any other dependencies).
However I started to dig into the Leiningen and apparently there is no plugin which would support this need. So before I am gonna build something like that on my own, is there some other way how to do this? Or am I thinking about the problem in the wrong way?
P.S. The ultimate goal is to deploy application to AWS, I've done it already via elastic-beanstalk plugin and it seemd to me pretty smooth (just build the WAR, pass it to the plugin and it will take care about the rest).
I have built projects with similarities. I avoided using leiningen/lein-plugins to build the frontend and instead built it with webpack, while letting lein compile the clojure into an uberjar. The build artifacts from webpack were output to the resources path that was declared in project.clj and packaged into an uberjar. The web server was also bundled in the uberjar and was configured to serve from that path. I used luminus as a project template.
It seems like you could do something similar here. Use gulp to build the frontend and package into a war that can be deployed to elastic beanstalk. My build script from package.json was this: npm install && NODE_ENV=production webpack -p && lein uberjar.
So, you don't need to have a lein plugin to build your frontend. I found it easier to let another build tool do that work.
Related
I am deploying a React app on AWS Elastic Beanstalk. I bundle the app using webpack. However, I'm slightly confused about what best practices are from the production build process. Should I build the app locally (with NODE_ENV=production) using webpack, and then just upload the resultant bundle.js file, along with all node_modules to the Elasticbeanstalk instance? Or, should I upload all the source files, and run webpack on the actual cloud AWS server during deployment?
You should never build for production locally (unless you're the only developer).
Ideally, you have a build process that gets triggered manually or automatically from a git commit which then builds your project for production for you.
By using a centralized build process, you can then be sure that all your builds are built the same way (e.g. same node version, same npm or yarn version).
Both approaches are not really good to be honest. Local building is not a best way to build anything you want to have on production. You might have packages locally that may have inpact on what you're building. Same applies to the OS your doing it on.
And, again, same applies to the building during deployment. As the name of 'deployments' stands for, it's deploying. Just placing your application setup on the server so it may serve as it is supposed to.
That's the point where all CI/CD comes in. Having those kinds of solutions guarantee that each build is done with the same steps and on the same solution stack. No difference between each build is desired, because it allows you to assume that any bug or a change comparing to the 'desing' is because of the code, not environment it was build within.
Assuming that you're the only developer here (because you're asking for such a thing), CI/CD might be definitive overkill here, so just create shell script with steps and use Docker as the environment for build, so it stays the same between each build. That's the closest to the CI/CD option you can get without a hassle.
We're using the hosted build agent on VSTS to build and release our ASP.NET Core code to Azure App service.
My question is: can we run WebPack to handle front-end tasks on this hosted build on VSTS or do we have to do it manually before checking the code into our repository?
Update:
I'm utilizing the new ASP.NET Core Build (Preview) template that's available on VSTS -- see below:
Here are the steps -- out of the box:
For VSTS we're working on an extension, currently it's in beta phase, you can ask for a share.
Check the VSTS marketplace.
Check this github repo.
Webpack is definitively not a first class citizen for VS2015 and VSTS. Streamlining webpack for CI/CD has been a real headache in my case, especially as webpack was introduced hastily to solve dreadful performance issues with a large monolithic SPA (ASP.NET 4.6, Kendo, 15,000 files, 2000 folders). To cut short, after trying many scenarios to make sure that freshly rebuilt bundles would end up in IIS and Azure webapp, I did a 2-pass build. The sequence of VSTS tasks is as follows: npm install global, npm install local, npm webpack install local, npm webpack install global, build pass 1, webpack, build pass 2, etc... This works with hosted and private agents, providing you supply the proper path for webpack as webpack is installed in a different location in host and in private (did not find a way to chose the webpack install location for consistency). I scorch everything before starting the build. Also need to do these in VS2015 solution : (1) unload "built" folder, and (2) Add Content Include="Built\StarStar" in project file. The "built" folder contains the bundles and should appear greyed, otherwise more bad surprises and instabilities to deal with...
Build-Pass #2 task in VSTS BUILD allows to collect the fresh bundles generated by Build-Pass #1 and includes them automatically in the package to be published.
Without a second build-pass, collecting the bundles and merging them in the zip package is a nightmare, especially when you have 15,000 files to unzip then rezip (300 ms per file!!). Did not find file-merging capability that I could readily use in VSTS.
I have my hears to the ground listening for someone coming up with a more efficient CI/CD scheme for webpack. In the meanwhile, my 2-pass-build workaround is working flawlessly, but slow indeed.
I anticipate that the advances with ASP.NET core, Angular 2 and webpack will look into solving this elegantly.
I'm developing a Leiningen plugin. Actually, I'm working on a patch to an existing Leiningen plugin. I've made some changes, and now I want to see if they work.
What do I do?
I made these changes to support another project I'm working on. I'd like to point that project at my local working copy of the plugin to test my changes, but I don't see a way to do that.
Leiningen offers checkout dependencies, which solve this problem for dependencies, but not for plugins. Is there an equivalent for plugins?
Publish your forked version with a different group-id, either to clojars or to your local repo (with lein install). Then, in the project that uses the plugin, depend on your new artifact-id instead of the public one.
I need to deploy a production version of a web application. So far, I've been testing it with mvn jetty:run. I've used actual jetty installations before, but they seem only necessary when you want to serve multiple wars on the same web server. In some ways this is the most staightforward however (mvn package and copy it over).
My other options are to create a runnable jar (mvn assembly:single) that starts a server, but I need to tweak the configuration so that the static content src/main/webapp is served and the web.xml can be found.
I've also read about a "runnable war". This might avoid the src/main/webapp problem since these files are already laid out in the warfile. I don't know how to go about doing this, however.
I could also stick with mvn jetty:run, but this doesn't seem like the best option because then the production deployment is tied to code instead of being a standalone jar.
Any opinions on the best way or pros and cons of these different approaches? Am I missing some options?
The jetty-console-maven-plugin from simplericity is simple to use and works great. When you run mvn package you get two wars--one that is executable. java -jar mywar.war --help gives usage, which allows a bit of configuration (port, etc.).
I'm not that familiar with maven, but this is how we approach deployment using embedded Jetty:
We create a single-file JAR with the embedding jetty app and the necessary lib jars packed.
We deploy the static content in a WAR file (which you can package into the JAR as well). Everything is generated by an ANT file that:
1) Build the static files WAR (this also creates the web.xml)
2) Copies the WAR into the application resources
3) Compiles an executable JAR
To get the embedded Jetty to "find and serve" your static files, add the war with a WebAppContext to the Jetty handlers:
Server jetty = new Server(port);
HandlerList handlers = new HandlerList();
WebAppContext staticContentAsWar = new WebAppContext();
staticContentAsWar.setContextPath("/static/");
staticContentAsWar.setWar(resource_Path_to_WAR);
handlers.addHandler(set);
jetty.setHandlers(handlers);
jetty.start();
HTH
How can I configure a Tapestry5 project to run standalone (via java -jar) with embedded Jetty?
I'm looking for a short "recipe" regarding Tapestry5, Jetty, configuration of servlets/ handlers/ whatever is needed to connect the dots...
I've seen a few dots: How to Create an Executable War, Configuring Tapestry (ref Tapestry as servlet filter)
Edit: I'm thinking about a standalone running webapp due to server circumstances. It doesn't have to be embedded Jetty, but I can't rely on a stable appserver. Still looking for a recipe, though, so I don't spend much time on dead ends...
Also, I'd like for Jenkins (Hudson) to be able to stop and start the server automatically when deploying updates - I don't know if that influences what I can do with Jetty, f.ex.
Well, i believe this is a general "how to run a war question". Assuming you indeed have a war, you can use jetty or winstone to "run" it - see :
http://winstone.sourceforge.net
and
http://www.enavigo.com/2008/08/29/deploying-a-web-application-to-jetty/
In the first case, you can directly do
java -jar winstone.jar --warfile=<warfile>
https://github.com/ccordenier/tapestry5-hotel-booking/
<-- Check its maven build
http://tapestry.zones.apache.org:8180/tapestry5-hotel-booking/signin
I did some digging, and this is the short recipe I basically ended up following:
Start with the Maven Jetty plugin as configured in the pom.xml of the Tapestry 5 archetype
Add the stopKey and stopPort attribute to Maven Jetty plugin configuration
Let Jenkins CI run maven target jetty:stop and then clean install
Let Jenkins run shell script mvn jetty:run &
Voila - my Java app is up and running with automatically updated code, without any appserver.