Bug 447662 - Impossible to evaluate Java services from workspace in an Acceleo3 expression
Summary: Impossible to evaluate Java services from workspace in an Acceleo3 expression
Status: CLOSED FIXED
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 1.0.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.0.0M7   Edit
Assignee: Pierre-Charles David CLA
QA Contact: Maxime Porhel CLA
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2014-10-17 04:50 EDT by Maxime Porhel CLA
Modified: 2015-06-24 11:13 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Porhel CLA 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 CLA 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 CLA 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 CLA 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 CLA 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 CLA 2015-04-27 04:28:58 EDT 
New Gerrit change created: https://git.eclipse.org/r/46531
Comment 7 Pierre-Charles David CLA 2015-04-30 05:28:41 EDT 
Fixed by documentation the limitation.
Comment 8 Maxime Porhel CLA 2015-05-22 04:55:25 EDT 
Validated on Sirius 3.0.0 RC1
Comment 9 Pierre-Charles David CLA 2015-06-24 11:13:10 EDT 
Available in Sirius 3.0.0. See https://wiki.eclipse.org/Sirius/3.0.0.