I've seen the GWT Expenses app from GWT SDK is using single module structure.
Is this a best practice? Are there any cons in having the project split into multiple maven modules, i.e:
client
shared
server
The GWT compiler and DevMode don't really care about how you structure your build system as long as all of the client and shared resources are available on the GWT classpath and the server components have been compiled into the webapp's WEB-INF/classes directory (or lib/foo.jar) if you're using DevMode's built-in Jetty server.
Related
How to integrate the Angular 5 into existing J2EE application and what will directory structure for the same .
Best practice is to create a separate Frontend WAR module which includes the Angular app (directory structure: does not matter).
In the Maven or Gradle build of that module, have it build the Angular app and then copy the resources to the static web resources directory, so the built Angular app gets included as static resources in the WAR.
For Maven, use https://github.com/eirslett/frontend-maven-plugin
For Gradle, use https://plugins.gradle.org/plugin/com.moowork.node
Advantages:
the Frontend WAR module can be integrated into the EAR, and therefore be deployed along with the backend
the Frontend WAR module can be built in parallel to the other modules (which significantly decreases build time on parallel builds)
I have a Maven component service that I package up as a WAR file. I would like to create another Maven project that builds a fully deployable Jetty container with a few custom configurations and contains my component service in it so that I can test my WAR or even deploy it. My questions for this scenario are:
Is it common to want to keep the WAR build separate from the distribution build? My thoughts behind doing this is that someone may not want to use my custom configured Jetty container. Maybe they want to create their own build with Tomcat or something else.
If this is a common thing to do, what packaging type should I use for the custom Jetty container project? It seems weird to me to use JAR or WAR since that isn't the actual artifact that ends up being built. And using "pom" packaging seems equally strange since I was under the impression that that is used for parent projects of submodules.
Ad 1. Yes, this is how I usually structure the project. There is an app project which is a container for application and a separate deploy project to handle the infrastructure. Regardless if it's building a container image, deploy to app server or whatsoever.
You can see it in an example project I've once created for a Devoxx presentation.
Ad 2. Default packaging (hence jar). If all you have in a project is a pom.xml (without any classes), no additional jar will be created nor installed. In the project I've mentioned the pom.xml contains only docker image creation 'logic'. In your scenario it will be jetty related plugin. No additional artifacts will be created.
I have created two separate maven modules (let's call them MODULE1 and MODULE2) which are submodules of a third integration module (SUPERMODULE).
MODULE1 and MODULE2 are both Spring Boot Web Applications. What I'm trying to achieve is to start (not build) both projects / web apps by means of SUPERMODULE.
As I see it, there are two options:
Deploy them both to the same tomcat server (probably the better & more interesting solution)
Deploy them to different tomcat servers with different ports
I found no viable example to achieve either one of these options (... by means of a single maven integration project). Hence, I would be glad if someone could point me into the right direction - or are both possibilities bad practice?
You said :
Deploy them both to the same tomcat server
(1) Build automation software
Any Build Automation tool (Jenkins, bamboo...) would allow you to create a job that deploys both your wars to tomcat (the same server or different server, you can setup your job as you wish).
Do you use an automation software ? I believe that would be the best the solution / best practices.
(2) Build an EAR - Deploy to Tomee
You said:
What I'm trying to achieve is to start (not build) both projects / web
apps by means of SUPERMODULE.
What you are really describing is an EAR!
I'll describe the idea, however, it seems Spring boot does not play well with EAR: Spring Boot EAR Packaging and https://github.com/purple52/spring-boot-ear-skinny-war
Since your 2 submodules are spring boot app, you could:
build the submodules as WAR
have your Supermodule build an EAR
include both WARs in the EAR (maven dependencies)
this however implies that you use (for instance) Tomee instead of tomcat (is that an option for you?).
as mentioned above, after some research it seems a spring-boot war does not work when packaged inside an EAR. The SpringServletContainerInitializer isn't called. So this would not be an option at the moment.
I am new to Spring MVC and I have now come accross tutorials that explain how to deploy your web project as a .jar. My IDE is the Spring Tool Suite. I have always used .war + Apache Tomcat.
Can someone elaborate a bit from the practical point of view why to use .jar instead of .war? Any problems to be aware of?
edit: other answers are welcome too
Spring Boot uses fat JAR packaging where is embeds Servlet container with all dependencies into this single JAR.
If you are using Maven, it uses spring-boot-maven-plugin to package the project.
Practical usage of this approach is simple. Ability to easily run Srvlet based Spring application from command line with externalized properties. Such configuration enables powerfully orchestration possibilities which are often used in modern enterprises in so called Microservices or SOA architecture.
There is group of people out there (including myself) which believe that deploying various WAR files of unrelated applications into single Servlet runtime is not very good idea.
So fat JARs are handy for separate Servlet runtime per application deployment.
About having .jar and Tomcat + .war on the same machine, it is possible and I use this. This may be not cool but I had a .war application running in a tomcat server before the rise up of spring boot. Now my new apps are spring boot apps, and we are migrating our architecture to SOA concept, but we can't change the tire with the moving car. The main application, the WAR is running in a tomcat server and the others (.jar) are self contained ( embedded tomcat ), each one running in a different port. It was the most viable solution available for us by the moment.
I am deploying the ear file each time when i making a changes as my project is multi-module and it is really tedious to upload/deployed the entire ear again in Jboss 7.Is there any way to replace only the changed jar/war/files in the already deployed ear in jboss without deploying the entire ear file again.
Thanks.
You should consider using JRebel - it allows reloading changes. After you compile any class it will automaticaly reload it, supporting modern frameworks (like reloading spring beans, etc) and application servers (JBoss included). It works as a java agent. You will find more details on producent site: http://zeroturnaround.com/software/jrebel/features/
To introduce JRebel in Maven project you just need to add jrebel-maven-plugin