Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 4
Next »
 |
You are viewing documentation of TeamCity 6.5.x, which is not the most recent released version of TeamCity. Please refer to the listing to choose another version.
|
|
Search
Table of Contents
|
Plugin Reloading
If you make changes to a plugin, you will generally need to shut down the server, update the plugin, and start the server again.
To enable TeamCity development mode, pass the "teamcity.development.mode=true" internal property. Using the option you will:
- Enforce application server to quicker recompile changed
.jsp classes
- Disable JS and CSS resources merging/caching
To avoid class loading issues in plugins after updating resources pass the "teamcity.development.shadowCopyClasses=true" internal property. Using the option you will:
- Make TeamCity server create "
.teamcity_shadow" directory for every plugin .jar files.
- Avoid .jar files update on plugin binaries external changes
The following hints can help you eliminate the restart in the certain cases:
- if you do not change code affecting plugin initialization and change only body of the methods, you can attach to the server process with a debugger and use Java hotswap to reload the changed classes from your IDE without web server restart. Note that the standard hotswap does not allow you to change method signatures.
- if you make a change in some resource (jsp, js, images) you can copy the resources to
webapps/ROOT/plugins/<plugin-name> directory to allow Tomcat to reload them.
- change in build agent part of plugin will initiate build agents upgrade.
See also:
|