• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
  • Paul Clapham
  • paul wheaton
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Piet Souris
  • Mike London

Clarification on Spring Boot project styles

Posts: 422
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's been silent here since late yesterday, so while I await more questions, let me clarify something about Spring Boot that I think a lot of people miss out on...

A lot of times when Spring Boot is demonstrated, it's done using the Spring Boot CLI and a tiny 60-character or so Groovy script (which I posted in another thread on this forum). That's a fun demo and is an extreme case of how simple Spring Boot can be, but it also turns away some developers who view it as a toy. They think that there's no way that they're ever going to develop and run production apps by writing really short Groovy scripts and running them on their production hardware by running something at the command line.

But to be clear, that's neither a toy nor is it the only way to develop Spring Boot apps. Here are the 3 main options available (and there are variations of each of these):

* Groovy scripts run through the Spring Boot CLI: Again, these are just plain, uncompiled Groovy scripts sitting in a directory. You run them with the CLI `spring run` command. You get all of the benefits of auto-configuration *plus* you get the benefit of some automatic import and dependency resolution. In other words, the CLI knows how to automatically resolve dependencies for some types and automatically add certain packages to the set of default packages so that you don't have to explicitly add import lines in the code. As I said, it makes for a great demo...but it doesn't mean that it's a toy. One way that it could be used in production is by placing the Groovy scripts inside of a Docker container and executing the CLI from the Dockerfile's entry point. You can also deploy these scripts to CloudFoundry with `cf push` and CloudFoundry will know what to do with them. And if you're worried about running tests, which is something that a conventional build normally does, there's also a `spring test` command to handle that for you. The only major downside with the CLI is that you can't use JSP for templates (but is that really such a bad thing?); you'll need to consider an alternative such as Thymeleaf, Velocity, or Groovy templates.
* Java (or any JVM language) code built with Maven or Gradle into an executable JAR file. This is a more familiar development model and more comfortable for most developers. You write Java code in your favorite IDE (Spring Tool Suite and IntelliJ IDEA both have excellent Spring Boot support) and use Maven or Gradle to build the code into an executable JAR. You get all of the benefits of Spring Boot auto-configuration, but you don't get the benefit of automatic dependency and import resolution like you would with the CLI. With an executable JAR file, you can deploy most anywhere that an executable JAR file can run, including CloudFoundry and within a Docker container. And because the servlet container is embedded in the JAR file (you choice of Tomcat, Jetty, or Undertow), you know you get a consistent platform no matter where it is run. (And I believe JSP is not going to work with executable JAR files here, the same as with the CLI.)
* Java (or any JVM language) code built with Maven or Gradle into a WAR file. This is the most familiar development model. This is essentially the same as building to an executable JAR file except that you have the option of deploying the app in a traditional way to an app server such as WebLogic or WebSphere. And you definitely get to use JSP if you want with WAR files. Oh...and if you want it is possible to build the app as an executable WAR file; that is, a WAR file that can both be deployed in a traditional way *and* be run from the command line. (Neat trick, but I'm iffy on what practical value it offers.)

There are variations for all of these, but these are the primary 3 ways to develop Spring Boot apps. Keep in mind that at no point is any code generated and the opinions imposed on your project by Spring Boot are concerning Spring configuration, not your application code.

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic