Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Extending EMF Code Generator
Extending EMF Code Generator [message #647243] Wed, 05 January 2011 10:27 Go to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
Messages: 42
Registered: July 2009
Member
Hello,

in this message Ed gives the comment to use Dynamic Templates (DT) to change the existing templates and to create a plugin and write a Generator Adapter to add new files to the generation. The new one can be overwritten again by the DT.

Well I started in my EMF Addon project to write some DT for generation of a bit more structured EMF editor.
At one point now I have to add a new file, so i wrote a plugin for it based on org.eclipse.emf.examples.generator.validator.

Now the question now is how can I overwrite existing templates in the plugin, the sample shows only adding new one.

In the other case it is always both required the plugin and the configuration in the genmodel to use the DT templates.
To simplify this i like to merge all in the plugin and e.g. enabled it by an annotation in the genmodel.

Greetings

Stephan

[Updated on: Wed, 05 January 2011 10:29]

Report message to a moderator

Re: Extending EMF Code Generator [message #647340 is a reply to message #647243] Wed, 05 January 2011 17:04 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26278
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010409070401000507060309
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Stephan,

Notice that the class loader of your derived generator adapter is used
to find the compiled (static) template, so if you have compiled
templates with the same qualified names as provided by EMF's generator
they'll "override" the ones from the base.

protected JETEmitter createJETEmitter(JETEmitterDescriptor
jetEmitterDescriptor)
{
JETEmitter jetEmitter = new JETEmitter(getTemplatePath(),
jetEmitterDescriptor.templatePathName, getClass().getClassLoader());

try
{
setStaticTemplateClass(jetEmitter,
jetEmitterDescriptor.className);


Stephan Zehrer wrote:
> Hello,
>
> in
> http://www.eclipse.org/forums/index.php?t=msg&S=26948a75 00a8f8b49cfde1a577ad810c&th=155261&goto=489160
> Ed gives the comment to use Dynamic Templates (DT) to change the
> existing templates and to create a plugin and write a Generator
> Adapter to add new files to the generation. The new one can be
> overwritten again by the DT.
>
> Well I started in my http://code.google.com/a/eclipselabs.org/p/emf/
> to write some DT for generation of a bit more structured EMF editor.
> At one point now I have to add a new file, so i wrote a plugin for it
> based on org.eclipse.emf.examples.generator.validator.
>
> Now the question now is how can I overwrite existing templates in the
> plugin, the sample shows only adding new one.
> In the other case it is always both required the plugin the
> configuration in the genmodel to use the DT templates.
> To simplify this i like to merge all in the plugin and e.g. enabled it
> by an annotation in the genmodel.
>
> Greetings
>
> Stephan

--------------010409070401000507060309
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Stephan,<br>
<br>
Notice that the class loader of your derived generator adapter is used
to find the compiled (static) template, so if you have compiled
templates with the same qualified names as provided by EMF's generator
they'll "override" the ones from the base.<small><br>
</small>
<blockquote><small>  protected JETEmitter
createJETEmitter(JETEmitterDescriptor jetEmitterDescriptor)</small><br>
<small>  {</small><br>
<small>    JETEmitter jetEmitter = new JETEmitter(getTemplatePath(),
jetEmitterDescriptor.templatePathName, getClass().getClassLoader());</small><br>
<br>
<small>    try</small><br>
<small>    {</small><br>
<small>      setStaticTemplateClass(jetEmitter,
jetEmitterDescriptor.className);</small><br>
</blockquote>
<br>
Stephan Zehrer wrote:
<blockquote cite="mid:ig1gph$u8b$1@news.eclipse.org" type="cite">Hello,
<br>
<br>
in
<a class="moz-txt-link-freetext" href=" http://www.eclipse.org/forums/index.php?t=msg&S=26948a75 00a8f8b49cfde1a577ad810c&th=155261&goto=489160">http://www.eclipse.org/forums/index.php?t=msg&amp ;S=26948a7500a8f8b49cfde1a577ad810c&amp;th=155261&am p;goto=489160 </a>
Ed gives the comment to use Dynamic Templates (DT) to change the
existing templates and to create a plugin and write a Generator Adapter
to add new files to the generation. The new one can be overwritten
again by the DT.
<br>
<br>
Well I started in my <a class="moz-txt-link-freetext" href="http://code.google.com/a/eclipselabs.org/p/emf/">http://code.google.com/a/eclipselabs.org/p/emf/</a> to
write some DT for generation of a bit more structured EMF editor. At
one point now I have to add a new file, so i wrote a plugin for it
based on org.eclipse.emf.examples.generator.validator.
<br>
<br>
Now the question now is how can I overwrite existing templates in the
plugin, the sample shows only adding new one.  <br>
In the other case it is always both required the plugin the
configuration in the genmodel to use the DT templates.
<br>
To simplify this i like to merge all in the plugin and e.g. enabled it
by an annotation in the genmodel.
<br>
<br>
Greetings
<br>
<br>
Stephan
<br>
</blockquote>
</body>
</html>

--------------010409070401000507060309--
Re: Extending EMF Code Generator [message #647709 is a reply to message #647340] Fri, 07 January 2011 23:19 Go to previous messageGo to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
Messages: 42
Registered: July 2009
Member
Hi Ed,

thx for your response ...

Ed Merks wrote on Wed, 05 January 2011 12:04


Notice that the class loader of your derived generator adapter is used
to find the compiled (static) template, so if you have compiled
templates with the same qualified names as provided by EMF's generator
they'll "override" the ones from the base.

protected JETEmitter createJETEmitter(JETEmitterDescriptor
jetEmitterDescriptor)
{
JETEmitter jetEmitter = new JETEmitter(getTemplatePath(),
jetEmitterDescriptor.templatePathName, getClass().getClassLoader());

try
{
setStaticTemplateClass(jetEmitter,
jetEmitterDescriptor.className);




This sounds for me I just put the compiled temples into the plugin and it should work? ... Well tested and I does (in my case) not Smile
After that I added an generateJava call in my GenerationAdapter ... did not work either ..

Now which of both is correct or is there a third option I just not see?

Btw ... why are the NL public in your compiled temples ... is there a special setting in JET?

Greetings from Germany

Stephan
Re: Extending EMF Code Generator [message #647712 is a reply to message #647709] Fri, 07 January 2011 23:46 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26278
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010401080606050307030809
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Stephan,

Comments below.


Stephan Zehrer wrote:
> Hi Ed,
>
> thx for your response ...
> Ed Merks wrote on Wed, 05 January 2011 12:04
>> Notice that the class loader of your derived generator adapter is
>> used to find the compiled (static) template, so if you have compiled
>> templates with the same qualified names as provided by EMF's
>> generator they'll "override" the ones from the base.
>>
>> protected JETEmitter createJETEmitter(JETEmitterDescriptor
>> jetEmitterDescriptor)
>> {
>> JETEmitter jetEmitter = new JETEmitter(getTemplatePath(),
>> jetEmitterDescriptor.templatePathName, getClass().getClassLoader());
>>
>> try
>> {
>> setStaticTemplateClass(jetEmitter,
>> jetEmitterDescriptor.className);
>
>
> This sounds for me I just put the compiled temples into the plugin and
> it should work? ... Well tested and I does (in my case) not :)
All I can suggest is looking at determining why the class loader for
your derived generator adapter (hmmm, you do have one?) doesn't find
your versions of the classes. when setStaticTemplateClass is called.

protected JETEmitter createJETEmitter(JETEmitterDescriptor
jetEmitterDescriptor)
{
JETEmitter jetEmitter = new JETEmitter(getTemplatePath(),
jetEmitterDescriptor.templatePathName, getClass().getClassLoader());

try
{
setStaticTemplateClass(jetEmitter,
jetEmitterDescriptor.className);


> After that I added an generateJava call in my GenerationAdapter ...
> did not work either ..
> Now which of both is correct or is there a third option I just not see?
Look into what's happening when the template class is set...
>
> Btw ... why are the NL public in your compiled temples ... is there a
> special setting in JET?
Look at JETEmitter.getObject; it's important that the template can be
specialized to generate the right type of line feeds depending on
preferences.
>
> Greetings from Germany
> Stephan

--------------010401080606050307030809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stephan,<br>
<br>
Comments below.<br>
<br>
<br>
Stephan Zehrer wrote:
<blockquote cite="mid:ig86ob$2gh$1@news.eclipse.org" type="cite">Hi Ed,
<br>
<br>
thx for your response ... <br>
Ed Merks wrote on Wed, 05 January 2011 12:04
<br>
<blockquote type="cite">Notice that the class loader of your derived
generator adapter is used to find the compiled (static) template, so if
you have compiled templates with the same qualified names as provided
by EMF's generator they'll "override" the ones from the base.
<br>
<br>
      protected JETEmitter createJETEmitter(JETEmitterDescriptor
<br>
    jetEmitterDescriptor)
<br>
      {
<br>
        JETEmitter jetEmitter = new JETEmitter(getTemplatePath(),
<br>
    jetEmitterDescriptor.templatePathName,
getClass().getClassLoader());
<br>
<br>
        try
<br>
        {
<br>
          setStaticTemplateClass(jetEmitter,
<br>
    jetEmitterDescriptor.className);
<br>
</blockquote>
<br>
<br>
This sounds for me I just put the compiled temples into the plugin and
it should work? ... Well tested and I does (in my case) not :)
<br>
</blockquote>
All I can suggest is looking at determining why the class loader for
your derived generator adapter (hmmm, you do have one?) doesn't find
your versions of the classes. when setStaticTemplateClass is called.<br>
<blockquote><small>  protected JETEmitter
createJETEmitter(JETEmitterDescriptor jetEmitterDescriptor)</small><br>
<small>  {</small><br>
<small>    JETEmitter jetEmitter = new JETEmitter(getTemplatePath(),
jetEmitterDescriptor.templatePathName, getClass().getClassLoader());</small><br>
<br>
<small>    try</small><br>
<small>    {</small><br>
<small>      setStaticTemplateClass(jetEmitter,
jetEmitterDescriptor.className);</small><br>
</blockquote>
<br>
<blockquote cite="mid:ig86ob$2gh$1@news.eclipse.org" type="cite">After
that I added an generateJava call in my GenerationAdapter ... did not
work either ..   <br>
Now which of both is correct or is there a third option I just not see?
<br>
</blockquote>
Look into what's happening when the template class is set...<br>
<blockquote cite="mid:ig86ob$2gh$1@news.eclipse.org" type="cite"><br>
Btw ... why are the NL public in your compiled temples ... is there a
special setting in JET?
<br>
</blockquote>
Look at JETEmitter.getObject; it's important that the template can be
specialized to generate the right type of line feeds depending on
preferences.<br>
<blockquote cite="mid:ig86ob$2gh$1@news.eclipse.org" type="cite"><br>
Greetings from Germany <br>
Stephan
<br>
</blockquote>
</body>
</html>

--------------010401080606050307030809--
Re: Extending EMF Code Generator [message #647741 is a reply to message #647712] Sat, 08 January 2011 14:03 Go to previous messageGo to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
Messages: 42
Registered: July 2009
Member
Ed Merks wrote on Fri, 07 January 2011 18:46

All I can suggest is looking at determining why the class loader for
your derived generator adapter (hmmm, you do have one?) doesn't find
your versions of the classes. when setStaticTemplateClass is called.



Yes I have one, but I think I need an example to explain what I want.
I have an new template ResourceManager which is generated in my GenAdapter. (without a AdapterFactory)
Now i have adapted the Editor.javajet template to use the ResourceManager.

Just adding the editor template class to my plugin didn't work. It is still the
GenPackageGeneratorAdapter of the ecore.codegen plugin which generate the editor
and I see at the moment no way how this plugin should find my class. (correct??)
So i expect i have to do more. (e.g. registration? )

>> Now which of both is correct or is there a third option I just not see?
>Look into what's happening when the template class is set...
You mean in the generateEditor method?
But at this time the editor is already generated.
Where/When is it set?
The JETEmitterDescriptors is provided only in the generateJava call as far as I see.


>> Btw ... why are the NL public in your compiled temples ... is there a
>> special setting in JET?
>Look at JETEmitter.getObject; it's important that the template can be
>specialized to generate the right type of line feeds depending on
>preferences.
Ok I'll take take a look

thanks

Stephan


Re: Extending EMF Code Generator [message #647761 is a reply to message #647741] Sat, 08 January 2011 17:08 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26278
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070703050004010001020707
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Stephan,

Comments below.

Stephan Zehrer wrote:
> Ed Merks wrote on Fri, 07 January 2011 18:46
>> All I can suggest is looking at determining why the class loader for
>> your derived generator adapter (hmmm, you do have one?) doesn't find
>> your versions of the classes. when setStaticTemplateClass is called.
>
>
> Yes I have one, but I think I need an example to explain what I want.
> I have an new template ResourceManager which is generated in my
> GenAdapter. (without a AdapterFactory)
> Now i have adapted the Editor.javajet template to use the
> ResourceManager.
>
> Just adding the editor template class to my plugin didn't work. It is
> still the GenPackageGeneratorAdapter of the ecore.codegen plugin which
> generate the editor and I see at the moment no way how this plugin
> should find my class. (correct??)
> So i expect i have to do more. (e.g. registration? )
I see. UML2 does this, but it has its own extended GenModel and
therefore has specialized adapters that kick in.
>
>>> Now which of both is correct or is there a third option I just not see?
>> Look into what's happening when the template class is set...
> You mean in the generateEditor method?
No, I keep pointing you to the specific class in which to set breakpoints.
> But at this time the editor is already generated.
> Where/When is it set?
> The JETEmitterDescriptors is provided only in the generateJava call
> as far as I see.
I have a feeling you're not taking much advantage of the debugger.
You'll understand the behavior of a framework much better if you set a
breakpoint and then look at all the calls that lead up to a specific
point in the code. That's what I've been prompting you to do. It's
much better to look at code in a running dynamic process then to do
endless static analysis.
>
>
>>> Btw ... why are the NL public in your compiled temples ... is there
>>> a special setting in JET?
>> Look at JETEmitter.getObject; it's important that the template can be
>> specialized to generate the right type of line feeds depending on
>> preferences.
> Ok I'll take take a look
Another technique that should work well in your type of situation is to
use a platform:/plugin/<your-bundle>/templates in the GenModel's
Template Path. That should make this code kick in to create a class
loader that loads classes, i.e., the compiled templates, from your bundle.

else if (templateURI.isPlatformPlugin())
{
final Bundle bundle =
Platform.getBundle(templateURI.segment(1));
if (bundle != null)
{
// Define a class loader that will look up the class
in the bundle,
// and if it doesn't find it there, will look in the
parent.
//
theClassLoader =
new URLClassLoader(new URL [0], jetEmitter.classLoader)
{
@Override
public Class<?> loadClass(String className) throws
ClassNotFoundException
{
try
{
return bundle.loadClass(className);
}
catch (ClassNotFoundException
classNotFoundException)
{
return super.loadClass(className);
}
}
};
}
}


>
> thanks
>
> Stephan
>
>
>

--------------070703050004010001020707
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stephan,<br>
<br>
Comments below.<br>
<br>
Stephan Zehrer wrote:
<blockquote cite="mid:ig9qh8$amu$1@news.eclipse.org" type="cite">Ed
Merks wrote on Fri, 07 January 2011 18:46
<br>
<blockquote type="cite">All I can suggest is looking at determining
why the class loader for your derived generator adapter (hmmm, you do
have one?) doesn't find your versions of the classes. when
setStaticTemplateClass is called.
<br>
</blockquote>
<br>
<br>
Yes I have one, but I think I need an example to explain what I want.
<br>
I have an new template ResourceManager which is generated in my
GenAdapter. (without a AdapterFactory)
<br>
Now i have adapted the Editor.javajet template to use the
ResourceManager.
<br>
<br>
Just adding the editor template class to my plugin didn't work. It is
still the GenPackageGeneratorAdapter of the ecore.codegen plugin which
generate the editor and I see at the moment no way how this plugin
should find my class. (correct??)
<br>
So i expect i have to do more. (e.g. registration? )
<br>
</blockquote>
I see.  UML2 does this, but it has its own extended GenModel and
therefore has specialized adapters that kick in.  <br>
<blockquote cite="mid:ig9qh8$amu$1@news.eclipse.org" type="cite"><br>
<blockquote type="cite">
<blockquote type="cite">Now which of both is correct or is there a
third option I just not see?
<br>
</blockquote>
Look into what's happening when the template class is set...
<br>
</blockquote>
You mean in the generateEditor method?</blockquote>
No, I keep pointing you to the specific class in which to set
breakpoints.<br>
<blockquote cite="mid:ig9qh8$amu$1@news.eclipse.org" type="cite"> But
at this time the editor is already generated.
<br>
Where/When is it set?
<br>
The JETEmitterDescriptors is provided only in the  generateJava call as
far as I see.
<br>
</blockquote>
I have a feeling you're not taking much advantage of the debugger. 
You'll understand the behavior of a framework much better if you set a
breakpoint and then look at all the calls that lead up to a specific
point in the code.  That's what I've been prompting you to do.  It's
much better to look at code in a running dynamic process then to do
endless static analysis.<br>
<blockquote cite="mid:ig9qh8$amu$1@news.eclipse.org" type="cite"><br>
<br>
<blockquote type="cite">
<blockquote type="cite">Btw ... why are the NL public in your
compiled temples ... is there a special setting in JET?
<br>
</blockquote>
Look at JETEmitter.getObject; it's important that the template can be
specialized to generate the right type of line feeds depending on
preferences.
<br>
</blockquote>
Ok I'll take take a look
<br>
</blockquote>
Another technique that should work well in your type of situation is to
use a platform:/plugin/&lt;your-bundle&gt;/templates in the GenModel's
Template Path.  That should make this code kick in to create a class
loader that loads classes, i.e., the compiled templates, from your
bundle.<br>
<small><br>
</small>
<blockquote><small>          else if (templateURI.isPlatformPlugin())</small><br>
<small>          {</small><br>
<small>            final Bundle bundle =
Platform.getBundle(templateURI.segment(1));</small><br>
<small>            if (bundle != null)</small><br>
<small>            {</small><br>
<small>              // Define a class loader that will look up the
class in the bundle,</small><br>
<small>              // and if it doesn't find it there, will look in
the parent.</small><br>
<small>              //</small><br>
<small>              theClassLoader = </small><br>
<small>                new URLClassLoader(new URL [0],
jetEmitter.classLoader)</small><br>
<small>                {</small><br>
<small>                  @Override</small><br>
<small>                  public Class&lt;?&gt; loadClass(String
className) throws ClassNotFoundException</small><br>
<small>                  {</small><br>
<small>                    try</small><br>
<small>                    {</small><br>
<small>                      return bundle.loadClass(className);</small><br>
<small>                    }</small><br>
<small>                    catch (ClassNotFoundException
classNotFoundException)</small><br>
<small>                    {</small><br>
<small>                      return super.loadClass(className);</small><br>
<small>                    }</small><br>
<small>                  }</small><br>
<small>                };</small><br>
<small>            }</small><br>
<small>          }</small><br>
</blockquote>
<br>
<blockquote cite="mid:ig9qh8$amu$1@news.eclipse.org" type="cite"><br>
thanks
<br>
<br>
Stephan
<br>
<br>
<br>
<br>
</blockquote>
</body>
</html>

--------------070703050004010001020707--
Re: Extending EMF Code Generator [message #647773 is a reply to message #647761] Sat, 08 January 2011 20:24 Go to previous messageGo to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
Messages: 42
Registered: July 2009
Member
Hi Ed,


[quote title=Ed Merks wrote on Sat, 08 January 2011 12:08c
> Just adding the editor template class to my plugin didn't work. It is
> still the GenPackageGeneratorAdapter of the ecore.codegen plugin which
> generate the editor and I see at the moment no way how this plugin
> should find my class. (correct??)
> So i expect i have to do more. (e.g. registration? )
I see. UML2 does this, but it has its own extended GenModel and
therefore has specialized adapters that kick in.
[/quote]
I guess this is a yes ...

Quote:

>> Look into what's happening when the template class is set...
> You mean in the generateEditor method?
No, I keep pointing you to the specific class in which to set breakpoints.


Well I did ... already on your last mail.
I put it on "setStaticTemplateClass"
And it get called for each template which is generated. (e.g. staring with ....templates.editor.Plugin if you generate the Editor".

In the line "Class<?> templateClass = getClass().getClassLoader().loadClass(className);" the classloader of getClass is used.
But getClass return, in the case of the Edior.javajet template (which i like replace), the class .... genmodel.generator.GenPackageGeneratorAdapter of the ecore plugin. That is the first time where the editor is generated.
So I see no change that in the first step he will ever find my template class because the plugin is always using the class loader of the generator adapter.

The second time it is called in my generator adapter now but it seems, even it uses the classloader of my gen adapter, it loads the wrong class.
I guess because the class is already loaded from the first time?

I will try it now with an other template name.
But the behavior of the first generation i can not change, or is there a mistake in my conclusion?

Quote:

> But at this time the editor is already generated.
> Where/When is it set?
> The JETEmitterDescriptors is provided only in the generateJava call
> as far as I see.
I have a feeling you're not taking much advantage of the debugger.
You'll understand the behavior of a framework much better if you set a
breakpoint and then look at all the calls that lead up to a specific
point in the code. That's what I've been prompting you to do. It's
much better to look at code in a running dynamic process then to do
endless static analysis.


Well I did ... hope your feeling changed now Smile

Quote:

Another technique that should work well in your type of situation is to
use a platform:/plugin/<your-bundle>/templates in the GenModel's
Template Path. That should make this code kick in to create a class
loader that loads classes, i.e., the compiled templates, from your bundle.

else if (templateURI.isPlatformPlugin())
{
final Bundle bundle =
Platform.getBundle(templateURI.segment(1));
if (bundle != null)
{
// Define a class loader that will look up the class
in the bundle,
// and if it doesn't find it there, will look in the
parent.
//
theClassLoader =
new URLClassLoader(new URL [0], jetEmitter.classLoader)
{
@Override
public Class<?> loadClass(String className) throws
ClassNotFoundException
{
try
{
return bundle.loadClass(className);
}
catch (ClassNotFoundException
classNotFoundException
{
return super.loadClass(className);
}
}
};
}
}


Ok that's maybe a solution, i can use it even as general switch for all generation task in the plugin.
The disadvantage of this, i can not use dynamicTemplates any more for development.
It is very time consuming always redeploy the plugin for testing. Mmm i have to think about this Smile

Thanks..

Stephan

[Updated on: Sat, 08 January 2011 20:25]

Report message to a moderator

Re: Extending EMF Code Generator [message #647778 is a reply to message #647773] Sat, 08 January 2011 21:41 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 26278
Registered: July 2009
Senior Member
Stephan,

You could switch from platform:/plugin to platform:/resource while
developing. Note that even with platform:/resource, if your project has
a JETNature and hence has compiled templates that the JETEmitter should
end up using those compiled versions...


Stephan Zehrer wrote:
> Hi Ed,
>
>
> [quote title=Ed Merks wrote on Sat, 08 January 2011 12:08c
>> Just adding the editor template class to my plugin didn't work. It is
>> still the GenPackageGeneratorAdapter of the ecore.codegen plugin
>> which generate the editor and I see at the moment no way how this
>> plugin should find my class. (correct??)
>> So i expect i have to do more. (e.g. registration? )
> I see. UML2 does this, but it has its own extended GenModel and
> therefore has specialized adapters that kick in. [/quote]
> I guess this is a yes ...
>
> Quote:
>> >> Look into what's happening when the template class is set...
>> > You mean in the generateEditor method?
>> No, I keep pointing you to the specific class in which to set
>> breakpoints.
>
> Well I did ... already on your last mail. I put it on
> "setStaticTemplateClass"
> And it get called for each template which is generated. (e.g. staring
> with ....templates.editor.Plugin if you generate the Editor".
>
> In the line "Class<?> templateClass =
> getClass().getClassLoader().loadClass(className);" the classloader of
> getClass is used.
> But getClass return, in the case of the Edior.javajet template (which
> i like replace), the class ....
> genmodel.generator.GenPackageGeneratorAdapter of the ecore plugin.
> That is the first time where the editor is generated.
> So I see no change that in the first step he will ever find my
> template class because the plugin is always using the class loader of
> the generator adapter.
>
> The second time it is called in my generator adapter now but it seems,
> even it uses the classloader of my gen adapter, it loads the wrong class.
>
> I will try it now with an other template name. But the behavior of the
> first generation i can not change, or is there a mistake in my
> conclusion?
> Quote:
>> > But at this time the editor is already generated.
>> > Where/When is it set?
>> > The JETEmitterDescriptors is provided only in the generateJava
>> call > as far as I see.
>> I have a feeling you're not taking much advantage of the debugger.
>> You'll understand the behavior of a framework much better if you set
>> a breakpoint and then look at all the calls that lead up to a
>> specific point in the code. That's what I've been prompting you to
>> do. It's much better to look at code in a running dynamic process
>> then to do endless static analysis.
>
> Well I did ... hope your feeling changed now :)
>
> Quote:
>> Another technique that should work well in your type of situation is
>> to use a platform:/plugin/<your-bundle>/templates in the GenModel's
>> Template Path. That should make this code kick in to create a class
>> loader that loads classes, i.e., the compiled templates, from your
>> bundle.
>>
>> else if (templateURI.isPlatformPlugin())
>> {
>> final Bundle bundle =
>> Platform.getBundle(templateURI.segment(1));
>> if (bundle != null)
>> {
>> // Define a class loader that will look up the class
>> in the bundle,
>> // and if it doesn't find it there, will look in the
>> parent.
>> //
>> theClassLoader =
>> new URLClassLoader(new URL [0],
>> jetEmitter.classLoader)
>> {
>> @Override
>> public Class<?> loadClass(String className) throws
>> ClassNotFoundException
>> {
>> try
>> {
>> return bundle.loadClass(className);
>> }
>> catch (ClassNotFoundException
>> classNotFoundException
>> {
>> return super.loadClass(className);
>> }
>> }
>> };
>> }
>> }
>
> Ok that's maybe a solution, i can use it even as general switch for
> all generation task in the plugin.
> The disadvantage of this, i can not use dynamicTemplates any more for
> development. It is very time consuming always redeploy the plugin for
> testing. Mmm i have to think about this :)
>
> Thanks..
>
> Stephan
Re: Extending EMF Code Generator [message #647840 is a reply to message #647778] Sun, 09 January 2011 21:14 Go to previous messageGo to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
Messages: 42
Registered: July 2009
Member
Ed,
Thanks !!


Ed Merks wrote on Sat, 08 January 2011 16:41

You could switch from platform:/plugin to platform:/resource while
developing. Note that even with platform:/resource, if your project has
a JETNature and hence has compiled templates that the JETEmitter should
end up using those compiled versions...



I debugged now some hours to understand what JETEmitter is doing and why it does not work in my configuration.
But at the end I can say the solution with adding platform:/plugin/<plugin-id>/templates works!

I am not sure it is a bug, but it was very helpful to removed the .JETEmitter project from the workspace.
In an clean environment where no compiled version's of old JET Templates and Template classes exist somewhere It do what it should.

Btw. the NL field is not public if you use the M2T Jet project configuration in JET1 mode, i opened a bug for this.

I collected some "hint" related to this topic on this page http://wiki.eclipse.org/EMF/ExtendingCodeGeneration
I hope this will help other people if they have similar problems.

Greetings

Stephan
Re: Extending EMF Code Generator [message #647857 is a reply to message #647778] Mon, 10 January 2011 07:40 Go to previous messageGo to next message
Stephan Zehrer is currently offline Stephan ZehrerFriend
Messages: 42
Registered: July 2009
Member
-

[Updated on: Mon, 10 January 2011 07:42]

Report message to a moderator

Re: Extending EMF Code Generator [message #647957 is a reply to message #647857] Mon, 10 January 2011 15:26 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 26278
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------080701060707000208060801
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Stephan,

Thanks for sharing your experience in the wiki!! Likely more folks
would find it from the EMF Recipes page:

http://wiki.eclipse.org/EMF/Recipes


Stephan Zehrer wrote:
> Ed,
>
> Thanks !!
>
> Ed Merks wrote on Sat, 08 January 2011 16:41
>> You could switch from platform:/plugin to platform:/resource while
>> developing. Note that even with platform:/resource, if your project
>> has a JETNature and hence has compiled templates that the JETEmitter
>> should end up using those compiled versions...
>
>
>
> After a hour debugging I understand now more or less what the
> JETEmitter is doing :)
> And I can confirm that the platform:/plugin method works. My problems
> were solved after the removing of the .JETEmitter project from my test
> environment workspace, without it always found old version's of the
> classes (maybe a bug? .... if so it will happen again I will open one)
>
> Nevertheless it works now !
>
> Btw. the NL problem was produced if you use M2T JET project in JET1
> mode :) and not the EMF version.
>
> I put some may experiences on the following wiki page
> http://wiki.eclipse.org/EMF/ExtendingCodeGeneration
>
> Greetings
>
> Stephan
>

--------------080701060707000208060801
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stephan,<br>
<br>
Thanks for sharing your experience in the wiki!!  Likely more folks
would find it from the EMF Recipes page:<br>
<blockquote><a href="http://wiki.eclipse.org/EMF/Recipes">http://wiki.eclipse.org/EMF/Recipes</a><br>
</blockquote>
<br>
Stephan Zehrer wrote:
<blockquote cite="mid:igecs2$s3b$1@news.eclipse.org" type="cite">Ed,
<br>
<br>
Thanks !!
<br>
<br>
Ed Merks wrote on Sat, 08 January 2011 16:41
<br>
<blockquote type="cite">You could switch from platform:/plugin to
platform:/resource while developing.  Note that even with
platform:/resource, if your project has a JETNature and hence has
compiled templates that the JETEmitter should end up using those
compiled versions...
<br>
</blockquote>
<br>
<br>
<br>
After a hour debugging I understand now more or less what the
JETEmitter is doing :)
<br>
And I can confirm that the platform:/plugin method works. My problems
were solved after the removing of the .JETEmitter project from my test
environment workspace, without it always found old version's of the
classes (maybe a bug? .... if so it will happen again I will open one)
<br>
<br>
Nevertheless it works now !
<br>
<br>
Btw. the NL problem was produced if you use M2T JET  project in JET1
mode :) and not the EMF version.
<br>
<br>
I put some may experiences on the following wiki page
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/EMF/ExtendingCodeGeneration">http://wiki.eclipse.org/EMF/ExtendingCodeGeneration</a>
<br>
<br>
Greetings
<br>
<br>
Stephan <br>
<br>
</blockquote>
</body>
</html>

--------------080701060707000208060801--
Previous Topic:Source for EMF Common (2.6.0.v20100914-1218)
Next Topic:[CDO] How to configure cdo-server.xml to use H2
Goto Forum:
  


Current Time: Thu Dec 18 02:29:10 GMT 2014

Powered by FUDForum. Page generated in 0.02495 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software