Eclipse Community Forums: EMF » Custom EMF JetTemplates: Uses wrong compiled template

Help

Home

Home » Modeling » EMF » Custom EMF JetTemplates: Uses wrong compiled template

Show: Today's Messages :: Show Polls :: Message Navigator

Custom EMF JetTemplates: Uses wrong compiled template [message #731190]

Fri, 30 September 2011 08:11

Hauke Fuhrmann

Messages: 333
Registered: July 2009

Senior Member

Hi there,

I'm trying to get customization of EMF Jet Templates to work.
Unfortunately, the codegen does not pick up my custom templates.

I did:
1. create EMF project "foo" with "model" folder containing ecore and
genmodel

2. create source "templates" folder in foo

3. copy templates from org.eclipse.emf.codegen to templates folder in
foo, keeping folder structure,
e.g. foo/templates/edit/plugin.propertiesjet

4. in genmodel set "dynamic templates" to true

5. in genmodel set Template Directory to
* templates
* foo/templates
* platform:/plugin/foo/templates
I tried all of them and nothing worked

So far nothing is changed when I do codegen.
I have a project called .JETEmitters in my workspace. It contains a
class "PluginProperties_.java" that seems to be updated regularly,
however, the changes in my plugin.propertiesjet are NOT visible there.

6. tried to make foo a JET project:
New -> JET -> Convert Projects to JET Projects -> foo

7. edit foo's project JET properties:
template dir: "templates"
source dir: "src-gen"

Now PluginProperties.java is generated to foo/src-gen which is a source
folder and compiles correctly (added missing dependencies). It contains
the customizations.

Still, the genmodel-codegen seems to use
..JETEmitters/src/..../PluginProperties.java instead, which does not
contain the customizations.

I cannot even move the correct foo/PluginProperties.java to
..JETEmitters, because the files there are regularly re-generated and
overwritten.

What's wrong?

Cheers,
Hauke

Report message to a moderator

Re: Custom EMF JetTemplates: Uses wrong compiled template [message #731235 is a reply to message #731190]

Fri, 30 September 2011 10:56

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Hauke

> 5. in genmodel set Template Directory to
> * templates
> * foo/templates
> * platform:/plugin/foo/templates
> I tried all of them and nothing worked
Try "/foo/templates" similar to "/foo/src" for the model folder. Perhaps
"platform:/plugin/foo/templates" might work too.

I presume you're not trying to make this work standalone; JMerge
requires plugin access to the Java compiler.

Regards

Ed Willink

Report message to a moderator

Re: Custom EMF JetTemplates: Uses wrong compiled template [message #731289 is a reply to message #731190]

Fri, 30 September 2011 13:42

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Hauke,

Comments below.

On 30/09/2011 1:11 AM, Hauke Fuhrmann wrote:
> Hi there,
>
> I'm trying to get customization of EMF Jet Templates to work.
> Unfortunately, the codegen does not pick up my custom templates.
>
> I did:
> 1. create EMF project "foo" with "model" folder containing ecore and
> genmodel
>
> 2. create source "templates" folder in foo
>
> 3. copy templates from org.eclipse.emf.codegen to templates folder in
> foo, keeping folder structure,
> e.g. foo/templates/edit/plugin.propertiesjet
>
> 4. in genmodel set "dynamic templates" to true
>
> 5. in genmodel set Template Directory to
> * templates
> * foo/templates
I'd expect you to use "/foo/templates"
> * platform:/plugin/foo/templates
It's going to look for a bundle with ID foo (not a good bundle ID BTW)
and try to find compiled templates in there. You can look at the
handleing in this case.

else if (templateURI.isPlatformPlugin())
{
This will be useful if you actually deploy your extension into the IDE
for others to reuse (but you've not gotten that far).
> I tried all of them and nothing worked
>
> So far nothing is changed when I do codegen.
> I have a project called .JETEmitters in my workspace. It contains a
> class "PluginProperties_.java" that seems to be updated regularly,
> however, the changes in my plugin.propertiesjet are NOT visible there.
>
> 6. tried to make foo a JET project:
> New -> JET -> Convert Projects to JET Projects -> foo
This is only use if you want to deploy your extension.
>
> 7. edit foo's project JET properties:
> template dir: "templates"
> source dir: "src-gen"
>
> Now PluginProperties.java is generated to foo/src-gen which is a
> source folder and compiles correctly (added missing dependencies). It
> contains the customizations.
>
> Still, the genmodel-codegen seems to use
> .JETEmitters/src/..../PluginProperties.java instead, which does not
> contain the customizations.
>
> I cannot even move the correct foo/PluginProperties.java to
> .JETEmitters, because the files there are regularly re-generated and
> overwritten.
>
> What's wrong?
>
> Cheers,
> Hauke

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Custom EMF JetTemplates: Uses wrong compiled template [message #731349 is a reply to message #731190]

Fri, 30 September 2011 17:13

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Hauke
>
> I'm trying to get customization of EMF Jet Templates to work.
> Unfortunately, the codegen does not pick up my custom templates.
There are some very unpleasant gotchas for novices.

The template directory is a path contribution so there is no diagnostic
when it is useless, and so you get output files generated by the
templates. Once you get the path right....

If, in order to test whether customized templates are in use, you modify
a template to include some distinctive comments, these do not appear
when you re-genmodel, because JMerge does not replace comments on
otherwise unchanged declarations. There are also some silenced NPEs in
JMerge that can also cause no change.

Make sure you delete the output files before test runs.

Regards

Ed Willink

Report message to a moderator

Re: Custom EMF JetTemplates: Uses wrong compiled template [message #732258 is a reply to message #731289]

Tue, 04 October 2011 10:46

Hauke Fuhrmann

Messages: 333
Registered: July 2009

Senior Member

Ed,

thanks for your comments. It still does not work, see comments below.

Am 30.09.2011 15:42, schrieb Ed Merks:
>> 5. in genmodel set Template Directory to
>> * templates
>> * foo/templates
> I'd expect you to use "/foo/templates"

If I do this, it will be extended to
platform:/resource/foo/templates lateron. Still, nothing happens.

>> * platform:/plugin/foo/templates
> It's going to look for a bundle with ID foo (not a good bundle ID BTW)
> and try to find compiled templates in there. You can look at the
> handleing in this case.
>
> else if (templateURI.isPlatformPlugin())
> {
> This will be useful if you actually deploy your extension into the IDE
> for others to reuse (but you've not gotten that far).

Looking into the code of JETEmitter line 506ff., it seems to be vice versa:

* If the URI is a platform Resource (either /foo/templates or
platform:/resource/foo/templates), it expects the JET nature and only
looks for precompiled templates (return silently if there is no JET
nature as it is in my case).

* If the URI is a platform Plugin (platform:/plugin/foo/templates) it
looks for the corresponding bundle in the current platform. This is not
available here. So it fails silently.

Is this a bug or do I need to use platform resource + pre-compiled
templates?

if (jetEmitter.templateURIPath != null)
{
URI templateURI = URI.createURI(jetEmitter.templateURIPath[0]);
URLClassLoader theClassLoader = null;
if (templateURI.isPlatformResource())
{
// If the template path points at a project with a JET Nature,
// then we will assume that the templates we want to use are
already compiled in this plugin Java project.
IProject project
=workspace.getRoot().getProject(templateURI.segment(1));
if (JETNature.getRuntime(project) != null)
{

Cheers,
Hauke

Report message to a moderator

Re: Custom EMF JetTemplates: Uses wrong compiled template [message #732261 is a reply to message #731289]

Tue, 04 October 2011 10:46

Hauke Fuhrmann

Messages: 333
Registered: July 2009

Senior Member

Report message to a moderator

Re: Custom EMF JetTemplates: Uses wrong compiled template [message #733384 is a reply to message #732258]

Tue, 04 October 2011 15:40

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hauke, 
 
Comments below. 
 
On 04/10/2011 3:46 AM, Hauke Fuhrmann wrote:
<blockquote cite="mid:j6enf2$876$1@news.eclipse.org" type="cite">Ed,
 
 
thanks for your comments. It still does not work, see comments
below.
 
 
Am 30.09.2011 15:42, schrieb Ed Merks:
 
<blockquote type="cite">
<blockquote type="cite">5. in genmodel set Template Directory to
 
* templates
 
* foo/templates
 
</blockquote>
I'd expect you to use "/foo/templates"
 
</blockquote>
 
If I do this, it will be extended to
 
platform:/resource/foo/templates lateron.</blockquote>
That's what I would expect. 
<blockquote cite="mid:j6enf2$876$1@news.eclipse.org" type="cite">
Still, nothing happens.
 
</blockquote>
That I wouldn't expect. 
<blockquote cite="mid:j6enf2$876$1@news.eclipse.org" type="cite">
 
<blockquote type="cite">
<blockquote type="cite">* platform:/plugin/foo/templates
 
</blockquote>
It's going to look for a bundle with ID foo (not a good bundle
ID BTW)
 
and try to find compiled templates in there. You can look at the
 
handleing in this case.
 
 
else if (templateURI.isPlatformPlugin())
 
{
 
This will be useful if you actually deploy your extension into
the IDE
 
for others to reuse (but you've not gotten that far).
 
</blockquote>
 
Looking into the code of JETEmitter line 506ff., it seems to be
vice versa:
 
 
* If the URI is a platform Resource (either /foo/templates or
platform:/resource/foo/templates), it expects the JET nature and
only looks for precompiled templates (return silently if there is
no JET nature as it is in my case).
 
</blockquote>
Yes, you want it to continue through to where it called
jetCompiler.generate later on. 
<blockquote cite="mid:j6enf2$876$1@news.eclipse.org" type="cite">
 
* If the URI is a platform Plugin
(platform:/plugin/foo/templates) it looks for the corresponding
bundle in the current platform. This is not available here. So it
fails silently.
 
</blockquote>
It's not failure, it's continuing to the point of actually
generating results from the source template. 
<blockquote cite="mid:j6enf2$876$1@news.eclipse.org" type="cite">
 
Is this a bug or do I need to use platform resource + pre-compiled
templates?
 
</blockquote>
No, this generally has been working for years... 
<blockquote cite="mid:j6enf2$876$1@news.eclipse.org" type="cite">
 
 
if (jetEmitter.templateURIPath != null)
 
{
 
 URI templateURI =
URI.createURI(jetEmitter.templateURIPath[0]);
 
 URLClassLoader theClassLoader = null;
 
 if (templateURI.isPlatformResource())
 
 {
 
 // If the template path points at a project with a JET
Nature,
 
 // then we will assume that the templates we want to use are
already compiled in this plugin Java project.
 
 IProject project
=workspace.getRoot().getProject(templateURI.segment(1));
 
 if (JETNature.getRuntime(project) != null)
 
 {
 
</blockquote>
So you are looking at things with the debugger, which is a good
thing. What we need to determine is the arguments to the
JETCompiler and why the relative template URI isn't found on the
template URI path. 
 
public JETCompiler(String[] templateURIPath, String
relativeTemplateURI, String encoding) throws JETException 
{ 
 super(); 
 
 this.templateURIPath = templateURIPath; 
 this.templateURI = relativeTemplateURI; 
 String[] actualTemplateURI = findLocation(templateURIPath, 0,
relativeTemplateURI); 
 this.reader = new JETReader(actualTemplateURI[1],
relativeTemplateURI, openStream(actualTemplateURI[0]), encoding); 
} 
 
When it's getting in here, it's just not able to open a
steam for the composition of the search path and the relative path. 
 
<blockquote> public static String[] findLocation(String[]
locationURIPath, int start, String relativeLocationURI) 
{ 
 String[] result = { null, null}; 
 for (int i = start; i < locationURIPath.length; ++i) 
 { 
 result[0] = locationURIPath[i]; 
 result[1] = locationURIPath[i]; 
 
 if (result[0] != null) 
 { 
 try 
 { 
 if (!result[0].endsWith("/")) 
 { 
 result[0] += "/"; 
 } 
 result[0] += relativeLocationURI; 
 
 InputStream inputStream = openStream(result[0]); 
 inputStream.close(); 
 break; 
 } 
 catch (JETException exception) 
 { 
 result[0] = null; 
 } 
 catch (IOException exception) 
 { 
 result[0] = null; 
 } 
 } 
 } 
 return result; 
} 
</blockquote>
 
 
 
<blockquote cite="mid:j6enf2$876$1@news.eclipse.org" type="cite">
 
Cheers,
 
Hauke
 
</blockquote>
</body>
</html>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Custom EMF JetTemplates: Uses wrong compiled template [message #733674 is a reply to message #733384]

Wed, 05 October 2011 11:46

Hauke Fuhrmann

Messages: 333
Registered: July 2009

Senior Member

Ed,

still not working, but I got further:

Am 04.10.2011 17:40, schrieb Ed Merks:
>> if (jetEmitter.templateURIPath != null)
>> {
>> URI templateURI = URI.createURI(jetEmitter.templateURIPath[0]);
>> URLClassLoader theClassLoader = null;
>> if (templateURI.isPlatformResource())
>> {
>> // If the template path points at a project with a JET Nature,
>> // then we will assume that the templates we want to use are
>> already compiled in this plugin Java project.
>> IProject project
>> =workspace.getRoot().getProject(templateURI.segment(1));
>> if (JETNature.getRuntime(project) != null)
>> {
> So you are looking at things with the debugger, which is a good thing.
> What we need to determine is the arguments to the JETCompiler and why
> the relative template URI isn't found on the template URI path.
>
> public JETCompiler(String[] templateURIPath, String
> relativeTemplateURI, String encoding) throws JETException
> {
> super();
>
> this.templateURIPath = templateURIPath;
> this.templateURI = relativeTemplateURI;
> String[] actualTemplateURI = findLocation(templateURIPath, 0,
> relativeTemplateURI);
> this.reader = new JETReader(actualTemplateURI[1],
> relativeTemplateURI, openStream(actualTemplateURI[0]), encoding);
> }
>
> When it's getting in *here*, it's just not able to open a steam for the
> composition of the search path and the relative path.
>
> public static String[] findLocation(String[] locationURIPath, int
> start, String relativeLocationURI)
> {
> String[] result = { null, null};
> for (int i = start; i < locationURIPath.length; ++i)
> {
> result[0] = locationURIPath[i];
> result[1] = locationURIPath[i];
>
> if (result[0] != null)
> {
> try
> {
> if (!result[0].endsWith("/"))
> {
> result[0] += "/";
> }
> result[0] += relativeLocationURI;
>
> *InputStream inputStream = openStream(result[0]);*
> inputStream.close();
> break;
> }
> catch (JETException exception)
> {
> result[0] = null;
> }
> catch (IOException exception)
> {
> result[0] = null;
> }
> }
> }
> return result;
> }

Using now the right resource-URI and debugging further, I can see that
creating the compiled JET-template in the .JETEmitter project actually
works. The JetReader is picking up my customized template and processes
it, I can see the customizations in the streams.

Hence it seems that compiling the template works fine (Customized
PluginProperties_.java and PluginProperties_.class is generated in the
..JETEmitter project now).

However, when loading the newly created class at JETEmitter:841 by the
URLClassloader, it seems that the old uncustomized class is loaded
instead. Unfortunately my Eclipse debugger cannot show the variables
during the loadClass steps, so I cannot really see where it fails.
Still, it seems to look in the .JETEmitter project at least.
However, at JETEmitter:869 resp. 291 where the "object" is set, it is an
instance of the uncustomized class, as I can see the unchanged TEXT
fields of the original PluginProperties_.java.
Hence the following generation steps work with this uncustomized version.

What could be wrong with loading the class?

Cheers,
Hauke

Report message to a moderator

Re: Custom EMF JetTemplates: Uses wrong compiled template [message #733729 is a reply to message #733674]

Wed, 05 October 2011 14:07

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

Hauke,

Earlier you claimed you didn't see changes in the JETEmitter project.
Now you see them? And the project is compiling properly? You could try
deleting it and confirming it's recreated...

On 05/10/2011 4:46 AM, Hauke Fuhrmann wrote:
> Ed,
>
> still not working, but I got further:
>
> Am 04.10.2011 17:40, schrieb Ed Merks:
>>> if (jetEmitter.templateURIPath != null)
>>> {
>>> URI templateURI = URI.createURI(jetEmitter.templateURIPath[0]);
>>> URLClassLoader theClassLoader = null;
>>> if (templateURI.isPlatformResource())
>>> {
>>> // If the template path points at a project with a JET Nature,
>>> // then we will assume that the templates we want to use are
>>> already compiled in this plugin Java project.
>>> IProject project
>>> =workspace.getRoot().getProject(templateURI.segment(1));
>>> if (JETNature.getRuntime(project) != null)
>>> {
>> So you are looking at things with the debugger, which is a good thing.
>> What we need to determine is the arguments to the JETCompiler and why
>> the relative template URI isn't found on the template URI path.
>>
>> public JETCompiler(String[] templateURIPath, String
>> relativeTemplateURI, String encoding) throws JETException
>> {
>> super();
>>
>> this.templateURIPath = templateURIPath;
>> this.templateURI = relativeTemplateURI;
>> String[] actualTemplateURI = findLocation(templateURIPath, 0,
>> relativeTemplateURI);
>> this.reader = new JETReader(actualTemplateURI[1],
>> relativeTemplateURI, openStream(actualTemplateURI[0]), encoding);
>> }
>>
>> When it's getting in *here*, it's just not able to open a steam for the
>> composition of the search path and the relative path.
>>
>> public static String[] findLocation(String[] locationURIPath, int
>> start, String relativeLocationURI)
>> {
>> String[] result = { null, null};
>> for (int i = start; i < locationURIPath.length; ++i)
>> {
>> result[0] = locationURIPath[i];
>> result[1] = locationURIPath[i];
>>
>> if (result[0] != null)
>> {
>> try
>> {
>> if (!result[0].endsWith("/"))
>> {
>> result[0] += "/";
>> }
>> result[0] += relativeLocationURI;
>>
>> *InputStream inputStream = openStream(result[0]);*
>> inputStream.close();
>> break;
>> }
>> catch (JETException exception)
>> {
>> result[0] = null;
>> }
>> catch (IOException exception)
>> {
>> result[0] = null;
>> }
>> }
>> }
>> return result;
>> }
>
> Using now the right resource-URI and debugging further, I can see that
> creating the compiled JET-template in the .JETEmitter project actually
> works. The JetReader is picking up my customized template and
> processes it, I can see the customizations in the streams.
>
> Hence it seems that compiling the template works fine (Customized
> PluginProperties_.java and PluginProperties_.class is generated in the
> .JETEmitter project now).
>
> However, when loading the newly created class at JETEmitter:841 by the
> URLClassloader, it seems that the old uncustomized class is loaded
> instead. Unfortunately my Eclipse debugger cannot show the variables
> during the loadClass steps, so I cannot really see where it fails.
> Still, it seems to look in the .JETEmitter project at least.
> However, at JETEmitter:869 resp. 291 where the "object" is set, it is
> an instance of the uncustomized class, as I can see the unchanged TEXT
> fields of the original PluginProperties_.java.
> Hence the following generation steps work with this uncustomized version.
>
> What could be wrong with loading the class?
>
> Cheers,
> Hauke

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Custom EMF JetTemplates: Uses wrong compiled template [message #733992 is a reply to message #733729]

Thu, 06 October 2011 08:53

Hauke Fuhrmann

Messages: 333
Registered: July 2009

Senior Member

Ed,

The silently different handling of plugin-URL vs. resource-URL seemed to
trick me. I think I first debugged it when using a plugin-URL.
Now, debugging with the resource-URL, codegen into the JETEmitters
works, but in the target edit-Project the target plugin.properties is
still the original one, even if I delete it before generation. Debugging
shows the problem as explained below: after generating and compiling the
PluginProperties_.class in the .JETEmitter project, it seems that the
original class is loaded by the classloader and not the new one.

Sorry for the confusion,
Hauke

Am 05.10.2011 16:07, schrieb Ed Merks:
> Hauke,
>
> Earlier you claimed you didn't see changes in the JETEmitter project.
> Now you see them? And the project is compiling properly? You could try
> deleting it and confirming it's recreated...
>
>
> On 05/10/2011 4:46 AM, Hauke Fuhrmann wrote:
>> Ed,
>>
>> still not working, but I got further:
>>
>> Am 04.10.2011 17:40, schrieb Ed Merks:
>>>> if (jetEmitter.templateURIPath != null)
>>>> {
>>>> URI templateURI = URI.createURI(jetEmitter.templateURIPath[0]);
>>>> URLClassLoader theClassLoader = null;
>>>> if (templateURI.isPlatformResource())
>>>> {
>>>> // If the template path points at a project with a JET Nature,
>>>> // then we will assume that the templates we want to use are
>>>> already compiled in this plugin Java project.
>>>> IProject project
>>>> =workspace.getRoot().getProject(templateURI.segment(1));
>>>> if (JETNature.getRuntime(project) != null)
>>>> {
>>> So you are looking at things with the debugger, which is a good thing.
>>> What we need to determine is the arguments to the JETCompiler and why
>>> the relative template URI isn't found on the template URI path.
>>>
>>> public JETCompiler(String[] templateURIPath, String
>>> relativeTemplateURI, String encoding) throws JETException
>>> {
>>> super();
>>>
>>> this.templateURIPath = templateURIPath;
>>> this.templateURI = relativeTemplateURI;
>>> String[] actualTemplateURI = findLocation(templateURIPath, 0,
>>> relativeTemplateURI);
>>> this.reader = new JETReader(actualTemplateURI[1],
>>> relativeTemplateURI, openStream(actualTemplateURI[0]), encoding);
>>> }
>>>
>>> When it's getting in *here*, it's just not able to open a steam for the
>>> composition of the search path and the relative path.
>>>
>>> public static String[] findLocation(String[] locationURIPath, int
>>> start, String relativeLocationURI)
>>> {
>>> String[] result = { null, null};
>>> for (int i = start; i < locationURIPath.length; ++i)
>>> {
>>> result[0] = locationURIPath[i];
>>> result[1] = locationURIPath[i];
>>>
>>> if (result[0] != null)
>>> {
>>> try
>>> {
>>> if (!result[0].endsWith("/"))
>>> {
>>> result[0] += "/";
>>> }
>>> result[0] += relativeLocationURI;
>>>
>>> *InputStream inputStream = openStream(result[0]);*
>>> inputStream.close();
>>> break;
>>> }
>>> catch (JETException exception)
>>> {
>>> result[0] = null;
>>> }
>>> catch (IOException exception)
>>> {
>>> result[0] = null;
>>> }
>>> }
>>> }
>>> return result;
>>> }
>>
>> Using now the right resource-URI and debugging further, I can see that
>> creating the compiled JET-template in the .JETEmitter project actually
>> works. The JetReader is picking up my customized template and
>> processes it, I can see the customizations in the streams.
>>
>> Hence it seems that compiling the template works fine (Customized
>> PluginProperties_.java and PluginProperties_.class is generated in the
>> .JETEmitter project now).
>>
>> However, when loading the newly created class at JETEmitter:841 by the
>> URLClassloader, it seems that the old uncustomized class is loaded
>> instead. Unfortunately my Eclipse debugger cannot show the variables
>> during the loadClass steps, so I cannot really see where it fails.
>> Still, it seems to look in the .JETEmitter project at least.
>> However, at JETEmitter:869 resp. 291 where the "object" is set, it is
>> an instance of the uncustomized class, as I can see the unchanged TEXT
>> fields of the original PluginProperties_.java.
>> Hence the following generation steps work with this uncustomized version.
>>
>> What could be wrong with loading the class?
>>
>> Cheers,
>> Hauke

Report message to a moderator

Previous Topic:	[CDO] CDORevision and timestamp
Next Topic:	expanding subtree in emf editor

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 26 15:44:06 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter