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 13:21  |
Eclipse User |
|
|
|
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 #628827 is a reply to message #628781] |
Fri, 24 September 2010 06:09  |
| Eclipse User |
|
|
|
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 07:27 |
| Eclipse User |
|
|
|
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 09:04 |
| Eclipse User |
|
|
|
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
>>
>
|
|
| | | |
Goto Forum:
Current Time: Thu Apr 24 04:14:19 EDT 2025
Powered by FUDForum. Page generated in 0.03192 seconds |
Home