What should be included in a deployable Java build

A deployable Java build should contain everything the runtime needs to start your application cleanly, while leaving out source files, local-only settings, and temporary build artefacts. In a managed hosting environment with a control panel such as Plesk and a Tomcat-based service like My App Server, the quality of the build package matters as much as the Java code itself. A correctly prepared build is easier to upload, easier to test, and less likely to fail because of missing dependencies, wrong paths, or environment-specific files.

For Java hosting, the most common deployable format is a WAR file, although some applications use a JAR for standalone JVM execution or a custom directory structure for a private Tomcat setup. The exact output depends on the framework you use, but the same principle applies: the build should be self-contained enough for deployment, yet still aligned with the target Java version, servlet container, and hosting limits.

What a deployable Java build should contain

A deployable Java build usually includes compiled application classes, dependency libraries, resources, and deployment descriptors. If the application is meant for Tomcat hosting, it should also include the correct web application structure and any framework-specific files required at runtime.

At a minimum, a deployment-ready build should contain:

Compiled bytecode under WEB-INF/classes for a web application, or inside the executable JAR for a standalone app.
Dependency JARs under WEB-INF/lib for WAR deployments, unless your build tool packages them differently.
Application resources such as configuration templates, properties files, XML descriptors, images, and static assets.
The correct deployment descriptor where needed, for example web.xml in older or more explicit servlet-based applications.
Framework-specific initialization files, such as Spring configuration, Hibernate mappings, or JSP tag library descriptors.

For hosting platforms that let you install and manage your own Apache Tomcat or private JVM inside a shared account, this structure should be predictable. A well-formed build reduces manual correction inside the control panel and makes service restarts, version changes, and redeployments safer.

Core files and folders in a deployable WAR

If you are deploying a web application to Tomcat, the WAR file is the most common package. A typical WAR contains a specific directory structure that tells Tomcat where to find classes, libraries, and web content.

Required structure

WEB-INF/ — protected runtime configuration area.
WEB-INF/classes/ — compiled application classes and packaged resources.
WEB-INF/lib/ — third-party JAR dependencies needed by the application.
webapp root — public files such as HTML, JSP, CSS, JavaScript, and images.

Depending on the framework, the build may also include:

WEB-INF/web.xml for servlet mappings and deployment metadata.
META-INF/ for build metadata or manifest information.
JSP files in the web root or in application-specific folders.
Static resources under folders such as assets, static, or resources.

When deploying through Plesk or a similar control panel, the application package should already be in this shape before upload. If you need to adjust the package manually, do it before the final deployment step, not after repeated failed restarts.

What to include from your build tool output

Most Java projects use Maven, Gradle, or another build system. These tools produce output directories that may contain both necessary deployment files and items that should not be shipped.

Typical Maven output

For Maven-based projects, the deployable file is often generated in the target/ directory. The actual deployment item may be:

a WAR file, such as myapp.war
an executable JAR, such as myapp.jar
a unpacked directory generated for testing only

In most hosting scenarios, the WAR file is the cleanest option for Tomcat. It already includes compiled classes and libraries in the expected layout.

Typical Gradle output

Gradle commonly places build artefacts under build/. Depending on the project type, you may get:

build/libs/*.war for web applications
build/libs/*.jar for standalone services
supporting files used during the build process, which should not be uploaded

The file to deploy is usually the final archive, not the whole build directory. Uploading the entire output tree can create confusion, waste disk space, and expose temporary files that are not meant for production use.

Files that should not be included in the deployment package

A deployable Java build should be lean. If you include the wrong files, you may increase the archive size, leak secrets, or create startup conflicts on the hosting account.

Exclude these common items

Source code folders such as src/ and test sources.
Local IDE files from IntelliJ IDEA, Eclipse, or VS Code.
Build caches and temporary directories.
Development-only configuration files.
Environment secrets, API keys, and database passwords in plain text.
Duplicate dependency JARs that are already provided by the container or platform.

In a managed hosting environment, configuration should be separated from code whenever possible. If your application needs database credentials, use the hosting control panel or environment-specific configuration methods instead of hardcoding values into the build.

Dependencies: package them correctly

One of the most common causes of deployment failure is missing or duplicated dependencies. A deployable Java build should contain the libraries the application truly needs, but not unnecessary extras.

Best practice for web applications

For a WAR deployment, application-specific libraries normally belong in WEB-INF/lib. These are loaded by Tomcat together with your application.

However, avoid packaging:

libraries that are already part of the servlet container
multiple versions of the same dependency
testing libraries
compile-only dependencies that are not needed at runtime

This matters especially on Tomcat hosting, because container-provided libraries can conflict with bundled versions. If the application was built against one version but the server loads another, you may see class loading errors or unexpected runtime behavior.

When to use a shaded or fat JAR

For standalone Java applications running under a private JVM, you may choose to build a shaded JAR or fat JAR that includes all runtime dependencies. This can be useful when the app is started directly rather than through Tomcat.

Still, for hosted Java web applications, a WAR file is usually a better fit because it matches the server model more closely and keeps the deployment easier to manage through Plesk or the service controls provided by My App Server.

Java version compatibility and target bytecode

A deployable build must match the Java version available in the hosting environment. This is especially important when using a hosted Tomcat instance or a private JVM with a selected Java release.

Check the target version

Make sure your build targets a bytecode version that the runtime can execute. For example, if your hosting service runs Java 17 and your application is compiled for Java 21, the application may not start.

Before deployment, confirm:

the Java version used during compilation
the Java version selected in the hosting control panel
any framework requirements that depend on a specific JVM release
the servlet API level expected by the application

In a Plesk-based Java hosting setup, the ability to choose or install a specific Tomcat and Java combination is useful, but the package still needs to be compiled for the correct target. A correct build does not compensate for an incompatible runtime.

Configuration files: include what the runtime needs, not what the developer used

A deployable build should contain runtime configuration, not local developer settings. This distinction is important for hosted deployments, where the server environment is different from your workstation.

Include

default application properties used at runtime
database connection templates if they are designed to be overwritten
framework configuration needed for startup
log settings that are safe for production use

Do not include

local file paths from your computer
machine-specific certificates unless explicitly required
development database URLs
hardcoded credentials
debug-only settings that produce excessive logs

For hosting platforms, the best pattern is usually to externalize secrets and environment-specific values. This makes redeployment easier and avoids editing the archive every time a password or endpoint changes.

Static files and templates

Web applications often depend on JSP files, HTML templates, CSS, JavaScript, and images. These are part of the deployable build if the application serves them directly.

Keep the content organized

Put public files where the web container can serve them.
Keep JSP files in locations allowed by your application layout.
Store reusable templates and view fragments in a consistent structure.
Verify that case-sensitive paths match the hosting file system.

This last point matters because many hosting environments use Linux file systems, where Image.png and image.png are different files. A build that works on Windows may fail after deployment if file names or paths are inconsistent.

Deployment checklist before uploading to hosting

Before you upload a Java build to a control panel or Tomcat service, review it against a simple checklist. This avoids repeated restart cycles and makes troubleshooting easier.

Confirm the build output is the final artifact, not the full project folder.
Check whether the application should be packaged as WAR or JAR.
Verify the Java target version matches the hosting runtime.
Ensure all runtime dependencies are included in the correct location.
Remove source code, tests, and local IDE files.
Move secrets and environment settings out of the package where possible.
Test the build locally in the same application mode used in hosting.
Check that JSPs, static files, and resources are present and correctly referenced.

If your hosting platform provides controls for starting, stopping, and redeploying the service, use them after uploading a clean package. A valid build plus a clean service restart often resolves issues that appear to be application errors.

How this applies to My App Server and Plesk-based Java hosting

In a Java hosting setup based on My App Server, you can often install and manage a private Tomcat instance or JVM from the control panel. That makes the build format especially important, because the deployment target is intentionally flexible.

A good deployable build helps you:

upload a WAR or application package with minimal manual changes
choose the right Java version for the app
restart the service safely after updates
keep application libraries separate from the host environment
avoid clutter in the hosting account

This model is well suited to small and medium Java web applications, including JSP sites, servlet-based applications, and lightweight private JVM workloads. It is not meant to replace enterprise-grade application server management or heavy clustered architectures, so the build should be practical, portable, and straightforward.

Common mistakes that break deployable builds

Many deployment issues come from packaging mistakes rather than code defects. Here are the most frequent problems.

1. Uploading source instead of compiled output

Tomcat cannot run raw source files. If the archive contains .java files but no compiled classes, the application will fail to start.

2. Missing runtime libraries

If the build tool marks a dependency as provided, but the container does not supply it, the app may fail with a missing class error.

3. Wrong Java target level

Compiling on a newer JDK without setting the correct target can produce bytecode the hosting JVM cannot read.

4. Packing local-only config

Files that point to local paths or local databases often break immediately after deployment.

5. Including unnecessary files

Extra files make the package harder to inspect and may expose data that should never be deployed.

Practical example of a clean deployable package

For a typical servlet or Spring-based web app deployed to Tomcat, the final package should look conceptually like this:

application classes compiled and placed under WEB-INF/classes
third-party JARs placed under WEB-INF/lib
JSP pages and static assets included in the web content area
runtime configuration files included only if they are meant for deployment
no source folders, no test output, and no editor files

If you build a standalone service instead, the package may be a single executable JAR with dependencies included or resolved at startup. In that case, the same rules still apply: only runtime-relevant content should be part of the deliverable.

FAQ

Should a deployable Java build include source code?

No, not unless you have a very specific reason. A deployable build should contain compiled output and runtime resources, not the full source tree.

Is a WAR file always required for Java hosting?

No. WAR is the usual choice for Tomcat-based web applications, but standalone JVM services may use an executable JAR instead. The correct format depends on how the application is started on the hosting platform.

Should I include all dependencies in the WAR file?

Include the dependencies your application needs at runtime. Do not include libraries that are already provided by the container or libraries used only for testing and development.

What happens if I compile with a newer Java version than the server supports?

The application may fail to start because the runtime cannot read the newer bytecode. Always match the target JVM version to the hosting environment.

Can I edit the package after uploading it to Plesk?

In most cases it is better to fix the build locally and redeploy a clean package. Manual edits on the server can create inconsistency between environments.

What is the safest way to manage configuration?

Keep environment-specific settings outside the build where possible. Use external configuration, hosting controls, or variables instead of hardcoding secrets into the archive.

Conclusion

A deployable Java build should be complete, compatible, and focused on runtime needs. For Java hosting with Tomcat or a private JVM, the right package normally includes compiled classes, required dependencies, web resources, and any necessary deployment descriptors, while excluding source files, local settings, and temporary artefacts. When your build matches the Java version, the container layout, and the hosting workflow, deployment becomes faster and much more reliable.

In a Plesk-based Java hosting environment with My App Server, this preparation is especially valuable because the service controls, Java selection, and Tomcat management work best when the uploaded package is clean and ready to run. If you keep the build portable and correctly structured, you reduce deployment errors and make future updates much easier to manage.

What should be included in a deployable Java build?