[447662] Mention A3/Luna's limitation regarding Java services

Also remove notes about limitations of service: which no longer exist.

Bug: 447662
Change-Id: I60430628ba89ea3cdb75a409b7db9d6ef62d18f3
Signed-off-by: Pierre-Charles David <pierre-charles.david@obeo.fr>

2 files changed, 11 insertions, 24 deletions

diff --git a/plugins/org.eclipse.sirius.doc/doc/specifier/general/Writing_Queries.html b/plugins/org.eclipse.sirius.doc/doc/specifier/general/Writing_Queries.html
index b77367ed75..0531dd3899 100644
--- a/plugins/org.eclipse.sirius.doc/doc/specifier/general/Writing_Queries.html
+++ b/plugins/org.eclipse.sirius.doc/doc/specifier/general/Writing_Queries.html
@@ -154,28 +154,13 @@
 				<code>getEClasses</code> on the current element if it is an instance of 
 				<code>EPackage</code>.
 				<ul>
-					<li>
-						<em>Note 1</em>: The service interpreter supports parameters, but only variables can be used as parameter (no literals or complex expressions), for example: 
+					<li>The service interpreter supports parameters, but only variables can be used as parameter (no literals or complex expressions), for example: 
 						<code>service:serviceName(view, diagram)</code>.
 					</li>
-					<li>
-						<em>Note 2</em>: You can use the service interpreter not only on the current context by using a variable name before calling the service, for example: 
+					<li>You can use the service interpreter not only on the current context by using a variable name before calling the service, for example: 
 						<code>service:myVariableName.serviceName</code>.
 					</li>
-					<li>Intended limitations exist to be more efficient:
-						<ul>
-							<li>The services should be in the same 
-								<code>bundle</code> as the VSM and should be deployed. If the services already exist in another 
-								<code>bundle</code>, you must declare a &#171;proxy&#187; in the 
-								<code>bundle</code> of the 
-								<em>VSM</em>.
-							</li>
-							<li>If multiple services match the expression, the first one found is used. There is no real polymorphism management.</li>
-						</ul>
-					</li>
-					<li>
-						<em>Tips</em>: You could put your bundle in workspace and runtime to have completion enabled on the service interpreter. 
-					</li>
+					<li>For efficiency reasons, if multiple services match the expression, the first one found is used. There is no real polymorphism management.</li>
 				</ul>
 			</li>
 		</ul>
@@ -224,6 +209,9 @@
 			<em>not</em> the value of the object&#8217;s property. To avoid ambiguity, always use expressions of the form 
 			<code>"[self.target/]"</code> in such cases.
 		</p>
+		<p>
+			<em>Note:</em> Due to internal changes in the Eclipse Equinox runtime, starting with Eclipse Luna (4.4) it is impossible to evaluate Java services from an Acceleo 3 expression if the Java service is defined directly in the workspace. This only affect specifiers (not end-users). When developing modelers which use Acceleo expressions and rely on Java services, you must launch an Eclipse runtime from your development environement to test the resulting modeler in a context where the service is available as part of a deployed plug-in. Starting with Sirius 3.0 you can also use the AQL language instead, which has a syntax very similar to Acceleo 3/MTL, but does not have this limitation regarding services in the workspace.
+		</p>
 		<h2 id="ocl">Using Raw OCL</h2>
 		<p>Sirius also supports raw OCL expressions, but this support is deprecated and will be removed in future versions. OCL expressions must be prefixed with 
 			<code>ocl:</code>. If you use it your Sirius project must declare a dependency to the 
diff --git a/plugins/org.eclipse.sirius.doc/doc/specifier/general/Writing_Queries.textile b/plugins/org.eclipse.sirius.doc/doc/specifier/general/Writing_Queries.textile
index b51d7b005d..daf98ffc30 100644
--- a/plugins/org.eclipse.sirius.doc/doc/specifier/general/Writing_Queries.textile
+++ b/plugins/org.eclipse.sirius.doc/doc/specifier/general/Writing_Queries.textile
@@ -52,12 +52,9 @@ Sirius provides several specialized interpreters to handle more efficiently some
 ** @feature:eAllContents@ returns all the elements directly and indirectly contained inside the current element (or an empty collection if there is none). This is equivalent to <code>[self.eAllContents()/]</code>.
 ** @feature:eCrossReferences@ returns all the model elements which are directly referenced by the current element (or an empty collection if there is none). This is equivalent to <code>[self.eCrossReferences()/]</code>.
 * *@service:@* This interpreter can be used to directly invoke a service method (i.e. a Java method that follows conventions for "service methods":#service_methods ) on the current element. For example, assuming the service class "@EcoreServices@":#ecore_services has been correctly registered in the VSM, the expression @service:getEClasses@ (note the absence of parenthesis) will invoke the @getEClasses@ on the current element if it is an instance of @EPackage@.
-** _Note 1_: The service interpreter supports parameters, but only variables can be used as parameter (no literals or complex expressions), for example: @service:serviceName(view, diagram)@.
-** _Note 2_: You can use the service interpreter not only on the current context by using a variable name before calling the service, for example: @service:myVariableName.serviceName@.
-** Intended limitations exist to be more efficient:
-*** The services should be in the same @bundle@ as the VSM and should be deployed. If the services already exist in another @bundle@, you must declare a "proxy" in the @bundle@ of the _VSM_.
-*** If multiple services match the expression, the first one found is used. There is no real polymorphism management.
-** _Tips_: You could put your bundle in workspace and runtime to have completion enabled on the service interpreter. 
+** The service interpreter supports parameters, but only variables can be used as parameter (no literals or complex expressions), for example: @service:serviceName(view, diagram)@.
+** You can use the service interpreter not only on the current context by using a variable name before calling the service, for example: @service:myVariableName.serviceName@.
+** For efficiency reasons, if multiple services match the expression, the first one found is used. There is no real polymorphism management.
 
 h2(#acceleo). Using Acceleo
 
@@ -77,6 +74,8 @@ In the context of Sirius, you have access to a special feature which can be used
 
 Note that in most cases, expressions in Sirius are evaluated in a context where _variables_ are defined. For example, most expressions inside tool definitions have access to variables telling them which elements the tool has been applied on. In some cases, the names of these variable can conflict with names of features in your meta-model. The evaluation rules of Acceleo (OCL actually) give precedence to variables, so it is recommended to always prefix accesses to your meta-model features with @self@ (or another expression) to avoid ambiguity. As a concrete example, say you have an expression @"[target/]"@ that you expect to access the @target@ feature of one of your object. If evaluated in a context where a @target@ variable exist, the value of the expression will be the value of the variable, _not_ the value of the object's property. To avoid ambiguity, always use expressions of the form @"[self.target/]"@ in such cases.
 
+_Note:_ Due to internal changes in the Eclipse Equinox runtime, starting with Eclipse Luna (4.4) it is impossible to evaluate Java services from an Acceleo 3 expression if the Java service is defined directly in the workspace. This only affect specifiers (not end-users). When developing modelers which use Acceleo expressions and rely on Java services, you must launch an Eclipse runtime from your development environement to test the resulting modeler in a context where the service is available as part of a deployed plug-in. Starting with Sirius 3.0 you can also use the AQL language instead, which has a syntax very similar to Acceleo 3/MTL, but does not have this limitation regarding services in the workspace.
+
 h2(#ocl). Using Raw OCL
 
 Sirius also supports raw OCL expressions, but this support is deprecated and will be removed in future versions. OCL expressions must be prefixed with @ocl:@. If you use it your Sirius project must declare a dependency to the @org.eclipse.sirius.common.ocl@ plug-in to ensure OCL support will be available wherever your modelers are used.