M
M
mystdeim2016-07-18 22:49:25
Java
mystdeim, 2016-07-18 22:49:25

How are Java EE applications deployed?

For Rails applications, there is a cool capistrano thing, you describe a "repept" and run it: dependencies are downloaded, code is downloaded from the central repository, database migrations are performed, you can do it up to synchronization of the ruby ​​version, just restart the necessary services if necessary - everything is simple and understandably.

It is interesting to see how things are in other camps.
Before that, I worked only with Java SE and used it only as an auxiliary tool. I wonder how applications are deployed to all sorts of wildfly and similar application servers, how zero downtime and database migrations work?
While playing with wildfly, I learned how to deploy an earnik to a local host using maven, the question arose of how to deal with deployment when you need to partially update, only one module?

Answer the question

In order to leave comments, you need to log in

1 answer(s)
V
Vladimir Smirnov, 2016-07-19
@bobzer

needs to be updated partially, only one module
Accordingly, this module should be a standalone Maven artifact. Typically, an EAR artifact describes building an application from other modules and configuration files. You should break the application into artifacts (usually jar/war) that are part of the EAR.
In general, when building for a production environment, it is more reliable to build the entire application (EAR in your case) as a whole. And when building for a developer environment, it is generally more convenient to use not the Maven collector, but the development environment. Idea, for example, perfectly understands the format of Maven configurations and can create its own artifacts based on them (and will strongly recommend doing this when pom.xml is found). If you collect artifacts using Idea, then even when building the entire EAR, only changed files will actually be updated, which speeds up the build process by orders of magnitude, compared to Maven. This is achieved due to the fact that Idea has its own version control and it knows what exactly should be rebuilt and what can be left as is. The greatest gain is obtained for exploded artifacts (which are not archived, but laid out in the form of a folder structure with files), because.
For each artifact, Maven Idea will create two versions of its artifacts - one packed and one unpacked (exploded). If your application consists of several modules, manual intervention in the generated artifacts may be required, since The exploded top-level artifact in the default configuration contains the sub-artifacts in compressed form. You will need to remove the packed version and insert the exploded version in its place. The downside is that when changing the Maven artifact, Idea will offer to regenerate its artifacts as well, all manual settings will be lost. But project topology settings change infrequently, so an extra minute of manual reconfiguration work can usually be neglected...
If you have just started experimenting with Java EE, then creating an EAR may be an unnecessary complication, because in many cases, a lower-level web artifact, the WAR, does the job of an Enterprise application just fine. In this case, a simpler structure is obtained, respectively, and there are fewer problems with setting up the assembly.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question