Home » Modeling » M2T (model-to-text transformation) » [Acceleo] Meta-model URI resolution query
| [Acceleo] Meta-model URI resolution query [message #628696] |
Thu, 23 September 2010 17:21  |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
How does Acceleo (3.0.0) locate meta-models in the current workspace?
I am referencing a number of models as
[module boilerplate(
'http://www.eclipse.org/ocl/3.1.0/CompleteOCLCST',
'http://www.eclipse.org/ocl/3.1.0/OCLinEcoreCST',
'http://www.eclipse.org/ocl/3.1.0/BaseCST',
'http://www.eclipse.org/emf/2002/Ecore',
'http://www.eclipse.org/ocl/3.1.0/Pivot',
'http://www.omg.org/ocl/markup/Markup')/]
and although these are genmodeled, they are only genmodeled in my
current workspace and, unlike QVTo, there is no registration facility to
bind e.g. http://www.eclipse.org/ocl/3.1.0/Pivot to platform:/resource/....
So I don't understand why this very nearly works. I just get a couple of
relatively random 'Cannot find ...' diagnostics rather than the hundreds
and hundreds that I would expect. Two are on operations but a third is
just on a three deep dot navigation.
However when I run the identical plugin in a nested Eclipse so that all
the above experience plugin registrations the errors vanish. Surely it
should either be the same, or the outer Eclipse should fail
catastrophically?
Regards
Ed Willink
|
|
|
| Re: [Acceleo] Meta-model URI resolution query [message #628781 is a reply to message #628696] |
Fri, 24 September 2010 06:44  |
|
Hi Ed,
I don't really understand what you mean here. Do you have a bug and want us to try and see why? Or do you get no bug where you expected one?
As for locating models, Acceleo searches within the dependencies of your generation project for models. Whether these dependencies are in the plugins or in the workspace doesn't matter : if they are in the plugins, then fine, the NsURI is in the EPackage registry and we don't meddle with anything. However, if we find one of these dependencies in the workspace (even if it is also in the installed plugins), we'll register the model in our own package registry (we have a "proxy" package registry in order to register workspace models without altering the "global" package registry).
Laurent Goubet
Obeo
|
|
|
| Re: [Acceleo] Meta-model URI resolution query [message #628827 is a reply to message #628781] |
Fri, 24 September 2010 10:09 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Laurent
Thanks. That explains some things. Acceleo is being 'helpful' by
auto-registering anything that it can find on the 'classpath'. This may
account for some difficulties I've had whereby platform:/plugin
meta-models have not been coherently occluded by platform:/resource
meta-models.
[I think QVTo's properties page mapping, of the variously UMLX, QVTd,
OCL properties page registry mapping is more appropriate, since it
allows the user to specify exactly which meta-models apply regardless of
any accidental Java configuration. Auto-registering is also a problem in
that it requires every possible model to be loaded, rather than just
those that are required.]
Since Acceleo is auto-registering, there should be no need for my nested
Eclipse invocation, so I shall try to raise a Bugzilla with a smaller
repro of how my usage is failing.
There also seem to be weird classpath behaviours associated with the
launch configurations. I find Java works much better than Acceleo, at
least the JDT debugger works, but it seems captive so anything that
triggers a rebuild may lock Eclipse up if the debugger is suspended at a
breakpoint.
It would be good to have a clear section in the documentation of how
Acceleo uses class paths for a) in-editor resolution, b) Java launches,
c) plugin launches, d) standalone.
Regards
Ed Willink
On 24/09/2010 07:44, Laurent Goubet wrote:
> Hi Ed,
>
> I don't really understand what you mean here. Do you have a bug and want
> us to try and see why? Or do you get no bug where you expected one?
>
> As for locating models, Acceleo searches within the dependencies of your
> generation project for models. Whether these dependencies are in the
> plugins or in the workspace doesn't matter : if they are in the plugins,
> then fine, the NsURI is in the EPackage registry and we don't meddle
> with anything. However, if we find one of these dependencies in the
> workspace (even if it is also in the installed plugins), we'll register
> the model in our own package registry (we have a "proxy" package
> registry in order to register workspace models without altering the
> "global" package registry).
>
> Laurent Goubet
> Obeo
|
|
|
| Re: [Acceleo] Meta-model URI resolution query [message #628836 is a reply to message #628827] |
Fri, 24 September 2010 11:27 |
|
This is a multi-part message in MIME format.
--------------040704080106050308010500
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Ed,
A small example on how to reproduce your particular bug would be helpful
indeed : we know we have problems with workspace and dynamic models, but
have yet to isolate precise failure points.
We do prefer auto-registering rather than a preference page for the sake
of user experience; if you do encounter bugs, chances are you would
encounter them even if we had delegated the registration to you/the user.
Laurent Goubet
Obeo
Ed Willink wrote:
> Hi Laurent
>
> Thanks. That explains some things. Acceleo is being 'helpful' by
> auto-registering anything that it can find on the 'classpath'. This may
> account for some difficulties I've had whereby platform:/plugin
> meta-models have not been coherently occluded by platform:/resource
> meta-models.
>
> [I think QVTo's properties page mapping, of the variously UMLX, QVTd,
> OCL properties page registry mapping is more appropriate, since it
> allows the user to specify exactly which meta-models apply regardless of
> any accidental Java configuration. Auto-registering is also a problem in
> that it requires every possible model to be loaded, rather than just
> those that are required.]
>
> Since Acceleo is auto-registering, there should be no need for my nested
> Eclipse invocation, so I shall try to raise a Bugzilla with a smaller
> repro of how my usage is failing.
>
> There also seem to be weird classpath behaviours associated with the
> launch configurations. I find Java works much better than Acceleo, at
> least the JDT debugger works, but it seems captive so anything that
> triggers a rebuild may lock Eclipse up if the debugger is suspended at a
> breakpoint.
>
> It would be good to have a clear section in the documentation of how
> Acceleo uses class paths for a) in-editor resolution, b) Java launches,
> c) plugin launches, d) standalone.
>
> Regards
>
> Ed Willink
>
>
> On 24/09/2010 07:44, Laurent Goubet wrote:
>> Hi Ed,
>>
>> I don't really understand what you mean here. Do you have a bug and want
>> us to try and see why? Or do you get no bug where you expected one?
>>
>> As for locating models, Acceleo searches within the dependencies of your
>> generation project for models. Whether these dependencies are in the
>> plugins or in the workspace doesn't matter : if they are in the plugins,
>> then fine, the NsURI is in the EPackage registry and we don't meddle
>> with anything. However, if we find one of these dependencies in the
>> workspace (even if it is also in the installed plugins), we'll register
>> the model in our own package registry (we have a "proxy" package
>> registry in order to register workspace models without altering the
>> "global" package registry).
>>
>> Laurent Goubet
>> Obeo
>
--------------040704080106050308010500
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyIj5PYmVvPC9hPg0KZW1haWw7 aW50ZXJuZXQ6
bGF1cmVudC5nb3ViZXRAb2Jlby5mcg0KdXJsOmh0dHA6Ly93d3cub2Jlby5m cg0KdmVyc2lv
bjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------040704080106050308010500--
|
|
|
| Re: [Acceleo] Meta-model URI resolution query [message #628856 is a reply to message #628836] |
Fri, 24 September 2010 13:04 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Laurent
There's probably a half-way house that's much better for everyone.
A property page that can auto-initialize/update for use of ease,
that displays the prevailing bindings for debugging,
that allows explicit control for developers.
Regards
Ed
On 24/09/2010 12:27, Laurent Goubet wrote:
> Ed,
>
> A small example on how to reproduce your particular bug would be helpful
> indeed : we know we have problems with workspace and dynamic models, but
> have yet to isolate precise failure points.
>
> We do prefer auto-registering rather than a preference page for the sake
> of user experience; if you do encounter bugs, chances are you would
> encounter them even if we had delegated the registration to you/the user.
>
> Laurent Goubet
> Obeo
>
> Ed Willink wrote:
>> Hi Laurent
>>
>> Thanks. That explains some things. Acceleo is being 'helpful' by
>> auto-registering anything that it can find on the 'classpath'. This
>> may account for some difficulties I've had whereby platform:/plugin
>> meta-models have not been coherently occluded by platform:/resource
>> meta-models.
>>
>> [I think QVTo's properties page mapping, of the variously UMLX, QVTd,
>> OCL properties page registry mapping is more appropriate, since it
>> allows the user to specify exactly which meta-models apply regardless
>> of any accidental Java configuration. Auto-registering is also a
>> problem in that it requires every possible model to be loaded, rather
>> than just those that are required.]
>>
>> Since Acceleo is auto-registering, there should be no need for my
>> nested Eclipse invocation, so I shall try to raise a Bugzilla with a
>> smaller repro of how my usage is failing.
>>
>> There also seem to be weird classpath behaviours associated with the
>> launch configurations. I find Java works much better than Acceleo, at
>> least the JDT debugger works, but it seems captive so anything that
>> triggers a rebuild may lock Eclipse up if the debugger is suspended at
>> a breakpoint.
>>
>> It would be good to have a clear section in the documentation of how
>> Acceleo uses class paths for a) in-editor resolution, b) Java launches,
>> c) plugin launches, d) standalone.
>>
>> Regards
>>
>> Ed Willink
>>
>>
>> On 24/09/2010 07:44, Laurent Goubet wrote:
>>> Hi Ed,
>>>
>>> I don't really understand what you mean here. Do you have a bug and want
>>> us to try and see why? Or do you get no bug where you expected one?
>>>
>>> As for locating models, Acceleo searches within the dependencies of your
>>> generation project for models. Whether these dependencies are in the
>>> plugins or in the workspace doesn't matter : if they are in the plugins,
>>> then fine, the NsURI is in the EPackage registry and we don't meddle
>>> with anything. However, if we find one of these dependencies in the
>>> workspace (even if it is also in the installed plugins), we'll register
>>> the model in our own package registry (we have a "proxy" package
>>> registry in order to register workspace models without altering the
>>> "global" package registry).
>>>
>>> Laurent Goubet
>>> Obeo
>>
>
|
|
| |
| Re: [Acceleo] Meta-model URI resolution query [message #629655 is a reply to message #629043] |
Wed, 29 September 2010 07:07 |
|
This is a multi-part message in MIME format.
--------------010906090300010002060103
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi Mirko,
The 3.0 release of Acceleo has problems with dynamic/workspace models. A
number of bugzilla issues have been raised for this and even more
newsgroup messages. Stabilizing this support is part of our plans for
3.1, for now please assume that we only support "single" dynamic models
(not referencing another dynamic model as in your case).
Laurent Goubet
Obeo
Mirko Seifert wrote:
> I have a similar problem. I have two metamodels in my workspace, which
> are not registered in the Eclipse instance (only in runtime instances).
> One of the metamodels is an extension of the other. For example, there
> is an EClass (A) which extends another class (B) from the extended
> metamodel.
> Unfortunately, Acceleo does not find the features of B when I invoke
> code completion on an instance of A in a template. I guess there is a
> problem with resolving the references from B to A, but I'm not sure.
>
> I do reference the metamodels from my template using the absolute path
> (/pluginname/metamodel/a.ecore) - not by the namespace URI. I'll post a
> bug with a minimal example.
>
> In the meantime: Is there any known issues regarding this behavior?
> Maybe I'm doing something wrong?
--------------010906090300010002060103
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyIj5PYmVvPC9hPg0KZW1haWw7 aW50ZXJuZXQ6
bGF1cmVudC5nb3ViZXRAb2Jlby5mcg0KdXJsOmh0dHA6Ly93d3cub2Jlby5m cg0KdmVyc2lv
bjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------010906090300010002060103--
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 05:00:54 GMT 2024
Powered by FUDForum. Page generated in 0.05055 seconds |
] 
Search
Help
Register
Login
Home
