Add a paragraph about publishing
diff --git a/tooling-guide/src/developing_with_PDE.xml b/tooling-guide/src/developing_with_PDE.xml
index 469c635..2f8c570 100644
--- a/tooling-guide/src/developing_with_PDE.xml
+++ b/tooling-guide/src/developing_with_PDE.xml
@@ -43,7 +43,7 @@
<para>
Developers should properly setup a local @umbrella.product.name@ so that its bundle repositories
contain their application dependencies. Then they should use the Tools to setup a PDE Target Platform
- so that their workspace projects are build and resolved against the same bundles that will be available
+ so that their workspace projects are built and resolved against the same bundles that will be available
at runtime.
</para>
<note>
@@ -160,6 +160,32 @@
and related tooling to work with the newly created project. Please refer to the official PDE documentation for further details.</note>
</para>
</section>
+ <section id="resource-publishing">
+ <title>Publishing</title>
+ <para>
+ The Virgo Server Editor includes a section to select when publishing to the server runtime should take place.
+ The section offers three options:
+ <simplelist>
+ <member>immediate publish on resource change</member>
+ <member>publish after build</member>
+ <member>never publish automatically</member>
+ </simplelist>
+ Immediate publish means that a change to a file in a bundle project deployed on the @umbrella.product.name@ will be automatically published, triggering in most cases a
+ re-deploy of the bundle project, as soon as the file is saved.
+ Publish after build means that a change to one or more files will be automatically published, triggering in most cases a re-deploy, when the containing project
+ is built, either because workspace auto-build is enabled or because the user requested a workspace or project build.
+ Never publish automatically means that publishing will take place only on user request, via the "Publish" action on the Servers view.
+ </para>
+ <para>
+ While automatic publishing reduces the learning curve for beginners, it may also imply longer waits on large workspaces with many bundle projects deployed to a server, because
+ the re-deploy of a project also implies the re-deploy of all dependent projects.
+ On large workspaces it's recommend to turn off auto-publish and to manually publish bundles as needed. In fact, when the server is running in debug mode,
+ if a source file is changed without altering the external "signature" of a class the Java Virtual Machine will be able to push the new byte-code to the server without requiring
+ a re-deploy of the containing bundle and dependencies. In such case the developer can simply save and build and the Java Virtual Machine will perform the hot-code replace.
+ When the source code change affects the "signature" of a class (such as a change in the signature of a method, a change in inheritance, the addition/removal of new properties of methods)
+ the Java Virtual Machine won't be able to perform the hot-code replace and in such case the user can manually invoke the publish action to trigger a re-deploy of the involved bundle.
+ </para>
+ </section>
<section id="pde-migration-actions">
<title>Migration actions</title>
<para>
