|
Re: [jet] Controlling the template path [message #1132999 is a reply to message #1132971] |
Fri, 11 October 2013 14:37 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
On 11/10/2013 4:14 PM, Ed Willink wrote:
> Hi
>
> My custom JET templates have suddenly started to fail with 7 "The
> method hasStaticFeatures() is undefined for the type GenClass" errors.
>
> This is no doubt because I moved the tip of my EMF GIT to the latest
> master, picking up
>
> commit 197526f3fa90e8fad36fddd5b0ec4db26369ff11
> [418541] Properly handle static features for dynamic feature delegation
Yes, and that commit clearly includes the new method:
http://git.eclipse.org/c/emf/org.eclipse.emf.git/commit/?id=197526f3fa90e8fad36fddd5b0ec4db26369ff11
>
> However org.eclipse.emf.ecore.codegen is a closed project in my
> workspace, so I am surprised that it is being used at all.
>
> My .jetproperties are
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jet-settings>
> <template-container>templates;@platform:/resource/org.eclipse.emf.codegen.ecore/templates</template-container>
>
> <source-container>jet-gen</source-container>
> </jet-settings>
>
> but changing /resource/ to /plugin/ makes no difference.
>
> Since I cannot find any documentation on the significance of the "@"
> that I copied from MDT/UML2 maybe my usage is inappropriate, but it
> would seem to me that neither setting should be able to use a closed
> project.
Much of the JET infrastructure is low level and operates without much
knowledge of the workspace. Even if there is a bug, "fixes" might be
considered a bug by someone relying on current behavior. I'm surprised
though if platform:/plugin makes no difference, and I'm not sure you
should expect platform:/resource to look anywhere other than the
workspace, so a fix is most likely one that just makes it fail until you
have such a workspace project open...
In any case, if you want me to have a look, including everything I need
in a self contained zip file...
>
> Is my thinking wrong or is it a Bugzilla?
>
> Regards
>
> Ed Willink
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [jet] Controlling the template path [message #1133099 is a reply to message #1132999] |
Fri, 11 October 2013 16:02 |
Ed Willink Messages: 7670 Registered: July 2009 |
Senior Member |
|
|
Hi
https://bugs.eclipse.org/bugs/show_bug.cgi?id=419239 raised.
..../plugin/... works, provided you restart Eclipse after making the
change; it seems the Nature/Builder has a change insensitive cache.
Regards
Ed Willink
On 11/10/2013 15:37, Ed Merks wrote:
> Ed,
>
> Comments below.
>
> On 11/10/2013 4:14 PM, Ed Willink wrote:
>> Hi
>>
>> My custom JET templates have suddenly started to fail with 7 "The
>> method hasStaticFeatures() is undefined for the type GenClass" errors.
>>
>> This is no doubt because I moved the tip of my EMF GIT to the latest
>> master, picking up
>>
>> commit 197526f3fa90e8fad36fddd5b0ec4db26369ff11
>> [418541] Properly handle static features for dynamic feature delegation
> Yes, and that commit clearly includes the new method:
>
> http://git.eclipse.org/c/emf/org.eclipse.emf.git/commit/?id=197526f3fa90e8fad36fddd5b0ec4db26369ff11
>
>
>>
>> However org.eclipse.emf.ecore.codegen is a closed project in my
>> workspace, so I am surprised that it is being used at all.
>>
>> My .jetproperties are
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <jet-settings>
>> <template-container>templates;@platform:/resource/org.eclipse.emf.codegen.ecore/templates</template-container>
>>
>> <source-container>jet-gen</source-container>
>> </jet-settings>
>>
>> but changing /resource/ to /plugin/ makes no difference.
>>
>> Since I cannot find any documentation on the significance of the "@"
>> that I copied from MDT/UML2 maybe my usage is inappropriate, but it
>> would seem to me that neither setting should be able to use a closed
>> project.
> Much of the JET infrastructure is low level and operates without much
> knowledge of the workspace. Even if there is a bug, "fixes" might be
> considered a bug by someone relying on current behavior. I'm surprised
> though if platform:/plugin makes no difference, and I'm not sure you
> should expect platform:/resource to look anywhere other than the
> workspace, so a fix is most likely one that just makes it fail until
> you have such a workspace project open...
>
> In any case, if you want me to have a look, including everything I
> need in a self contained zip file...
>>
>> Is my thinking wrong or is it a Bugzilla?
>>
>> Regards
>>
>> Ed Willink
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.04192 seconds