©ZeroTurnaround OÜ, Estonia, Tartu
JRebel maps your project workspace directly to a running application, watches for the changes you make to classes and
resources, and intelligently reflects them in your application. In order for it to do that, JRebel needs to know
where your classes and resources are. We use the rebel.xml
configuration file to map your deployed
project back to your workspace. This is mandatory when you deploy your app as a WAR/EAR. You'll need to have one
rebel.xml
file per each module. This includes both web and EJB modules.
rebel.xml
configuration file should end up in your WEB-INF/classes
directory in the case of a web module and in the jar root in the case of an ejb module or a jar library. Put it in
the root of a source or resource folder in your project (the same place where the .properties files are) and make
sure it's copied to the target directory.
Configuring JARs
JARs are usually not deployed on their own, but as a part of application (e.g. WEB-INF/lib
in WARs or
EJB modules in EARs). However, often you still want to update their code on-the-fly. Let's assume that we have a
module my-business-module.jar
deployed in WEB-INF/lib
. You can propagate the changes from
your workspace by adding the following rebel.xml
to the root of the JAR file:
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath> <dir name="c:\myWorkspace\myBusinessModule\target\classes"/>
<dir name="c:\myWorkspace\myBusinessModule\src\main\resources"/>
</classpath> </application>
This will mount classes and resources in directories
c:\myWorkspace\myBusinessModule\target\classes
and c:\myWorkspace\myBusinessModule\src\main\resources
before the classes and resources in the JAR file. Changes to those classes and resources will propagate to the
application.
Configuring WARs
In case of a web application you have web application resources, like JSPs, HTML files, graphic files and so on in
addition to the classpath. To configure a web application deployed as a WAR file we create a rebel.xml
file in the WEB-INF/classes
directory:
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath> <dir name="c:\myWorkspace\myWar\target\classes"/>
<dir name="c:\myWorkspace\myWar\src\main\resources"/>
</classpath> <web> <link target="/">
<dir name="c:\myWorkspace\myWar\src\main\webapp"/>
</link> <link target="/jsps/">
<dir name="c:\myWorkspace\myWar\src\main\jsps"/>
</link> </web> </application>
This will mount classes and resources in directories c:\myWorkspace\myWar\target\classes
and
c:\myWorkspace\myWar\src\main\resources
to the application classpath before the deployed classes
and resources. This means that those classes and resources will override the ones in WEB-INF/classes
and
WEB-INF/lib/*.jar
. Changes to those classes and resources will propagate to the application.
This will also map the web resources in the c:\myWorkspace\myWar\src\main\webapp
directory to the root
("/") of the web application context and the web resources in c:\myWorkspace\myWar\src\main\jsps
directory under the /jsps/
URI of the web application context. You may map several directories to one
context target if necessary.
Configuring EARs
To configure a EAR you need to create a separate rebel.xml
file for each EAR module.
Web modules should be configured same as individually deployed WARs, EJB modules should be configured same as JARs.
If your container supports APP-INF/classes
you may also add a rebel.xml
to that folder
and mount classes and resources that belong to the EAR as a whole.
Putting absolute paths in the rebel.xml
might be a bad idea as you'd like to share it with other team
members. Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml
to a property that
you provide. You can set this property as a Java System property (-Dmyproject.root=c:/projects/
) or in
the JRebel Agent Configuration:
<jar>
.
<dirset>
or <jarset>
that accepts Ant-style patterns to specify the specific directories.
<dir>
and
<jar>
entries.
Click on your project and pick Generate rebel.xml.
You need to generate one rebel.xml file per Eclipse project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and Eclipse will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.
The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to
share it with other team members. Luckily JRebel will expand expressions like "${myproject.root}" in
rebel.xml
to a property that you provide. You can set this property as a Java System property
(-Dmyproject.root=c:/projects/
) or in the JRebel Agent Configuration:
If everyone on your team uses Eclipse and a similar workspace layout, you can even skip using a custom property as every application or server launched with JRebel for Eclipse will have the property rebel.workspace.path set to the Eclipse workspace location and you can use it as “${rebel.workspace.path}” in rebel.xml.
Click on your project and pick Generate rebel.xml.
You need to generate one rebel.xml file per Eclipse project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and Eclipse will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.
The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to
share it with other team members. Luckily JRebel will expand expressions like "${myproject.root}" in
rebel.xml
to a property that you provide. You can set this property as a Java System property
(-Dmyproject.root=c:/projects/
) or in the JRebel Agent Configuration:
If everyone on your team uses Eclipse and a similar workspace layout, you can even skip using a custom property as every application or server launched with JRebel for Eclipse will have the property rebel.workspace.path set to the Eclipse workspace location and you can use it as “${rebel.workspace.path}” in rebel.xml.
To generate the rebel.xml file right click on your project and pick Generate rebel.xml:
You need to generate one rebel.xml file per project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and your IDE will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.
(*) Put rebel.xml in the root of the src/main/resources folder for Maven projects.
The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to share it with other team members.
Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml
to a property that you provide.
You can set this property as a Java System property (-Dmyproject.root=c:/projects/
) or in the JRebel Agent Configuration:
To generate the rebel.xml file right click on your project and pick Generate rebel.xml:
You need to generate one rebel.xml file per project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and your IDE will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.
(*) Put rebel.xml in the root of the src/main/resources folder for Maven projects.
The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to share it with other team members.
Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml
to a property that you provide.
You can set this property as a Java System property (-Dmyproject.root=c:/projects/
) or in the JRebel Agent Configuration:
To generate the rebel.xml file right click on your project and pick Generate rebel.xml:
You need to generate one rebel.xml file per project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and your IDE will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.
The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to share it with other team members.
Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml
to a property that you provide.
You can set this property as a Java System property (-Dmyproject.root=c:/projects/
) or in the JRebel Agent Configuration:
Add the following snippet to your parent pom.xml
. The rebel.xml configuration file will be generated for
each individual sub-module of your maven project.
<plugin> <groupId>org.zeroturnaround</groupId> <artifactId>jrebel-maven-plugin</artifactId> <version>1.1.1</version> <executions> <execution> <id>generate-rebel-xml</id> <phase>process-resources</phase> <goals> <goal>generate</goal> </goals> </execution> </executions> </plugin>
This will generate JRebel configuration file rebel.xml
automatically on every build. If you want to
generate the rebel.xml
manually run mvn jrebel:generate -Drebel.xml.dir=OUTPUT_DIRECTORY
(by default OUTPUT_DIRECTORY
is target/classes
). Adding
-Drebel.generate.show=true
will print out generated rebel.xml
at info level, so you can
immediately see what was generated.
By default, the generated rebel.xml
contains absolute paths to your workspace. However if you want to deploy
the artifacts for your team to use, you will need to make sure that the paths are relative using a configurable custom
property.
Assuming that you have the following project structure in directory c:\projects\
:
my-maven-project1 my-jar1 my-war1
You should add the following configuration to the plugin:
<configuration> <!-- root is 2 directories up from the jar/war modules --> <relativePath>../../</relativePath> <!-- use a custom property for specifying root directory (note the double $) set the property in JRebel configuration or as -Dmyproject.root=c:/projects/ --> <rootPath>$${myproject.root}</rootPath> </configuration>
Now you will have c:/projects/my-maven-project1/my-jar1/target/classes
as ${myproject.root}/my-maven-project1/my-jar1/target/classes
in the rebel.xml
. You can set this property as a Java System property (-Dmyproject.root=c:/projects/
)
or in the JRebel Agent Configuration:
A sample maven plugin configuration with comments follows:
<plugin> <groupId>org.zeroturnaround</groupId> <artifactId>jrebel-maven-plugin</artifactId> <version>1.1.1</version> <configuration> <!-- If your project uses custom packaging that is not recognized set this to jar or war. --> <packaging>war</packaging> <classpath> <fallback>default</fallback> <resources> <resource> <!-- A relative path. --> <directory>target/special-classes </directory> <!-- You may use includes and excludes as with any other resource. --> <includes> <include>com/yourapp/include/package1/** </include> <include>com/yourapp/include/package2/** </include> </includes> <excludes> <exclude>com/yourapp/exclude/package1/** </exclude> <exclude>com/yourapp/exclude/package2/** </exclude> </excludes> </resource> <resource> <!-- Empty resource element marks default configuration. By default it is placed first in generated configuration. --> </resource> <resource> <!-- An absoulte path is used here. --> <jar>c:\projects\myProject\3rdpartyLibs\myLibrary.jar </jar> </resource> <resource> <jarset>app/3rd-party-lib</jarset> <excludes> <exclude>apache*.jar</exclude> </excludes> </resource> <resource> <dirset>c:\projects\project1Root\ </dirset> <excludes> <exclude>**\build\classes</exclude> </excludes> </resource> </resources> </classpath> <war> <path>c:\projects\myProject\dist\myProject.war </path> </war> <web> <resources> <resource> <target>gfx/</target> <directory>c:\projects\myProject\static\gfx </directory> </resource> <resource> <!-- Empty resource element marks default configuration. By default it is placed first in generated configuration. --> </resource> </resources> </web> <!-- addResourcesDirToRebelXml - default is false Required if the resource directories are to be added to rebel.xml --> <addResourcesDirToRebelXml>true</addResourcesDirToRebelXml> <!-- alwaysGenerate - default is false If 'false' - rebel.xml is generated if timestamps of pom.xml and the current rebel.xml file are not equal. If 'true' - rebel.xml will always be generated --> <alwaysGenerate>true</alwaysGenerate> </configuration> </plugin>
Also, maven has a notion of build profiles defined in your application's POM that you can leverage.
<profiles> <profile> <id>jrebel</id> <activation> <property> <name>env</name> <value>jrebel</value> </property> </activation> <build> <plugins> <plugin> <groupId>org.zeroturnaround</groupId> <artifactId>jrebel-maven-plugin</artifactId> <executions> <execution> <id>generate-rebel-xml</id> <phase>process-resources</phase> <goals> <goal>generate</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles>
Executing the example above with mvn -Denv=jrebel clean install
command will trigger JRebel plugin to generate rebel.xml.
Starting with JRebel 2.0 rebel.xml
file must be used
for web applications that use packaged deployment (i.e. WARs, JARs and
EARs). Instead of the WAR/JAR/EAR file deployed all resources will be
picked up from the locations provided in the rebel.xml
.
Also these directories and archives will be monitored for changes.
The rebel.xml
must be placed in the WEB-INF/classes
directory of the deployed WAR file, in a root directory of a JAR file
or in the root of
EJB JAR modules. A rebel.xml
file should be
provided per
each module in the application that you want to change on-the-fly.
The contents of the
rebel.xml
is defined by the schema at
http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd
. There is a full example at the end of this file.
JRebel will expand expressions like "${myProject.root}" in rebel.xml
to a system property
that you can pass to the application container as -DmyProject.root=c:/myWorkspace/myProject
. This allows
to use a single configuration for everyone and then customize it when starting the server.
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
...
</application>
Defines the mounted classpath of the application with nested dir, dirset, jar and jarset elements. The fallback attribute controls if classes and resources are also found from the original application classpath (e.g. WEB-INF/classes, WEB-INF/lib/*.jar, JAR root, etc).
Attribute | Description | Required |
fallback | Values: all ,
none and default
(default).
|
No |
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
...
</classpath>
</application>
Directory on the filesystem that is added to classpath or link. Nested include / exclude tags can be used to limit the files included from the specified directory.
Attribute | Description | Required |
name | A full path to a directory on the
filesystem. |
Yes |
includes | Specifies a pattern that directs which resources will be included from the parent. | No |
excludes | Specifies a pattern that directs which resources will be excluded from the parent. | No |
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
<!--
Add a directory with class files to the classpath. The classes
can also be excluded or included based on patterns.
-->
<dir name="c:\projects\myProject\classes\">
<!-- Including everything from com/yourapp/package1-->
<include name="com/yourapp/package1/**"/>
<!-- Exclude the unimportant subpackage of package1-->
<exclude name="com/yourapp/package1/unimportant/**"/>
</dir>
</classpath>
</application>
Defines multiple subdirectories of a directory that can be added to classpath. Nested include / exclude tags can be used to limit the subdirectories included from the specified directory.
Attribute | Description | Required |
dir | The parent directory from which subdirectories are found. By default all will be added. | Yes |
includes | Specifies a pattern that directs which resources will be included from the parent. | No |
excludes | Specifies a pattern that directs which resources will be excluded from the parent. | No |
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
<!--
DIRSET enables you to add multiple directories to the classpath
without specifying them one-by-one. For example if there are multiple
MAVEN modules with a similar folder structure. The following configuration
will include all modules from the directory of "c:\projects\project1Root\
that adhere to the pattern "**\build\classes".
-->
<dirset dir="c:\projects\project1Root\">
<include name="**\build\classes"/>
</dirset>
</classpath>
</application>
Defines a JAR file that is added to classpath or link. Nested include / exclude tags can be used to limit the resources included from the specified JAR.
Attribute | Description | Required |
name | Full path to a JAR file that is added to the CLASSPATH. | Yes |
includes | Specifies a pattern that directs which resources will be included from the parent. | No |
excludes | Specifies a pattern that directs which resources will be excluded from the parent. | No |
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
<!--
Adds a JAR file to the classpath. The classes from the
JAR archive can also be excluded or included based on patterns.
-->
<jar name="c:\projects\myProject\3rdpartyLibs\myLibrary.jar">
<!-- Including everything from com/yourapp/package1-->
<include name="com/yourapp/package1/**"/>
<!-- Exclude the unimportant subpackage of package1-->
<exclude name="com/yourapp/package1/unimportant/**"/>
</jar>
</classpath>
</application>
Defines multiple JAR files to be added to classpath. Nested include / exclude tags can be used to limit the JARS included from the specified directory.
Attribute | Description | Required |
dir | JAR files from this directory on the filesystem are added to the CLASSPATH | Yes |
includes | Specifies a pattern that directs which resources will be included from the parent. | No |
excludes | Specifies a pattern that directs which resources will be excluded from the parent. | No |
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
<!--
JARSET enables you to add multiple JAR files to the classpath without
specifying them one-by-one. The following example includes JAR files
from the app/3rd-party-lib directory that don't match the pattern apache*.jar.
-->
<jarset dir="app/3rd-party-lib">
<exclude name="apache*.jar"/>
</jarset>
</classpath>
</application>
Overrides the WAR file deployed to the container with a exploded directory or a WAR file on the filesystem. Needs to have either dir or file attribute.
Attribute | Description | Required |
dir | Path to an exploded WAR
directory on the filesystem. Resources and class files will be loaded
from this directory. |
Yes/No |
file | Path to a WAR archive on the filesystem. Resources and class files will be loaded from this file. | Yes/No |
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<!--
WAR tag with FILE attribute specifies the location of the WAR file.
The contents of this WAR file will have higher priority as compared
to the web application deployed. All resources in this file will be
available in the web application just as they would be in the
deployed WAR file.
-->
<war file="c:\projects\myProject\dist\myProject.war" />
</application>
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<!--
WAR tag with DIR attribute specifies the location of the exploded
directory. The contents of this directory will have higher priority
as compared to the web application deployed to the container. All
resources in this folder will be available in the web application
just as they would be in the deployed web application.
-->
<war dir="c:\projects\myProject\dist\war" />
</application>
Defines separate locations for static resources that can be referenced from the web application. With nested link tags it is possible to map different resources from the filesystem to the web context.
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<!--
WEB tag defines separate locations for static resources that can be referenced from
the web application. Directories containing jsp, css, html, gif etc. files. These
directories can be mapped to arbitrary locations for the web application.
-->
<web>
...
</web>
</application>
Can be added to web to link a nested dir or jar to the target URI. The mapped resource is made available from servlet context and also via HTTP.
Attribute | Description | Required |
target | Mapping target. For example "gfx/" or "js/". | Yes |
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<!--
WEB tag defines separate locations for static resources that can be referenced from
the web application. Directories containing jsp, css, html, gif etc. files. These
directories can be mapped to arbitrary locations for the web application.
-->
<web>
<!--
The location c:\projects\myProject\static\gfx will be accessible to the WEB
application as http://yourhost/webapp/gfx folder. Adding static resources to
that location will let you use them from your web application.
-->
<link target="gfx/">
<dir name="c:\projects\myProject\static\gfx"/>
</link>
</web>
</classpath>
</application>
This element is used to filter resources in dir, dirset, jar and jarset elements. Resources named by this element will be included in the result.
Attribute | Description | Required |
name | Name that will be filtered, can contain wildcards. See example for more information. | Yes |
<dirset dir="c:\projects\project1Root\">
<exclude name="**\build\classes"/>
</dirset>
...
<jarset dir="app/3rd-party-lib">
<exclude name="apache*.jar"/>
</jarset>
...
<jar name="c:\projects\myProject\3rdpartyLibs\myLibrary.jar">
<!-- Include all of package1-->
<include name="com/yourapp/package1/**"/>
<!-- Except for internal subpackage-->
<exclude name="com/yourapp/package1/internal/**"/>
</jar>
This element is used to filter resources in dir, dirset, jar and jarset elements. Resources named by this element will be excluded from the result.
Attribute | Description | Required |
name | Name that will be filtered, can contain wildcards. See example from include tag for more information. | Yes |
The following file can be copied to your project and appropriate sections deleted or customized.
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<!--
Classpath allows you to add DIRECTORIES and JAR files to your classpath. Your
webapp will see these resources as resources inside the WAR archive or your
exploded directory.
The default value of fallback is true. When set to 'false' then if a resources
is NOT found from the defined directories, it won't be looked for from the
deployed resources.
Example. Fallback is set to FALSE and you remove a styles.css file. Even though
a styles.css file is deployed to the container, it will give a 404 on HTTP request
or null on ServletContext lookup even though it exists in the deployed archive.
If set to true, all resources will fallback to the deployed application, this is
the default behavior.
-->
<classpath fallback="default">
<!--
Add a directory with class files to the classpath. The classes
can also be excluded or included based on patterns.
-->
<dir name="c:\projects\myProject\classes\">
<!-- Only include package1 and its subpackages -->
<include name="com/yourapp/package1/**"/>
<!-- Except com/yourapp/package1/package2 and its subpackages -->
<exclude name="com/yourapp/package1/package2/**"/>
</dir>
<!--
Adds a JAR file to the classpath. The classes from the
JAR archive can also be excluded or included based on patterns.
-->
<jar name="c:\projects\myProject\3rdpartyLibs\myLibrary.jar">
<!-- Only include package1 and its subpackages -->
<include name="com/yourapp/package1/**"/>
<!-- Except com/yourapp/package1/package2 and its subpackages -->
<exclude name="com/yourapp/package1/package2/**"/>
</jar>
<!--
JARSET enables you to add multiple JAR files to the classpath without
specifying them one-by-one. The following example includes JAR files
from the c:\projects\3rd-party-lib directory that don't match the pattern apache*.jar.
-->
<jarset dir="c:\projects\3rd-party-lib">
<exclude name="apache*.jar"/>
</jarset>
<!--
DIRSET enables you to add multiple directories to the classpath
without specifying them one-by-one. For example if there are multiple
MAVEN modules with a similar folder structure. The following configuration
will include all modules from the directory of "c:\projects\project1Root\
that adhere to the pattern "**\build\classes".
-->
<dirset dir="c:\projects\project1Root\">
<exclude name="**\build\classes"/>
</dirset>
</classpath>
<!--
WAR tag with FILE attribute specifies the location of the WAR file. The contents
of this WAR file will have higher priority as compared to the web application deployed.
All resources in this file will be available in the web application just as they
would be in the deployed WAR file.
-->
<war file="c:\projects\myProject\dist\myProject.war" />
<!--
WAR tag with DIR attribute specifies the location of the exploded directory. The
contents of this directory will have higher priority as compared to the web application
deployed to the container. All resources in this folder will be available in the
web application just as they would be in the deployed web application.
-->
<war dir="c:\projects\myProject\dist\war"/>
<!--
WEB tag defines separate locations for static resources that can be referenced from
the web application. Directories containing jsp, css, html, gif etc. files. These
directories can be mapped to arbitrary locations for the web application.
-->
<web>
<!--
The location c:\projects\myProject\static\gfx will be accessible to the WEB
application as http://yourhost/webapp/gfx folder. Adding static resources to
that location will let you use them from your web application.
-->
<link target="gfx/">
<dir name="c:\projects\myProject\static\gfx"/>
</link>
<!--
The location c:\projects\jsProject\dist\js will be accessible to the WEB
application as http://yourhost/webapp/js folder. Adding static resources to
that location will let you use them from your web application.
-->
<link target="js/">
<dir name="c:\projects\jsProject\dist\js"/>
</link>
</web>
</application>
JRebel Reference Manual, ©ZeroTurnaround OÜ, Estonia, Tartu