16

I have a Java web project that uses Maven standard directory layout: java files gets into java (actually: /src/main/java), resources into resources, web content into webapp.

Then we wanted to improve our web layer, by adding bower, sass, gulp etc. Our gulp build compiles scss, minimize javascripts, optimize images etc, everything what you would expect. But this introduced 1) another build tool, gulp and 2) generated files by gulp.

Question is how to organize such project? One way could be:

(A) gulp builds into webapp folder

In this solution, all javascript,images,scss files are stored in /src/main/assets and gets build into the /src/main/webapp. Both sources and gulp-generated files gets committed to the git. The gradle build is independent from gulp, and it is ok for the users that does not have gulp installed - like those who needs to work only on backend. Also, CI servers does not depend on gulp stuff.

(B) use gulp from gradle during build

In this solution, gulp is called from gradle. Gradle therefore builds everything. And you must use gradle every time when you want to try something. Also, every developer needs to have gulp installed, what may be a problem for developers using windows (as i've been told). Also CI server should know how to run gulp.

My team is torn between these two options. Does anyone have any working experience with either of these solutions?

igr
  • 10,199
  • 13
  • 65
  • 111

4 Answers4

10

I'm currently using Java + Grunt + Maven. I've found there are two ways of packaging your frontend with your backend and the same will certainly apply to Gulp.

In the end it's up to what's best for your project/team. From my experience I usually use option B when working with others since the decoupling is easily worth the other issues. When I'm doing my own side projects I always go for option A because it's just easier to launch one webserver and to run a local environment closer to what DEV/PROD is like.

A) Put your frontend into the webapp folder (ex. https://github.com/kdubb1337/maven-grunt-webapp)

Benefits - You can launch your backend and do development all in one place and working with Spring security is a snap, even without OAUTH. Fewer issues working with two webservers up on your local environment when they would normally be bundled into one port on other environments.

B) Keep your frontend in a different folder, or even in a different repo that you clone into the root folder of your backend repo. (ex. https://github.com/kdubb1337/maven-grunt) see the 'yo' folder

Benefits - Fantastic decoupling so front end developers can live in joy without having to even install java locally or worry about recompiling your backend. Works great if you want Travis (or your favourite CI app) to do unit tests on the backend and the frontend.

EDIT I've found this awesome plugin you can use with maven/gradle to build the frontend https://github.com/eirslett/frontend-maven-plugin. Seems like the way to go, will be refactoring my starter projects with this guy for grunt and gulp

Erich
  • 2,743
  • 1
  • 24
  • 28
9

The current best practice here is to treat your frontend build as a separate project and put it in its own Maven or Gradle module. Have your Java build system invoke the JavaScript tooling (e.g., with the maven-exec-plugin) and save the output into the appropriate directory in target or build. Bundle up the results in a jar and serve off the classpath.

If you're using Bower, you only need the base Node install on your CI server, and your Java build can invoke the necessary build process from there, fetching JS packages as needed. Don't forget to (1) use --save and (2) exclude the JS modules directory from source control.

In addition, I suggest looking at RaveJS, which manages your JavaScript build and keeps you from having to configure watchers and such during development.

chrylis -cautiouslyoptimistic-
  • 75,269
  • 21
  • 115
  • 152
  • How developers uses this every day? For example, how do you prepare the exploded folder and put everything inside, so they dont need to restart the server on every javascript change? – igr Sep 16 '14 at 08:49
  • You set up the server to serve out of the JavaScript directory. This is pretty easy in Spring MVC, and I know that running in Eclipse, it's all set up automatically. If you want it to run without needing an IDE to manage the classpath, have the profile that puts you in dev mode (no caching, etc.) also set the server's lookup path to include the `file:` URL of the on-disk repository. – chrylis -cautiouslyoptimistic- Sep 16 '14 at 13:18
  • Old post but still valid. To get an exploded WAR dir to update you have a few great options: gulp.watch to copy them on change, or if you're using an IDE they have a on change copy command. IntelliJ will copy resources when the IDE loses focus. Or you could use a File Watcher. Lastly, you could not ever copy and use a symlink on the folder(junction) or a hard link on the files into the exploded war directory. then it'll always be up to date. – Andrew T Finnell Oct 04 '16 at 22:14
4

My recommended best practice is using the com.github.eirslett.frontend-maven-plugin (or the maven grunt plugin) to call the grunt/gulp build from mvn (in process resources goal). When CI builds, it's all integrated, even npm etc can be installed in mvn's target so you don't have bother to configure your CI server for npm.

When developers build, then mostly still just use one maven command. For JS/CSS/HTML developers, after mvn clean install, they can run grunt/gulp "watch" in the background to get their JS changes reflected immediately in the browser without incurring any maven overhead (just the wicked fast gulp/grunt tasks).

Michael Bushe
  • 1,503
  • 16
  • 16
0
  1. Deploy the UI components on default Tomcat webapp directory.
  2. Deploy the class files on "wtpwebapps" (default directory for uploading war through eclipse) directory.

Setting Eclipse

  1. Go to server tab, open properties for tomcat
    (source: scotch.io)

  2. Make sure, the location should be [workspace metadata]

  3. Then double click on tomcat to open Tomcat overview.
    (source: scotch.io)

  4. Set server location to "Use tomcat location".

Grunt/Gulp Setting

  1. Use the copy task to copy the build UI file to<tomcat installation directory>/webapps/<contextRoot>/

https://pub.scotch.io/@ankur841/eclipse-tomcat-deployment-with-gruntgulp-build

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
ankur kushwaha
  • 458
  • 3
  • 9