So I've two separate applications - one is REST Api written in java which is exported as a war. The other is a REACT javascript application which is rendered in a folder with 1 HTML, 1 CSS and 1 JS file.
Now my organization wants me to package the two applications in gradle and offer 1 single war for deployment.
Personally I think it's a terrible idea, but well, can't always choose.
My question is, can that even be done, if yes how can I do it. Important to note that it has to be a gradle build.
Theoretically, you should be able to package assets into your .war and have Tomcat (or whatever) serve them alongside your actual assets.
You should be able to place them alongside the WEB-INF folder at the same level. The container will serve them directly.
You probably want a build step that runs whatever JS things needs to run (minification, etc). Another build step could take the output of that and dump it into war.
Related
When creating production build with docker what is the strategy people uses about compiling and bundling the code.
So outside the docker world, I would create a build (using some sort of npm command) which will create a dist. code (without any source code, uglified and compressed javascript for e.g.) and then I point a web server to the dist folder.
In docker world where would you build the code, Is it in docker image or on host os and just copy the dist folder to the docker image? Basically I do not want the whole npm_modules and all source code files in the docker image/container.
Any idea how to achieve this?
Thanks
It sounds like you're worried about two different, valid, problems:
Ensuring an isolated/reproducible production environment.
Ensuring an isolated/reproducible build environment (for building #1).
You can achieve both with the approach you suggested - have the build steps run as part of your Dockerfile. But this has the disadvantages that you mention - you're left with all of your source/development artifacts at runtime, unless you take explicit steps to remove them all.
Docker introduced multi-stage builds to somewhat alleviate this issue - it effectively allows you to "squash" multiple layers into one. But it doesn't eliminate the problem of needing to explicitly clean up.
So in my experience, the most common solution is indeed to build your artifact externally, and then COPY it into your production image.
That solves problem #1, but not #2. So go one step further - build your Docker image inside a Docker container! CI platforms are increasingly supporting this approach as a first-class concept - see e.g. Circle CI's Docker executor.
In Docker, in general, you want to create an image of your software that contains all that is necessary for your Application to run on any machine. This is what Docker is used for: bind the Application and its dependencies into a single artifact so that it can run everywhere where Docker is installed.
The self-sufficient image is very handy when you use an orchestrator like Docker swarm. The orchestrator can run the container on any machine that is part of the network (i.e. the swarm) by pulling the image and starting a container. If nor the image neither the host contain all that it needs then the container fails.
There are cases where you need to change very easy the files inside the container as it runs, for example in development. In that case you mount a local directory from the host into the container (see volumes); in this way you just modify the files in the host and the modification is propagated immediately inside the container. Even in this case, your image should contain the files needed to run the Application on other machine; using a volume just hides them in the development environment.
I've got two projects which I've created:
A web UI built using webpack
A Vert.x webserver written in java built using Gradle
I want to find a way to bring the resulting build dir contents of the first project into the second as the webroot which will be server up using the StaticHandler.
Is anyone aware of a clean way to do this? I want to preserve the two git projects as they are because I like using the webpack dev server for development of the UI and it generally feels cleaner to have them separated.
I was looking at potentially using the bitbucket pipelines build on my repo, however bringing the assets generated by the first project into the build of the second is where I'm facing issues.
You could create a gradle task that before that depends on the jar task (so it runs before it) executes webpack compile into the resources directory. So when your jar task runs it bundles the compiled webpack code.
I want to use Google Closure Compiler(GCC further) for joining my js-files and compressing before deploy. It's ok, if I will need to run some script. But how can I write a file with options for GCC? I can only write a *.sh file with task.
Help me please. Also it will be great, if there is some tool, that can watch for changes in my local js folder and run that task.
Thanks.
There are lots of "make" systems that provide a command to rebuild your software according to a set of rules when one of the source files changes. GNU/Linux has make, Java has ant, CoffeeScript has cake, Ruby has rake, etc. Any of these can spawn a task that will compile your .js files. They all have fiddly syntax.
A system that detects file changes and automatically rebuilds, tests, and deploys everything when files change is called a "continuous build", "continuous integration", or "continuous deployment" system. The big one is Jenkins developed for Java.
It sounds like you want a fairly simple single-user combination of 1 and 2.
node.js is well-suited to running a job that watches for file changes and spawns build commands. It doesn't have a "standard" JavaScript build system or continuous integration system. But there are lots of projects out there, such as
ready.js
drip for node.js got a lot of coverage but I'm not sure its status.
the CoffeeScript language (that compiles into JavaScript) has a Cakefile system that can watch for script changes and run commands
I'm trying to decide between ready.js and Cakefile myself.
check out plovr. http://plovr.com/
You need to get node.js so you can write make files in javascript , that's the best way to do it.
I am in the process of converting an existing Rails 3.1 app I made for a client into a Backbone.js app with the Rails app only as a backend server extension. This is only a personal project of mine, to learn more about Backbone.js.
While setting up Backbone.js (using Backbone-on-Rails), I noticed I have some dependencies (like backbone-forms) that come from external sources and are frequently updated.
I've grown accustomed to using Bundler to manage my Ruby gems, but I haven't found anything similar for JavaScript files. I'm wondering if there is any way to do the same for Javascript (and possibly css) files.
Basically I can see three possibilities to solve this issue:
Simply write down all the sources for each JS file and check these sources from time to time to see what has changed.
Use some kind of existing "Bundler for Javascript" type of tool, I've been looking for something like this but have yet to find anything (good).
Since most of these JS files will be coming from Git anyway, use Git to get the files directly and use checkout to get the latest version from time to time.
I prefer the last option, but was hoping on some more input from other people who have gone this route or preferred some other way to tackle this issue (or is this even an issue?).
I figure the Git way seems easy, but I am not quite sure yet how I could make this work nicely with Rails 3.1 and Sprockets. I guess I'd try to checkout a single file using Git and have it be cloned in a directory that is accessible to Sprockets, but I haven't tried this yet.
Any thoughts?
You don't mention it in your alternatives, but ideally you should use something like Maven to manage your dependencies. Unfortunately, there are no public repositories for javascript files. This discussion lists some other options which might be of help to you: JQuery Availability on Maven Repositories
For now I've settled on using the Git solution combined with some guard-shell magic.
The steps I follow:
Create a dependencies directory somewhere on your local drive
Clone the repositories with javascript (or css) files you want to use in the app
Set up a custom guard-shell command to do the following:
group 'dependencies' do
guard 'shell' do
dependencies = '~/path/to/dependencies/'
watch(%r{backbone-forms/src/(backbone\-forms\.js)}) {|m| `cp #{dependencies + m[0]} vendor/assets/javascripts/#{m[1]}` }
end
end
Place the Guardfile at the root of the app directory
It takes some time to set things up, but after that, when you have the Guard running, and you pull changes into your dependencies, the required files are automatically copied to your application directory, which are then part of your repository.
It seems to work great, you need to do some work for each new file you want to include in the asset pipeline, but all that is required is cloning the repository in your dependencies directory and adding a single line to your Guardfile, for example for the backbone-form css:
watch(%r{backbone-forms/src/(backbone\-forms\.css)}) {|m| `cp #{dependencies + m[0]} vendor/assets/stylesheets/#{m[1]}` }
Also, the reason I added this Guard to a group is because I keep my dependencies outside the main application directory, which means guard normally doesn't check my dependencies directory. To make this work, I start up my main Guard processes using bundle exec guard -g main and use bundle exec guard -w ~/path/to/dependencies -g dependencies in a new terminal window/tab to specify the -w(atchdir).
I have worked in a web project with a heavy part on JavaScript, and I have noticed that there was no style how to use JavaScript. What unsettled me most is that everyone added files here and there, which resulted in a mess to organize and deliver them. Because this will be happen in every new project, I would like to have something like a styleguide for JavaScript. This styleguide should address the following questions:
How should JavaScript files be organized in the file system during development?
How should the JavaScript parts be separated from the HTML and other parts of the application?
How should JavaScript files be delivered in the real application, so that less code has to be loaded on each request and not too much requests have to be sent?
Is there something public available as a starting point for developing our own styleguide? What are your experiences in using your styleguide? Are developers following it easily, what are the simple and what are the difficult parts in it?
(I know, more question than one, but I'm interested in the whole story here. As a background, we have used JQuery and JSF, but I don't think that will have an impact on the answer.)
If you're doing heavy client side, you are probably going the MVC way.
So I'll answer your questions with the approach taken by the brunch. Brunch projects use MVC library Backbone.js, and have strict directory structure.
How should JavaScript files be organized in the file system during development?
src/
app/
collections/
controllers/
models/
styles/
templates/
views/
vendor/
build/
web/
config.yaml
Use Stitch to organize your files as CommonJS modules. Then you will be able to use require() to define dependency between them, as well as to combine them into one file later.
How should the JavaScript parts be separated from the HTML and other parts of the application?
build directory is used to store html; build/web is used to store javascript, images, and css.
How should JavaScript files be delivered in the real application, so that less code has to be loaded on each request and not too much requests have to be sent?
At the build stage, all JavaScript is minified and combined into one file (build/web/js/app.js), so that client will have to make only one HTTP request when he / she visits your site for the first time.
It's probably a good idea to make building process as easy as possible. Brunch does that by offering brunch watch command, which monitors filesystem for changes and builds code instantly with the help of Stitch and some other tools.
(It should be noted that during development brunch projects also use CoffeeScript as the primary language; it is transparently compiled by brunch before stitching the resulting JavaScript. However, this doesn't matter as long as file organization is concerned, and is out of scope of your question.)
For all JavaScript files definitely use a separate directory. Have as many files as possible semantically. One large constructor should correspond to a separate file. Never use filename prefixes where you can create a directory.
Unix-style directory structure is often found on GitHub:
src -- for the source JavaScript.
lib -- for libraries.
tests -- for unit tests.
bin -- for executables.
dist -- for compiled files.
For compiling we use a Makefile with targets for production and development. The production version is all of files JSHint`ed, minified and concatenated into one. The development target is generating a server-side script that includes all JavaScript files dynamically (for easy inclusion into HTML).
But generally it depends. We used a widget directory for one project. This widget directory had a set of separate widget subdirectories (e.g. slider, tabs, modal-window), each of which had the following layout (inspired by DOMLoader):
html -- for HTML templates.
css -- for CSS files necessary for the widget.
js -- for the widget JavaScript constructor.
Crockford has a few stylistic guidelines and the Yahoo exceptional performance site has details which might be useful to you.
I can recommend a book: JavaScript Patterns by Stoyan Stefanov.
I think one of the best book about javascript