When you prepare a Java application for deployment on a hosting platform, the most important goal is to include everything the app needs to start, run, and connect to its web container without bundling unnecessary files. For a deployable build in a Plesk-based Java hosting environment, that usually means a clean WAR file or an application directory with compiled classes, application resources, and the correct library dependencies. If you are using Apache Tomcat through a managed hosting service such as My App Server, a well-structured build makes installation faster, reduces startup errors, and helps you troubleshoot version or dependency problems more easily.
In practical terms, a deployable Java build should contain your application code, static assets, configuration that belongs inside the app, and any libraries that are not already provided by the runtime or the container. It should not contain source code, local machine settings, build cache files, or server-specific binaries that are not meant to be deployed. The exact package structure depends on whether you are deploying a traditional Java web application, a servlet-based application, or a JSP application running under Tomcat.
What a deployable Java build should include
A deployable build is the output of your build process that can be uploaded to the hosting environment and started without additional manual assembly. For Java hosting, this is usually a WAR file, although some applications may also use an exploded web application directory. If you are hosting on a control panel with a Tomcat integration, the build should be ready for deployment into the configured application server with minimal extra steps.
Compiled application classes
Your build must include compiled .class files, not Java source files. These classes are typically placed under WEB-INF/classes inside a WAR package. They represent the application logic that Tomcat loads at runtime.
Common examples include:
- Servlet classes
- Controller classes
- Service and utility classes
- Domain and model classes
Application resources
Include any resources that your application reads at runtime. These are usually files packaged with the application so they are available from the classpath or web root.
Examples:
- Properties files
- XML configuration files
- Templates
- Messages and localization files
- Static web assets such as CSS, JavaScript, and images
Static content usually belongs in the web root of the application, while internal configuration files may go under WEB-INF/classes or another classpath location depending on the framework.
Required dependencies
Your deployable build should contain all libraries that are not supplied by the runtime. In a Tomcat hosting environment, this usually means application-specific JAR files in WEB-INF/lib. If your app depends on Spring, Hibernate, JSON libraries, logging libraries, or other third-party components, they should normally be packaged with the build unless the hosting setup explicitly provides them.
Be careful not to bundle libraries that are already included by the container or provided by the Java runtime, because this can cause class loading conflicts. For example, Tomcat already provides servlet API classes, so these are generally marked as provided in your build configuration.
Deployment descriptor or framework metadata
Depending on your application type, you may need deployment metadata such as WEB-INF/web.xml. Some modern frameworks reduce the amount of manual XML configuration, but the build still needs whatever metadata is required by your app and the hosting runtime.
Include only the configuration that is supposed to travel with the application. Environment-specific secrets, server credentials, and local development files should not be packaged inside the deployable artifact.
What should not be included in a deployable build
A common reason for deployment problems is packaging too much into the artifact. A clean build is smaller, easier to upload, and less likely to fail on the target server. When using Java hosting or Tomcat hosting, leaving out unnecessary files is just as important as including the right ones.
Source code and development files
Do not include raw .java files in the final deployable package unless you are intentionally shipping an exploded source-based setup, which is uncommon for managed hosting. You also should not include:
- IDE project files
- Build tool caches
- Temporary files
- Local logs
- Test output directories
Operating system and local environment files
Files created on your laptop or build machine should normally stay out of the deployment package. These can include local environment files, editor settings, and OS metadata. They are not needed by Tomcat and can create confusion during deployment.
Provided container dependencies
Anything already supplied by the hosting platform or the application server should not be packaged again unless the framework documentation says otherwise. A classic example is the servlet API. Repackaging container-provided dependencies can lead to version clashes and unexpected runtime errors.
Secret values and machine-specific settings
Do not hard-code passwords, API keys, or host-specific paths into the build. Use environment-specific configuration patterns supported by your application or your hosting control panel. In a managed hosting setup, separating code from secrets is safer and easier to maintain.
WAR file structure for Tomcat hosting
For most Java web applications deployed to Apache Tomcat, the standard format is a WAR file. If you are using a hosting platform with a Plesk extension such as My App Server, a WAR archive is usually the simplest deployment format because it matches Tomcat’s expected structure.
Typical WAR contents
A standard WAR file often contains:
index.jspor a front controller entry point- Static assets at the web root
WEB-INF/classesfor compiled application classesWEB-INF/libfor dependency JARsWEB-INF/web.xmlif your app uses it
Frameworks may add additional files or generated metadata, but the general layout remains the same. If your WAR cannot be deployed cleanly, it is often because files are in the wrong folder or the package contains duplicate classes and libraries.
Exploded directory deployments
Some hosting environments allow an exploded application directory instead of a single WAR file. This can be useful during development or for manual updates. The same rules still apply: include the necessary classes, libraries, and resources, but avoid source and build artifacts that are not required at runtime.
On a managed hosting platform, the WAR format is often easier to maintain because it keeps deployment predictable and reduces the chance of partial file uploads.
How to prepare the build for a managed hosting platform
If your Java application is hosted through a control panel, your build process should create a deployment artifact that can be uploaded and activated without extra editing on the server. For My App Server environments, this usually means matching the application’s expected Java version and Tomcat compatibility before you upload the build.
Step 1: Choose the correct packaging type
Decide whether your application should be deployed as a WAR, a directory, or a custom server package. For most Tomcat-based web apps, WAR is the right choice. If your app needs a specific runtime layout, make sure it matches the deployment method supported by the hosting panel.
Step 2: Mark container-provided libraries as provided
In Maven or Gradle, libraries such as the servlet API are usually marked as provided so they are available at compile time but not packaged into the final artifact. This reduces the risk of duplicate classes and makes the deployable build cleaner.
Step 3: Package application-specific dependencies only
Include third-party JARs that your app really needs at runtime. Review the contents of WEB-INF/lib or the equivalent output folder and remove anything that is not required in production.
Step 4: Verify the Java version target
Your build must be compiled for a Java version that matches the runtime available in your hosting plan. If you compile with a newer JDK than the server supports, the app may fail to start with class version errors. This is especially important when you choose between ready-made Java versions in a hosting platform or upload a custom setup.
Step 5: Check framework-specific output
Some frameworks generate additional files during packaging. Review the final artifact and confirm that the framework’s required descriptors, resources, and bootstrap files are present. If the app uses Spring Boot in WAR mode, for example, the packaging layout may differ from a traditional servlet app, but the deployment rules still depend on runtime compatibility.
Step 6: Test the artifact locally before uploading
Before deploying to the hosting server, test the WAR file in a local Tomcat installation or in a staging environment. This helps you confirm that the artifact starts correctly, loads the expected libraries, and serves the correct entry point.
Common build mistakes that cause deployment issues
Many deployment errors in Java hosting are caused by packaging problems rather than server problems. Identifying these early can save time when using a control panel-based deployment workflow.
Including the servlet API in the WAR
This is one of the most common mistakes. Tomcat already provides servlet classes, so bundling another version can create conflicts. Use your build tool’s dependency scope correctly to avoid this.
Shipping duplicate JAR files
If the same library appears in multiple places, the application may load the wrong version or fail with a classpath conflict. Check for duplicate dependencies in both your application package and any server-level library folder.
Leaving out runtime configuration files
Sometimes a build works locally but fails after deployment because a properties file, template, or XML resource was not included in the final artifact. Confirm that everything needed at runtime is copied into the correct output folder before packaging.
Using the wrong Java language level
A build compiled for a newer Java release cannot run on an older JVM. Make sure your source and target compatibility match the Java version offered by your hosting platform or custom JVM setup.
Packaging test and development assets
Including test classes, sample data, or debug-only resources can increase build size and make maintenance harder. Keep the final build focused on production runtime needs.
Recommended checklist before deployment
Use this checklist to confirm your build is ready for upload to a Java hosting environment:
- The application is packaged as the correct artifact type, usually WAR for Tomcat
- Compiled classes are included
- Required JAR dependencies are included
- Container-provided APIs are excluded from the package
- Runtime resources and templates are present
- Static web files are in the correct location
- No source code or build cache files are included
- No secrets or local machine settings are packaged
- The build target matches the server’s Java version
- The artifact has been tested locally or in staging
Using My App Server for Java deployment
In a hosting environment that provides Java support through a Plesk extension such as My App Server, the deployable build should be ready to install into the Tomcat instance or private JVM assigned to your account. The goal is to keep deployment simple: upload the build, map it to the application server, and start the service from the control panel.
This setup is well suited to small and medium Java applications that need a private runtime, straightforward service control, and support for WAR or JSP-based deployment. It is not intended as a heavy enterprise cluster platform, so clean packaging matters even more. A tidy build helps you stay within the practical limits of shared hosting while still keeping control over your application structure.
When to use a custom app server build
If your application needs a specific Tomcat version, a particular JVM version, or extra runtime settings, you may need a custom app server configuration. In that case, the deployable build should still remain portable. Avoid hard-coding paths or container assumptions that only work on your local machine.
How control panel deployment helps
With a control panel workflow, you usually want predictable file structure and minimal manual server editing. A properly prepared build reduces the chance of mistakes when uploading, restarting the service, or rolling back to a previous version.
FAQ
Is a deployable Java build always a WAR file?
No. A WAR file is the most common format for Tomcat-based web applications, but some projects may use an exploded directory or another packaging approach. The right choice depends on your framework and hosting setup.
Should I include source files in the final build?
Usually no. The final deployable artifact should contain compiled classes and runtime resources, not source code. Source files belong in your version control system and development environment.
Do I need to include Tomcat libraries in my build?
Generally no. Tomcat provides its own servlet and container libraries. You should package only the application-specific dependencies unless your framework documentation clearly requires something different.
What if my app works locally but fails on the hosting server?
Check the Java version, dependency packaging, resource paths, and whether you included or excluded the correct libraries. Local and hosted environments often differ in classpath, container version, or configuration.
Can I upload a Spring or servlet app to a Plesk-based Java hosting service?
Yes, if the application is compatible with the available Java and Tomcat versions. The build must be packaged correctly and should not depend on unsupported enterprise features or external cluster infrastructure.
How do I reduce deployment errors?
Use a clean build process, test locally, keep dependencies under control, and ensure your artifact contains only the files needed at runtime. A consistent packaging approach is one of the best ways to avoid startup issues.
Summary
A deployable Java build for hosting in the UK market should be complete, portable, and cleanly packaged. Include compiled classes, runtime resources, and the dependencies your application needs, but exclude source code, development files, duplicate libraries, and container-provided APIs. For Tomcat hosting through a control panel such as Plesk and My App Server, the best result is usually a well-structured WAR file that matches the target Java version and deployment layout.
When your build is prepared correctly, deployment becomes simpler, troubleshooting becomes faster, and your Java application is more likely to start reliably on the hosting platform. That is especially important for JSP, servlet, and Tomcat-based applications where file structure and dependency handling directly affect runtime behavior.