Nowadays almost everyone employ their favorite JS based framework while developing their dynamic web applications. There are dozens of client and server side UI frameworks around there, and you can be sure that you are going to be criticized about your choice it doesn’t matter which one you chose. Some will ask why it is not Angular, and some other will ask why it is Angular? We also employ Vaadin UI Framework in our projects as well. However, I still prefer not to employ any one of those frameworks during the trainings I give over java-egitimleri.com. My choice is still for JSP in order to teach fundamentals of web application development to my audience. I have some reasons for this;
- It is a lot easier to demonstrate building blocks of Web MVC architecture, explain how front controller pattern works
- You don’t need any third party dependency or any pre-configuration to make them running
- They can be modified easily at runtime, without requiring any recompilation, or server restart
My aim is not to deal with various UI gadgetry, and instead focus more on backend process of developing enterprise web applications during my trainings.
Trainings mostly contain Spring stuff, and Spring Boot is the framework/platform to melt down all those Spring, JPA/Hibernate and various middleware related theory into an executable and demonstrable artifact easily. However, Spring Boot doesn’t play nicely with JSPs in executable JAR format. They ask you either to switch to executable WAR format, and not use Undertow as web container, or employ another templating engine, such as Thymeleaf or FreeMarker.
Anyway, I was ok with switching into WAR packaging, createing src/main/webapp folder to place all those JSPs, and their static resources underneath, and keep up with embedded Tomcat. However, a few days ago, I questioned myself again, if there might be an alternative way to keep all those JSP and related stuff under src/main/resources, and came up with a little but invaluable information around the web. According to JSR-245 and Servlet 3.0 API, it is possible to place static resources within /META-INF/resources folder of JAR files. This means that, we can move our JSPs and their related static content into /src/main/resources/META-INF/resources folder in our Spring Boot projects!
I tried it immediately, and it worked without any problem inside my STS IDE. Afterwards, I decided to create an executable JAR and check if everything still works there as well. Unfortunately it’s not!
When I extracted executable JAR file, I noticed that Spring Boot Maven Plugin repackaged JAR content by moving everything under /BOOT-INF/classes folder including /META-INF/resources. Unfortunately, Spring Boot Maven Plugin has no way to specify excludes during repackaging.
The only viable solution is to create another simple maven project containing your JSPs and their related static content, under src/main/resources/META-INF/resources, and make it a dependency to your Spring Boot project. This might look a bit weird to some of you but this looks the only viable workaround to this repackage issue with the plugin, as the guys responsible with developing Spring Mave Plugin respond with suggesting moving into Gradle in case you are blocked with Maven 🙂