Minor corrections to release notes

svn changeset:10419/svn branch:6.2

1 files changed, 12 insertions, 12 deletions

diff --git a/WebContent/release-notes.html b/WebContent/release-notes.html
index 0672acaf21..a0d5bf20b3 100644
--- a/WebContent/release-notes.html
+++ b/WebContent/release-notes.html
@@ -45,7 +45,7 @@ contains a number of significant enhancements.</p>
 
         <li>A widget set definition class is no longer used. Java code needed for widget
         instantiation and client-server mapping is automatically generated by GWT
-        compiler. For common Vaadin user, Widgetset is now only a GWT module definition
+        compiler. For a common Vaadin user, Widgetset is now only a GWT module definition
         file (.gwt.xml).</li>
   
         <li>Server-side component is mapped to a client-side widget with an annotation:
@@ -71,10 +71,10 @@ public class ColorPicker extends AbstractField {</pre>
     <ul>
 	    <li>On the server-side:</li>
 	    <ul>
-	       <li>Listeners are now easier to implement  with <tt>ReflectTools.findMethod()</tt>
-			and <tt>addListener(String eventIdentifier, Class&lt;?&gt;
-			eventType, Object target, Method method)</tt> methods. The latter
-			automatically inform the client-side that a listener is registered on server side)</li>
+	        <li>Listeners for custom client side events are now easier to implement with
+	        <tt>ReflectTools.findMethod()</tt> and <tt>addListener(String eventIdentifier,
+	        Class&lt;?&gt; eventType, Object target, Method method)</tt> methods. The latter
+		    automatically informs the client-side that a listener is registered on server side)</li>
 		</ul>
         <li>On the client-side:</li>
         <ul>
@@ -118,13 +118,13 @@ public class ColorPicker extends AbstractField {</pre>
     </ul>
     <li>Additional Maven archetypes</li>
     <ul>
-        <li><b>vaadin-archetype-clean</b> with dependency to Vaadin and a minimal application skeleton, no client side widgets</li>
+        <li><b>vaadin-archetype-clean</b> with a dependency to Vaadin and a minimal application skeleton, no client side widgets</li>
         <li><b>vaadin-archetype-widget</b> for creation of Vaadin 6.2 widget packages</li>
         <li><b>vaadin-archetype-sample</b> has been updated for Vaadin 6.2 - use version 1.0.x for earlier Vaadin versions</li>
     </ul>
     <li>Maven Vaadin plugin</li>
     <ul>
-        <li><b>vaadin-maven-plugin</b> can automatically update Vaadin 6.2 widgetsets based on Maven dependencies using the goal <b>update-widgetset</b></li>
+        <li><b>vaadin-maven-plugin</b> can automatically update Vaadin 6.2 widgetsets based on Maven dependencies using the goal <tt>update-widgetset</tt></li>
     </ul>
     <li><b>HttpServletRequestListener</b></li>
     <ul>
@@ -199,7 +199,7 @@ If you package a widget set as a JAR for use in other projects:
   </ul>
   <li>Install new GWT JARs if the GWT version has changed</li>
   <ul>
-    <li>The Eclipse plugin will download the new GWT automatically when you update the Vaadin version; you will need to update GWT paths in the widget set compilation launch configurations in Eclipse (<a href="http://dev.vaadin.com/ticket/3286">#3286</a>).
+    <li>The Eclipse plugin will automatically download the new GWT and update launch configurations and the project build path when you update the Vaadin version.</li>
   </ul>  
   <li>If you have custom widget sets, recompile them with the new Vaadin library using the included GWT compiler</li>
   <li>If using the Eclipse IDE:
@@ -311,10 +311,10 @@ under the Google App Engine.</p>
   <li><p>DO NOT update application state when serving an <b>ApplicationResource</b> (e.g <b>ClassResource</b>.<i>getStream()</i>).</p></li>
 
   <li><p>AVOID (or be very careful when) updating application state in a
-  <b>TransactionListener</b> - it is called even when the application is not locked and
-  won't be serialized (e.g <b>ApplicationResource</b>), and changes can thus go missing (it
-  should be safe to update things that can be safely discarded later - i.e valid only for
-  the current request)</p></li>
+  <b>TransactionListener</b> or a <b>HttpServletRequestListener</b> - they are called even when the
+  application is not locked and won't be serialized (e.g <b>ApplicationResource</b>), and
+  changes can thus go missing (it should be safe to update things that can be safely discarded
+  later - i.e valid only for the current request)</p></li>
 
   <li><p>The application remains locked during uploads - a progress bar is not possible</p></li>
 </ul>