programmer-guide/src/tooling.xml - virgo/org.eclipse.virgo.documentation - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
 		"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
 <chapter id="tooling">
 	<title>Tooling</title>
 	<para>
 		SpringSource provides a set of plug-ins for the Eclipse IDE that streamline the development
 		lifecycle of OSGi bundles and PAR applications. The @product.name@ Tools build on top
 		of the Eclipse Web Tools Project (WTP).
 	</para>
 	<para>
 		The @product.name@ Tools support the creation of new OSGi bundle and PAR projects within Eclipse, and the
 		conversion of existing projects into OSGi bundle projects. Projects can then be deployed and debugged on a running
 		@short.product.name@ from within Eclipse.
 	</para>
 	<section id="tooling-installation">
 		<title>Installation</title>
 		<para>
 			Currently the Tools support Eclipse 3.5 and Eclipse 3.6 with the corresponding version of WTP. Downloading and
 			unzipping the <ulink url="http://www.eclipse.org/downloads/">Eclipse IDE for Java EE  Developers</ulink> is the
 			easiest way to start.
 		</para>
 		<para>
 			You may like to change the Eclipse launcher options to increase the values of <literal>-XX:MaxPermSize</literal>,
 			<literal>-Xms</literal>, and <literal>-Xmx</literal>. Suggested values, if you have plenty of RAM, are <literal>768m</literal>,
 			<literal>500m</literal>, and <literal>2500m</literal>, respectively.
 		</para>
 		<para>
 			Install the dm Server Tools, which include the Virgo Tools, from one of the following update sites depending on
 			your version of Eclipse. Releases are, in general, more stable than milestones whereas nightly builds are not for the
 			faint of heart.
 			<itemizedlist>
 				<listitem>
 					<para>
 						<literal>http://dist.springsource.com/release/TOOLS/update/e3.6/</literal>
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						<literal>http://dist.springsource.com/release/TOOLS/update/e3.5/</literal>
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						<literal>http://dist.springsource.com/milestone/TOOLS/update/e3.6/</literal>
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						<literal>http://dist.springsource.com/milestone/TOOLS/update/e3.5/</literal>
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						<literal>http://dist.springsource.com/snapshot/TOOLS/nightly/e3.6/</literal>
 					</para>
 				</listitem>
 				<listitem>
 					<para>
 						<literal>http://dist.springsource.com/snapshot/TOOLS/nightly/e3.5/</literal>
 					</para>
 				</listitem>
 			</itemizedlist>
 		</para>
 	</section>
 	<section id="tooling-running">
 		<title>Running a @product.name@ instance within Eclipse</title>
 		<para>
 			After installing the Tools from the update site outlined in the previous section, you
 			will be able to configure an instance of the @short.product.name@ inside Eclipse.
 		</para>
 		<para>
 			To do so bring up the WTP Servers view (i.e.,
 			<menuchoice>
 				<guimenu>Window</guimenu>
 				<guisubmenu>Show View</guisubmenu>
 				<guimenuitem>Other</guimenuitem>
 				<guimenuitem>Server</guimenuitem>
 				<guimenuitem>Servers</guimenuitem>
 			</menuchoice>).
 			You can now right-click in the view and select "<menuchoice><guimenu>New</guimenu><guimenuitem>Server</guimenuitem></menuchoice>".
 			This will bring up a "New Server" dialog. Select "@product.name@ v2.1 Server"
 			in the "Virgo" category and click "<guibutton>Next</guibutton>".
 		</para>
 		<para>
 			<imagedata fileref="images/tooling-new-server.png" format="PNG" />
 		</para>
 		<para>
 			Within the "New Server Wizard" point to the installation directory of the @product.name@
 			and finish the wizard. After finishing the wizard you should see a @product.name@
 			entry in the Servers view.
 		</para>
 		<para>
 			To start, stop, and debug the created @product.name@ instance use the toolbar or the context
 			menu actions of the Servers view.
 		</para>
 		<para>
 			<imagedata fileref="images/tooling-start-server.png" format="PNG" />
 		</para>
 	</section>
 	<section id="tooling-repository-editor">
 		<title>Bundle and Library Provisioning</title>
 		<para>
 			After successful configuration of an instance of the @product.name@ in Eclipse you can use
 			the Repository Browser to very easily install bundles and libraries from the remote
 			SpringSource Enterprise Bundle Repository.
 		</para>
 		<para>
 			To open the Repository Browser double-click a @product.name@ instance in the Servers
 			view and select the "Repository" tab in the server editor. Please note that opening of the
 			Editor may take a few seconds as the contents of the local repository needs to be indexed
 			before opening.
 		</para>
 		<para>
 			<imagedata fileref="images/tooling-repository-browser.png" format="PNG" />
 		</para>
 		<para>
 			The left section of the Repository Browser allows the user to run searches against the
 			@ebr@ and displays matching results. The search can
 			take parts of bundle symbolic names, class or package names and allows wildcards such as
 			&lsquo;?&rsquo; and &lsquo;*&rsquo;. By selecting the checkbox left to a matching bundle and/or library and clicking
 			the "Download" button it is	very easy to install new bundles in the @product.name@. For your
 			convenience JARs containing the bundle source code can be automatically downloaded as well.
 		</para>
 		<para>
 			Clicking the "Download" button will trigger an Eclipse background job that will download
 			the selected repository artifacts and -- if desired -- the source JARs one after another.
 		</para>
 		<para>
 			The section on the right displays the currently installed bundles and libraries. Bundles
 			with available sources are visually marked. You can very easily download missing source
 			JARs by using the "Install Sources" button.
 		</para>
 	</section>
 	<section id="tooling-config">
 		<title>Setting up Eclipse Projects</title>
 		<para>
 			The @product.name@ supports different deployment units as discussed earlier in this guide. The
 			Tools define specific project types to support the development of OSGi and PAR projects.
 		</para>
 		<section id="tooling-config-creating-new-projects">
 			<title>Creating New Projects</title>
 			<para>
 				There are two New Project Wizards available within Eclipse that allow for creating
 				new OSGi bundle and PAR projects. The projects created by the wizards are deployable
 				to the integrated @short.product.name@ instance without requiring any additional steps.
 			</para>
 			<para>
 				<imagedata fileref="images/tooling-new-project-wizards.png" format="PNG" />
 			</para>
 			<para>
 				Those wizards create the required <code>MANIFEST.MF</code> file and appropriate manifest
 				headers.
 			</para>
 		</section>
 		<section id="tooling-config-migrating-existing-projects">
 			<title>Migrating existing Java Projects</title>
 			<para>
 				To migrate an existing Java Project to be used with the @short.product.name@, the Tools
 				provide a migration action that adds the required meta data to the project.
 				The migration will not change your project&rsquo;s source layout.
 			</para>
 			<para>
 				Use the context menu action of a project in the Package or Project Explorer and select
 				"<menuchoice><guimenu>Spring Tools</guimenu><guimenuitem>Convert to OSGi bundle project</guimenuitem></menuchoice>".
 			</para>
 		</section>
 		<section id="tooling-config-creating-plan-projects">
 			<title>Creating Plan Projects</title>
 			<para>
 				This is done by creating a new <emphasis>faceted</emphasis> project and then applying the OSGi Plan facet.
 				This will give you access to features such as content completion when editing <literal>.plan</literal> files
 				and deployment to configured servers from within the IDE.
 			</para>
 		</section>
 	</section>
 	<section id="tooling-developing" >
 		<title>Developing OSGi Bundles</title>
 			<para>
 				The Tools provide functionality that makes developing OSGi bundles,
 				especially the editing of MANIFEST.MF files, easier.
 			</para>
 		<section id="tooling-developing-resolving-bundle-dependencies">
 			<title>Resolving Bundle Dependencies</title>
 			<para>
 				While working with OSGi bundles, one of the most interesting and challenging aspects is defining
 				the	package, bundle, and library imports in the manifest and then keeping this in sync
 				with your compile classpath	either in Ant and Maven or Eclipse. In most cases you would typically
 				be required to manually set up the Eclipse classpath. Ultimately, the Eclipse compile
 				classpath is still different from the bundle runtime classpath, as normally an entire
 				JAR file is being made available on the Eclipse classpath but not necessarily at runtime
 				due to the explicit visibility rules defined in <code>Import-Package</code> headers.
 			</para>
 			<para>
 				The Tools address this problem by providing an Eclipse classpath container that
 				uses an @product.name@-specific dependency resolution mechanism. This classpath
 				container makes resolved dependencies available on the project&rsquo;s classpath but allows
 				only access to those package that are imported explicitly (e.g., via <code>Import-Package</code>)
 				or implicitly by using <code>Import-Library</code> or <code>Import-Bundle</code>.
 			</para>
 			<para>
 				To use the automatic dependency resolution, an OSGi bundle or PAR project needs to be
 				targeted to a configured @product.name@ instance. This can be done from the project&rsquo;s
 				preferences by selecting the runtime on the "Targeted Runtimes" preference page.
 			</para>
 			<para>
 				<note>
 					In most scenarios it is sufficient to target the PAR project to a runtime. The nested
 					bundles will then automatically inherit this setting.
 				</note>
 			</para>
 			<para>
 				<imagedata fileref="images/tooling-classpath.png" format="PNG" />
 			</para>
 			<para>
 				After targeting the project or PAR you will see a "Bundle Dependencies" classpath
 				container in your Java project. It is now safe to remove any manually configured classpath
 				entries.
 			</para>
 			<para>
 				The classpath container will automatically attach Java source code to the classpath
 				entries by looking for source JARs next to the binary JARs in the @product.name@&rsquo;s
 				repository. You can also manually override the source code attachment by using the
 				properties dialog on a single JAR entry. This manual attachment will always override
 				the convention-based attachment.
 			</para>
 		</section>
 		<section id="tooling-developing-editing-manifest-mf">
 			<title>Editing the Manifest</title>
 			<para>
 				The Tools provide a Bundle Manifest Editor that assists the developer to create and
 				edit MANIFEST.MF files. The editor understands the @product.name@ specific headers
 				like <code>Import-Library</code> and <code>Import-Bundle</code> and provides content
 				assist features while editing source code. Furthermore a Eclipse Form-based UI is also
 				available.
 			</para>
 			<para>
 				To open the Bundle Manifest Editor right click a MANIFEST.MF file and select "Bundle
 				Manifest Editor" from the "Open With" menu.
 			</para>
 			<para>
 				<note>
 					Please note that the @product.name@ specific manifest headers appear in green color
 					to distinguish them from those headers defined in the OSGi specification. This also
 					makes navigating much easier.
 				</note>
 			</para>
 			<para>
 				<imagedata fileref="images/tooling-manifest-source-editor.png" format="PNG" />
 			</para>
 			<para>
 				The content assist proposals in the source tab as well as in the UI-based tabs are
 				resolved from the bundle and library repository of an installed and configured
 				@product.name@. Therefore it is important to target the project or PAR to a specific
 				@short.product.name@ instance to indicate to the tooling which bundle repository to use.
 			</para>
 			<para>
 				<note>
 					If a OSGi bundle project is not targeted to a @short.product.name@ instance, either
 					directory or indirectly via a PAR project&rsquo;s targetting, the manifest editor will not
 					be able to provide content assist for importing packages, bundles, and libraries.
 				</note>
 			</para>
 			<para>
 				<imagedata fileref="images/tooling-manifest-form-ui-editor.png" format="PNG" />
 			</para>
 			<para>
 				The Dependencies tab of the Bundle Manifest Editor enables the user to easily download
 				and install bundles and libraries from the @ebr@
 				by using the "Download..." buttons next to the "Import Bundle" and "Import Library"
 				sections.
 			</para>
 		</section>
 	</section>
 	<section id="tooling-deploying">
 		<title>Deploying Applications</title>
 		<para>
 			Currently the Tools support direct deployment of WTP Dynamic Web Projects, OSGi
 			bundle and PAR projects to the @short.product.name@ from directly within Eclipse.
 		</para>
 		<para>
 			To deploy an application to the @product.name@ just bring up the context menu on the configured
 			@short.product.name@ runtime in the Servers view and choose "Add or Remove Projects...". In the
 			dialog, select the desired project and add it to the list of "Configured projects".
 		</para>
 		<para>
 			<imagedata fileref="images/tooling-deployed-application.png" format="PNG" />
 		</para>
 		<note>
 			<para>
 				Deploying and undeploying an application from the @short.product.name@ certainly works
 				while the @product.name@ is running, but you can also add or remove projects if the
 				@short.product.name@ is not running.
 			</para>
 		</note>
 		<para>
 			Once an application is deployed on the @product.name@ the tooling support will automatically
 			pick up any change to source files -- for example, Java and XML context files -- and refresh the
 			deployed application on the @short.product.name@.
 		</para>
 		<para>
 			The wait time between a change and the actual refresh can be configured
 			in the configuration editor of the runtime. To bring up that editor,
 			double-click on the configured @product.name@ instance in the Servers view.
 		</para>
 	</section>
 </chapter>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
	"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
	<chapter id="tooling">
	<title>Tooling</title>
	<para>
	SpringSource provides a set of plug-ins for the Eclipse IDE that streamline the development
	lifecycle of OSGi bundles and PAR applications. The @product.name@ Tools build on top
	of the Eclipse Web Tools Project (WTP).
	</para>
	<para>
	The @product.name@ Tools support the creation of new OSGi bundle and PAR projects within Eclipse, and the
	conversion of existing projects into OSGi bundle projects. Projects can then be deployed and debugged on a running
	@short.product.name@ from within Eclipse.
	</para>
	<section id="tooling-installation">
	<title>Installation</title>
	<para>
	Currently the Tools support Eclipse 3.5 and Eclipse 3.6 with the corresponding version of WTP. Downloading and
	unzipping the <ulink url="http://www.eclipse.org/downloads/">Eclipse IDE for Java EE Developers</ulink> is the
	easiest way to start.
	</para>
	<para>
	You may like to change the Eclipse launcher options to increase the values of <literal>-XX:MaxPermSize</literal>,
	<literal>-Xms</literal>, and <literal>-Xmx</literal>. Suggested values, if you have plenty of RAM, are <literal>768m</literal>,
	<literal>500m</literal>, and <literal>2500m</literal>, respectively.
	</para>
	<para>
	Install the dm Server Tools, which include the Virgo Tools, from one of the following update sites depending on
	your version of Eclipse. Releases are, in general, more stable than milestones whereas nightly builds are not for the
	faint of heart.
	<itemizedlist>
	<listitem>
	<para>
	<literal>http://dist.springsource.com/release/TOOLS/update/e3.6/</literal>
	</para>
	</listitem>
	<listitem>
	<para>
	<literal>http://dist.springsource.com/release/TOOLS/update/e3.5/</literal>
	</para>
	</listitem>
	<listitem>
	<para>
	<literal>http://dist.springsource.com/milestone/TOOLS/update/e3.6/</literal>
	</para>
	</listitem>
	<listitem>
	<para>
	<literal>http://dist.springsource.com/milestone/TOOLS/update/e3.5/</literal>
	</para>
	</listitem>
	<listitem>
	<para>
	<literal>http://dist.springsource.com/snapshot/TOOLS/nightly/e3.6/</literal>
	</para>
	</listitem>
	<listitem>
	<para>
	<literal>http://dist.springsource.com/snapshot/TOOLS/nightly/e3.5/</literal>
	</para>
	</listitem>
	</itemizedlist>
	</para>
	</section>
	<section id="tooling-running">
	<title>Running a @product.name@ instance within Eclipse</title>
	<para>
	After installing the Tools from the update site outlined in the previous section, you
	will be able to configure an instance of the @short.product.name@ inside Eclipse.
	</para>
	<para>
	To do so bring up the WTP Servers view (i.e.,
	<menuchoice>
	<guimenu>Window</guimenu>
	<guisubmenu>Show View</guisubmenu>
	<guimenuitem>Other</guimenuitem>
	<guimenuitem>Server</guimenuitem>
	<guimenuitem>Servers</guimenuitem>
	</menuchoice>).
	You can now right-click in the view and select "<menuchoice><guimenu>New</guimenu><guimenuitem>Server</guimenuitem></menuchoice>".
	This will bring up a "New Server" dialog. Select "@product.name@ v2.1 Server"
	in the "Virgo" category and click "<guibutton>Next</guibutton>".
	</para>
	<para>
	<imagedata fileref="images/tooling-new-server.png" format="PNG" />
	</para>
	<para>
	Within the "New Server Wizard" point to the installation directory of the @product.name@
	and finish the wizard. After finishing the wizard you should see a @product.name@
	entry in the Servers view.
	</para>
	<para>
	To start, stop, and debug the created @product.name@ instance use the toolbar or the context
	menu actions of the Servers view.
	</para>
	<para>
	<imagedata fileref="images/tooling-start-server.png" format="PNG" />
	</para>
	</section>
	<section id="tooling-repository-editor">
	<title>Bundle and Library Provisioning</title>
	<para>
	After successful configuration of an instance of the @product.name@ in Eclipse you can use
	the Repository Browser to very easily install bundles and libraries from the remote
	SpringSource Enterprise Bundle Repository.
	</para>
	<para>
	To open the Repository Browser double-click a @product.name@ instance in the Servers
	view and select the "Repository" tab in the server editor. Please note that opening of the
	Editor may take a few seconds as the contents of the local repository needs to be indexed
	before opening.
	</para>
	<para>
	<imagedata fileref="images/tooling-repository-browser.png" format="PNG" />
	</para>
	<para>
	The left section of the Repository Browser allows the user to run searches against the
	@ebr@ and displays matching results. The search can
	take parts of bundle symbolic names, class or package names and allows wildcards such as
	‘?’ and ‘*’. By selecting the checkbox left to a matching bundle and/or library and clicking
	the "Download" button it is very easy to install new bundles in the @product.name@. For your
	convenience JARs containing the bundle source code can be automatically downloaded as well.
	</para>
	<para>
	Clicking the "Download" button will trigger an Eclipse background job that will download
	the selected repository artifacts and -- if desired -- the source JARs one after another.
	</para>
	<para>
	The section on the right displays the currently installed bundles and libraries. Bundles
	with available sources are visually marked. You can very easily download missing source
	JARs by using the "Install Sources" button.
	</para>
	</section>
	<section id="tooling-config">
	<title>Setting up Eclipse Projects</title>
	<para>
	The @product.name@ supports different deployment units as discussed earlier in this guide. The
	Tools define specific project types to support the development of OSGi and PAR projects.
	</para>
	<section id="tooling-config-creating-new-projects">
	<title>Creating New Projects</title>
	<para>
	There are two New Project Wizards available within Eclipse that allow for creating
	new OSGi bundle and PAR projects. The projects created by the wizards are deployable
	to the integrated @short.product.name@ instance without requiring any additional steps.
	</para>
	<para>
	<imagedata fileref="images/tooling-new-project-wizards.png" format="PNG" />
	</para>
	<para>
	Those wizards create the required <code>MANIFEST.MF</code> file and appropriate manifest
	headers.
	</para>
	</section>
	<section id="tooling-config-migrating-existing-projects">
	<title>Migrating existing Java Projects</title>
	<para>
	To migrate an existing Java Project to be used with the @short.product.name@, the Tools
	provide a migration action that adds the required meta data to the project.
	The migration will not change your project’s source layout.
	</para>
	<para>
	Use the context menu action of a project in the Package or Project Explorer and select
	"<menuchoice><guimenu>Spring Tools</guimenu><guimenuitem>Convert to OSGi bundle project</guimenuitem></menuchoice>".
	</para>
	</section>
	<section id="tooling-config-creating-plan-projects">
	<title>Creating Plan Projects</title>
	<para>
	This is done by creating a new <emphasis>faceted</emphasis> project and then applying the OSGi Plan facet.
	This will give you access to features such as content completion when editing <literal>.plan</literal> files
	and deployment to configured servers from within the IDE.
	</para>
	</section>
	</section>
	<section id="tooling-developing" >
	<title>Developing OSGi Bundles</title>
	<para>
	The Tools provide functionality that makes developing OSGi bundles,
	especially the editing of MANIFEST.MF files, easier.
	</para>
	<section id="tooling-developing-resolving-bundle-dependencies">
	<title>Resolving Bundle Dependencies</title>
	<para>
	While working with OSGi bundles, one of the most interesting and challenging aspects is defining
	the package, bundle, and library imports in the manifest and then keeping this in sync
	with your compile classpath either in Ant and Maven or Eclipse. In most cases you would typically
	be required to manually set up the Eclipse classpath. Ultimately, the Eclipse compile
	classpath is still different from the bundle runtime classpath, as normally an entire
	JAR file is being made available on the Eclipse classpath but not necessarily at runtime
	due to the explicit visibility rules defined in <code>Import-Package</code> headers.
	</para>
	<para>
	The Tools address this problem by providing an Eclipse classpath container that
	uses an @product.name@-specific dependency resolution mechanism. This classpath
	container makes resolved dependencies available on the project’s classpath but allows
	only access to those package that are imported explicitly (e.g., via <code>Import-Package</code>)
	or implicitly by using <code>Import-Library</code> or <code>Import-Bundle</code>.
	</para>
	<para>
	To use the automatic dependency resolution, an OSGi bundle or PAR project needs to be
	targeted to a configured @product.name@ instance. This can be done from the project’s
	preferences by selecting the runtime on the "Targeted Runtimes" preference page.
	</para>
	<para>
	<note>
	In most scenarios it is sufficient to target the PAR project to a runtime. The nested
	bundles will then automatically inherit this setting.
	</note>
	</para>
	<para>
	<imagedata fileref="images/tooling-classpath.png" format="PNG" />
	</para>
	<para>
	After targeting the project or PAR you will see a "Bundle Dependencies" classpath
	container in your Java project. It is now safe to remove any manually configured classpath
	entries.
	</para>
	<para>
	The classpath container will automatically attach Java source code to the classpath
	entries by looking for source JARs next to the binary JARs in the @product.name@’s
	repository. You can also manually override the source code attachment by using the
	properties dialog on a single JAR entry. This manual attachment will always override
	the convention-based attachment.
	</para>
	</section>
	<section id="tooling-developing-editing-manifest-mf">
	<title>Editing the Manifest</title>
	<para>
	The Tools provide a Bundle Manifest Editor that assists the developer to create and
	edit MANIFEST.MF files. The editor understands the @product.name@ specific headers
	like <code>Import-Library</code> and <code>Import-Bundle</code> and provides content
	assist features while editing source code. Furthermore a Eclipse Form-based UI is also
	available.
	</para>
	<para>
	To open the Bundle Manifest Editor right click a MANIFEST.MF file and select "Bundle
	Manifest Editor" from the "Open With" menu.
	</para>
	<para>
	<note>
	Please note that the @product.name@ specific manifest headers appear in green color
	to distinguish them from those headers defined in the OSGi specification. This also
	makes navigating much easier.
	</note>
	</para>
	<para>
	<imagedata fileref="images/tooling-manifest-source-editor.png" format="PNG" />
	</para>
	<para>
	The content assist proposals in the source tab as well as in the UI-based tabs are
	resolved from the bundle and library repository of an installed and configured
	@product.name@. Therefore it is important to target the project or PAR to a specific
	@short.product.name@ instance to indicate to the tooling which bundle repository to use.
	</para>
	<para>
	<note>
	If a OSGi bundle project is not targeted to a @short.product.name@ instance, either
	directory or indirectly via a PAR project’s targetting, the manifest editor will not
	be able to provide content assist for importing packages, bundles, and libraries.
	</note>
	</para>
	<para>
	<imagedata fileref="images/tooling-manifest-form-ui-editor.png" format="PNG" />
	</para>
	<para>
	The Dependencies tab of the Bundle Manifest Editor enables the user to easily download
	and install bundles and libraries from the @ebr@
	by using the "Download..." buttons next to the "Import Bundle" and "Import Library"
	sections.
	</para>
	</section>
	</section>
	<section id="tooling-deploying">
	<title>Deploying Applications</title>
	<para>
	Currently the Tools support direct deployment of WTP Dynamic Web Projects, OSGi
	bundle and PAR projects to the @short.product.name@ from directly within Eclipse.
	</para>
	<para>
	To deploy an application to the @product.name@ just bring up the context menu on the configured
	@short.product.name@ runtime in the Servers view and choose "Add or Remove Projects...". In the
	dialog, select the desired project and add it to the list of "Configured projects".
	</para>
	<para>
	<imagedata fileref="images/tooling-deployed-application.png" format="PNG" />
	</para>
	<note>
	<para>
	Deploying and undeploying an application from the @short.product.name@ certainly works
	while the @product.name@ is running, but you can also add or remove projects if the
	@short.product.name@ is not running.
	</para>
	</note>
	<para>
	Once an application is deployed on the @product.name@ the tooling support will automatically
	pick up any change to source files -- for example, Java and XML context files -- and refresh the
	deployed application on the @short.product.name@.
	</para>
	<para>
	The wait time between a change and the actual refresh can be configured
	in the configuration editor of the runtime. To bring up that editor,
	double-click on the configured @product.name@ instance in the Servers view.
	</para>
	</section>
	</chapter>