Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 447662

Summary:	Impossible to evaluate Java services from workspace in an Acceleo3 expression
Product:	[Modeling] Sirius	Reporter:	Maxime Porhel <maxime.porhel>
Component:	Core	Assignee:	Pierre-Charles David <pierre-charles.david>
Status:	CLOSED FIXED	QA Contact:	Maxime Porhel <maxime.porhel>
Severity:	normal
Priority:	P3	CC:	florian.barbin, jerome.pequery, pierre-charles.david
Version:	1.0.1	Keywords:	triaged
Target Milestone:	3.0.0M7
Hardware:	All
OS:	All
See Also:	https://git.eclipse.org/r/46531 https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=2ec5c18199303f9625aa53eb52e1a691f65dde82
Whiteboard:

Description Maxime Porhel

2014-10-17 04:50:44 EDT

If you define a Java service, the Acceleo3 interpreter is able to show it in its completion proposals. But the evaluation will fail if you are developing and testing your VSM in the same Eclipse instance. This java service calls in Acceleo3 expressions used to work in this 'live editing' mode.

The workaround is to launch a runtime to 'deploy' the service, and import (without copying it) the VSP in the runtime to continue to use the 'live editing' capabilities for the mappings, styles, tools, ...

Comment 1 Pierre-Charles David

2014-10-26 09:44:28 EDT

I believe we can not do anything about this, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=419205.

Basically, since Luna the underlying Equinox framework changes have removed the possibility for Acceleo to do the "magic" live deployment of OSGi bundles which are needed to invoke Java code defined in the workspace without starting a separate runtime. Note that like all "magic" behaviors, it was very brittle anyway.

I'm really tempted to close this as WONTFIX: *if* Equinox supported such a mechanism and *if* Acceleo 3 made use of it, Sirius would probably support this scenario with no change needed (as it did pre-Luna). As it is, there is nothing wrong in Sirius, simply a limitation (regression) in the possibilities of one of the query languages we have an adapter for, and I don't think it is our responsibility to fix this.

The only issue I see here which concerns Sirius itself is to make sure that this restriction is correctly documented.

Comment 2 Pierre-Charles David

2014-12-29 10:23:37 EST

Moving to M5, but only to properly document the limitation, not to try to workaround it.

Comment 3 Pierre-Charles David

2015-03-04 04:38:07 EST

Note that with bug #460947, this limitation may be lifted for AQL itself (but unless that work is also intergrated in the main Acceleo engine, the limitation will still hold for Acceleo itself).

Comment 4 Pierre-Charles David

2015-03-17 04:34:10 EDT

Moving to M7; we'll see how the work on AQL impacts the way we want to word this.

Comment 5 Eclipse Genie

2015-04-27 04:28:58 EDT

New Gerrit change created: https://git.eclipse.org/r/46531

Comment 6 Eclipse Genie

2015-04-30 05:28:07 EDT

Gerrit change https://git.eclipse.org/r/46531 was merged to [master].
Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=2ec5c18199303f9625aa53eb52e1a691f65dde82

Comment 7 Pierre-Charles David

2015-04-30 05:28:41 EDT

Fixed by documentation the limitation.

Comment 8 Maxime Porhel

2015-05-22 04:55:25 EDT

Validated on Sirius 3.0.0 RC1

Comment 9 Pierre-Charles David

2015-06-24 11:13:10 EDT

Available in Sirius 3.0.0. See https://wiki.eclipse.org/Sirius/3.0.0.