Home » Modeling » EMF » Exception when regenerating code in standalone mode
| Exception when regenerating code in standalone mode [message #416278] |
Thu, 24 January 2008 17:29  |
 Conrad Hoffmann
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Hi all.
I am doing code generation from models in a standalone app. The project I
work on is currently being transitioned from Eclipse 3.2 to Eclipse 3.3.
My code (which is basically straight from the docs) worked flawlessly in
3.2. Unfortunately, not exactly so in 3.3:
When generating code for the first time, it still works fine. But when
regenerating, the following exception occurs:
java.lang.IllegalStateException: Workspace is closed.
at
org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
at
org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
at org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
at
org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
at
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
at
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
at
org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
at
org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
So the merging with the already present code seems to require the
workspace?
This did work in 3.2, anybody know how to make it work in 3.3?
I wouldn't care if the already present code would be totally disregarded...
For completeness, code is below (like I said, straight from the docs):
// Globally register the default generator adapter factory for
GenModel
// elements (only needed in stand-alone).
//
GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
(GenModelPackage.eNS_URI,
GenModelGeneratorAdapterFactory.DESCRIPTOR);
Generator gen = new Generator();
gen.setInput(genModel);
gen.generate(
genModel,
GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
new BasicMonitor.Printing(System.out));
|
|
|
| Re: Exception when regenerating code in standalone mode [message #416281 is a reply to message #416278] |
Thu, 24 January 2008 17:46  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060502010804020602040204
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Conrad,
That sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807
but this was fixed in 3.4 not in 3.3.
One of the Generator.Options is
/**
* The name of the {@link
org.eclipse.emf.codegen.merge.java.facade.FacadeHelper facade
helper} class to be used in
* Java merging.
* @see org.eclipse.emf.codegen.merge.java.facade.FacadeHelper
*/
public String mergerFacadeHelperClass;
You could use that to specify
org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per which
was the default in 3.2 but now the AST facade is the default.
So probably gen.getOptions().mergerFacadeHelperClass =
" org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per " will
make it work as before.
Conrad Hoffmann wrote:
> Hi all.
>
> I am doing code generation from models in a standalone app. The
> project I work on is currently being transitioned from Eclipse 3.2 to
> Eclipse 3.3. My code (which is basically straight from the docs)
> worked flawlessly in 3.2. Unfortunately, not exactly so in 3.3:
>
> When generating code for the first time, it still works fine. But when
> regenerating, the following exception occurs:
>
> java.lang.IllegalStateException: Workspace is closed.
> at
> org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
>
> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
> at
> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
>
> at
> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>
> at
> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>
> at
> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>
> at
> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>
> at
> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>
> at
> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>
>
> So the merging with the already present code seems to require the
> workspace?
> This did work in 3.2, anybody know how to make it work in 3.3? I
> wouldn't care if the already present code would be totally disregarded...
>
> For completeness, code is below (like I said, straight from the docs):
>
> // Globally register the default generator adapter factory
> for GenModel
> // elements (only needed in stand-alone).
> //
> GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
> (GenModelPackage.eNS_URI,
> GenModelGeneratorAdapterFactory.DESCRIPTOR);
>
>
> Generator gen = new Generator();
> gen.setInput(genModel);
> gen.generate(
> genModel,
> GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
> new BasicMonitor.Printing(System.out));
>
>
--------------060502010804020602040204
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Conrad,<br>
<br>
That sounds like <a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807">https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807</a>
but this was fixed in 3.4 not in 3.3.<br>
<br>
One of the Generator.Options is <br>
<blockquote>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Exception when regenerating code in standalone mode [message #416287 is a reply to message #416281] |
Fri, 25 January 2008 00:26 |
Conrad Hoffmann
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Ed,
thanks for the hint, I really thought that might be it, but
unfortunately not...
When using the JDOMFacadeHelper in 3.3, I get this:
java.lang.NullPointerException
at java.lang.String.compareTo(Unknown Source)
at
org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per.createCompilationUnit(JDOMFacadeHelper.java:97)
at
org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
at
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
at
org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
at
org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
at
org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
which originates here in JDOMFacadeHelper:
String sourceCompatibility = JavaCore.getOption(JavaCore.COMPILER_SOURCE);
if ("1.4".compareTo(sourceCompatibility) < 0) // <---
so JavaCore.getOption() returns null? I don't quite get it...
Anyways, I though I'd give the ASTFacadeHelper in 3.4 a shot. The latest
build does sometimes go fishin' on me, so I don't know if errors should
taken as 'might happen', but mostly it does work fine, and while the
original exception is gone, i have a new one in the exact same place
under the exact same preconditions:
java.lang.NullPointerException
at
org.eclipse.core.resources.ResourcesPlugin.getEncoding(Resou rcesPlugin.java:301)
at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2921 )
at
org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1688)
at org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2900)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
at
org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
at
org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
which boils down to this here failing:
String enc = getPlugin().getPluginPreferences().getString(PREF_ENCODING);
Now, I am beginning to fear that there is a ISO Layer 8 problem here
somewhere, by which I mean myself. I have 3.2 and 3.3 running in a 32bit
VM and 3.4 in a 64bit VM, so I have quite a mixture of working
environments and VMs here. If you so much as suspect that I screwed up
an install or something, let me know. Although on the other hand,
everything else does work fine so far... :/
If you have any more ideas, please let me know.
Thanks a lot!
Ed Merks schrieb:
> Conrad,
>
> That sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807
> but this was fixed in 3.4 not in 3.3.
>
> One of the Generator.Options is
>
> /**
> * The name of the {@link
> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper facade
> helper} class to be used in
> * Java merging.
> * @see org.eclipse.emf.codegen.merge.java.facade.FacadeHelper
> */
> public String mergerFacadeHelperClass;
>
> You could use that to specify
> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per which
> was the default in 3.2 but now the AST facade is the default.
>
> So probably gen.getOptions().mergerFacadeHelperClass =
> " org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per " will
> make it work as before.
>
>
> Conrad Hoffmann wrote:
>> Hi all.
>>
>> I am doing code generation from models in a standalone app. The
>> project I work on is currently being transitioned from Eclipse 3.2 to
>> Eclipse 3.3. My code (which is basically straight from the docs)
>> worked flawlessly in 3.2. Unfortunately, not exactly so in 3.3:
>>
>> When generating code for the first time, it still works fine. But when
>> regenerating, the following exception occurs:
>>
>> java.lang.IllegalStateException: Workspace is closed.
>> at
>> org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
>>
>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
>> at
>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
>>
>> at
>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>
>> at
>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>
>> at
>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>
>> at
>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>
>> at
>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>
>> at
>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>
>> at
>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>
>> at
>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>
>>
>> So the merging with the already present code seems to require the
>> workspace?
>> This did work in 3.2, anybody know how to make it work in 3.3? I
>> wouldn't care if the already present code would be totally disregarded...
>>
>> For completeness, code is below (like I said, straight from the docs):
>>
>> // Globally register the default generator adapter factory
>> for GenModel
>> // elements (only needed in stand-alone).
>> //
>> GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
>> (GenModelPackage.eNS_URI,
>> GenModelGeneratorAdapterFactory.DESCRIPTOR);
>>
>>
>> Generator gen = new Generator();
>> gen.setInput(genModel);
>> gen.generate(
>> genModel,
>> GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
>> new BasicMonitor.Printing(System.out));
>>
>>
>
>
|
|
|
| Re: Exception when regenerating code in standalone mode [message #416288 is a reply to message #416287] |
Fri, 25 January 2008 00:46 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Conrad,
Comments below.
Conrad Hoffmann wrote:
> Ed,
>
> thanks for the hint, I really thought that might be it, but
> unfortunately not...
>
> When using the JDOMFacadeHelper in 3.3, I get this:
> java.lang.NullPointerException
> at java.lang.String.compareTo(Unknown Source)
> at
> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per.createCompilationUnit(JDOMFacadeHelper.java:97)
>
> at
> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>
> at
> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>
> at
> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>
> at
> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>
> at
> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>
> at
> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>
>
> which originates here in JDOMFacadeHelper:
> String sourceCompatibility =
> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
> if ("1.4".compareTo(sourceCompatibility) < 0) // <---
> so JavaCore.getOption() returns null? I don't quite get it...
I suppose that when it's not able to get options it returns null. Is
null less that all strings?
>
> Anyways, I though I'd give the ASTFacadeHelper in 3.4 a shot. The
> latest build does sometimes go fishin' on me, so I don't know if
> errors should taken as 'might happen', but mostly it does work fine,
> and while the original exception is gone, i have a new one in the
> exact same place under the exact same preconditions:
> java.lang.NullPointerException
> at
> org.eclipse.core.resources.ResourcesPlugin.getEncoding(Resou rcesPlugin.java:301)
>
> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2921 )
I suspect it's not all properly guarded... :-( I didn't continue to
test after the fix they provided....
> at
> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1688)
>
> at
> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2900)
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>
> at
> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>
> at
> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>
>
> which boils down to this here failing:
> String enc = getPlugin().getPluginPreferences().getString(PREF_ENCODING);
>
> Now, I am beginning to fear that there is a ISO Layer 8 problem here
> somewhere, by which I mean myself.
Well, it's nice you are self deprecating, but that's not so clear.
> I have 3.2 and 3.3 running in a 32bit VM and 3.4 in a 64bit VM, so I
> have quite a mixture of working environments and VMs here. If you so
> much as suspect that I screwed up an install or something, let me
> know. Although on the other hand, everything else does work fine so
> far... :/
We don't have such good tests for the standalone stuff with respect to
code generation.
>
> If you have any more ideas, please let me know.
Probably we need to try to reproduce this locally. But how best to do
that?
> Thanks a lot!
>
> Ed Merks schrieb:
>> Conrad,
>>
>> That sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807
>> but this was fixed in 3.4 not in 3.3.
>>
>> One of the Generator.Options is
>>
>> /**
>> * The name of the {@link
>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper facade
>> helper} class to be used in
>> * Java merging.
>> * @see org.eclipse.emf.codegen.merge.java.facade.FacadeHelper
>> */
>> public String mergerFacadeHelperClass;
>>
>> You could use that to specify
>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per which
>> was the default in 3.2 but now the AST facade is the default.
>>
>> So probably gen.getOptions().mergerFacadeHelperClass =
>> " org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per "
>> will make it work as before.
>>
>>
>> Conrad Hoffmann wrote:
>>> Hi all.
>>>
>>> I am doing code generation from models in a standalone app. The
>>> project I work on is currently being transitioned from Eclipse 3.2
>>> to Eclipse 3.3. My code (which is basically straight from the docs)
>>> worked flawlessly in 3.2. Unfortunately, not exactly so in 3.3:
>>>
>>> When generating code for the first time, it still works fine. But
>>> when regenerating, the following exception occurs:
>>>
>>> java.lang.IllegalStateException: Workspace is closed.
>>> at
>>> org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
>>>
>>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
>>> at
>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
>>>
>>> at
>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>
>>>
>>> So the merging with the already present code seems to require the
>>> workspace?
>>> This did work in 3.2, anybody know how to make it work in 3.3? I
>>> wouldn't care if the already present code would be totally
>>> disregarded...
>>>
>>> For completeness, code is below (like I said, straight from the docs):
>>>
>>> // Globally register the default generator adapter
>>> factory for GenModel
>>> // elements (only needed in stand-alone).
>>> //
>>> GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
>>> (GenModelPackage.eNS_URI,
>>> GenModelGeneratorAdapterFactory.DESCRIPTOR);
>>>
>>>
>>> Generator gen = new Generator();
>>> gen.setInput(genModel);
>>> gen.generate(
>>> genModel,
>>> GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
>>> new BasicMonitor.Printing(System.out));
>>>
>>>
>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Exception when regenerating code in standalone mode [message #416301 is a reply to message #416288] |
Fri, 25 January 2008 15:32 |
Conrad Hoffmann
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
This is a multi-part message in MIME format.
--------------060709040602060309050102
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Ed,
please see below.
Ed Merks schrieb:
> Conrad,
>
> Comments below.
>
> Conrad Hoffmann wrote:
>> Ed,
>>
>> thanks for the hint, I really thought that might be it, but
>> unfortunately not...
>>
>> When using the JDOMFacadeHelper in 3.3, I get this:
>> java.lang.NullPointerException
>> at java.lang.String.compareTo(Unknown Source)
>> at
>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per.createCompilationUnit(JDOMFacadeHelper.java:97)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>
>> at
>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>
>> at
>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>
>> at
>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>
>> at
>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>
>> at
>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>
>> at
>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>
>> at
>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>
>>
>> which originates here in JDOMFacadeHelper:
>> String sourceCompatibility =
>> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
>> if ("1.4".compareTo(sourceCompatibility) < 0) // <---
>> so JavaCore.getOption() returns null? I don't quite get it...
> I suppose that when it's not able to get options it returns null. Is
> null less that all strings?
no, that's what actually throws the NullPointerException.
I didn't think about it first, but it does make sense that the options
are unavailable in a non-Eclipse environment. So maybe this should be
guarded too?
>> Anyways, I though I'd give the ASTFacadeHelper in 3.4 a shot. The
>> latest build does sometimes go fishin' on me, so I don't know if
>> errors should taken as 'might happen', but mostly it does work fine,
>> and while the original exception is gone, i have a new one in the
>> exact same place under the exact same preconditions:
>> java.lang.NullPointerException
>> at
>> org.eclipse.core.resources.ResourcesPlugin.getEncoding(Resou rcesPlugin.java:301)
>>
>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2921 )
> I suspect it's not all properly guarded... :-( I didn't continue to
> test after the fix they provided....
>> at
>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1688)
>>
>> at
>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2900)
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>
>> at
>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>
>>
>> which boils down to this here failing:
>> String enc = getPlugin().getPluginPreferences().getString(PREF_ENCODING);
>>
>> Now, I am beginning to fear that there is a ISO Layer 8 problem here
>> somewhere, by which I mean myself.
> Well, it's nice you are self deprecating, but that's not so clear.
>> I have 3.2 and 3.3 running in a 32bit VM and 3.4 in a 64bit VM, so I
>> have quite a mixture of working environments and VMs here. If you so
>> much as suspect that I screwed up an install or something, let me
>> know. Although on the other hand, everything else does work fine so
>> far... :/
> We don't have such good tests for the standalone stuff with respect to
> code generation.
>>
>> If you have any more ideas, please let me know.
> Probably we need to try to reproduce this locally. But how best to do
> that?
I packed up an example project, which generates a genmodel for the
well-known extlibrary.ecore and the Java code respectively. With it, one
can conviently reproduce the error (at least I can, in 3.3, not so in
3.2). Now, I hope the code is not too horrible, but there is just very
little documentation regarding stand-alone model/code generation...
The following oddities can be reproduced with that project:
1) The Exception I originally descried: regenerating in stand-alone mode
will fail when trying to merge code (both facade halpers)
2) The generated genmodel does look a little odd itself. E.g.
<genClasses>
<ecoreClass href="extlibrary.ecore#//Book"/>
...
</genClasses>
instead of:
<genClasses ecoreClass="extlibrary.ecore#//Book"
labelFeature="#//extlibrary/Book/title">
....
</genClasses>
But the Genmodel editor doesnt complain, so...?
But also see next point:
3) When using the generated genmodel to generate Java code via the
Genmodel Editor (right click, Generate model code), the code generation
will not complain, but, if there was aleady present code, generate
strange duplicate things, i.e. invalid code like this:
public void setTitle(String newTitle newTitle)
This also does not happen in 3.2 though, so my guess is it also does
relate to the merging process?
I would really like this to work, and I would be willing to put some
effort into fixing things, if this is required and/or possible.
But maybe the generation code is just flat out wrong?
I secretly hope you have some ideas already ;)
I'll be gone for the weekend now, so I wish you a nice one, too.
>> Thanks a lot!
>>
>> Ed Merks schrieb:
>>> Conrad,
>>>
>>> That sounds like https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807
>>> but this was fixed in 3.4 not in 3.3.
>>>
>>> One of the Generator.Options is
>>>
>>> /**
>>> * The name of the {@link
>>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper facade
>>> helper} class to be used in
>>> * Java merging.
>>> * @see org.eclipse.emf.codegen.merge.java.facade.FacadeHelper
>>> */
>>> public String mergerFacadeHelperClass;
>>>
>>> You could use that to specify
>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per which
>>> was the default in 3.2 but now the AST facade is the default.
>>>
>>> So probably gen.getOptions().mergerFacadeHelperClass =
>>> " org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per "
>>> will make it work as before.
>>>
>>>
>>> Conrad Hoffmann wrote:
>>>> Hi all.
>>>>
>>>> I am doing code generation from models in a standalone app. The
>>>> project I work on is currently being transitioned from Eclipse 3.2
>>>> to Eclipse 3.3. My code (which is basically straight from the docs)
>>>> worked flawlessly in 3.2. Unfortunately, not exactly so in 3.3:
>>>>
>>>> When generating code for the first time, it still works fine. But
>>>> when regenerating, the following exception occurs:
>>>>
>>>> java.lang.IllegalStateException: Workspace is closed.
>>>> at
>>>> org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
>>>>
>>>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
>>>> at
>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
>>>>
>>>> at
>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>
>>>>
>>>> So the merging with the already present code seems to require the
>>>> workspace?
>>>> This did work in 3.2, anybody know how to make it work in 3.3? I
>>>> wouldn't care if the already present code would be totally
>>>> disregarded...
>>>>
>>>> For completeness, code is below (like I said, straight from the docs):
>>>>
>>>> // Globally register the default generator adapter
>>>> factory for GenModel
>>>> // elements (only needed in stand-alone).
>>>> //
>>>> GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
>>>> (GenModelPackage.eNS_URI,
>>>> GenModelGeneratorAdapterFactory.DESCRIPTOR);
>>>>
>>>>
>>>> Generator gen = new Generator();
>>>> gen.setInput(genModel);
>>>> gen.generate(
>>>> genModel,
>>>> GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
>>>> new BasicMonitor.Printing(System.out));
>>>>
>>>>
>>>
>>>
--------------060709040602060309050102
Content-Type: application/octet-stream;
name="emf_gentest.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="emf_gentest.zip"
UEsDBBQACAAIAL2AOTgAAAAAAAAAAAAAAAAWAAAAZW1mX2dlbnRlc3QvLmNs YXNzcGF0aJ2Q
QUsDMRCFzxb8D0vunbWX4mHXIrKChVZpV6+SJkM6mk7iJCn231upRfFQxNu8 4XuPx2sm7xtf
bVESBW7VCC5UhWyCJXateuxvh5dqcnU+aIzXKUWd13tx9q2Qs+yqV2LbqiRG VZ/Pw1n/iXTI
p0gT+EgGcYDGU0wILzaD14XNet8Tpovu+eZ+3l/fzbtF/ZsjziisPVhcFQeF vpwosMyarRb7
NOt3Eeup3uplNxzB+B+VokUwQRAE3woJ2gdfHHE6FRVKjiUf01Z0mKKpf479 AVBLBwgPKnBk
0gAAAKIBAABQSwMEFAAIAAgAvYA5OAAAAAAAAAAAAAAAABQAAABlbWZfZ2Vu dGVzdC8ucHJv
amVjdL2ST2sDIRDFzynkO4S9V9NbD2YX0pJbSyHtORidNS7rH9QN/fhV46Ys YSGH0tu8N/P8
jSJpvlW/OoPz0uhN9YTW1Qo0M1xqsam+PnePz1VTLx+IdaYDFl7BMydtiNPR XRBNFdSg2oMA
HcAHgrOTWswoFc2a4LFKbjnHZ4En6jjInu8tsKSKfIlRqnl2Cs04gYD10npA HQ+IGRcLeqY5
AO53hZigTgyJ7YvGU4PgG8pdXMsBvVEt23jl7f9i9+wEiv4JtDjjk0deGByU 6YuYf+1LPy2Q
5+YyaeWPfhBSv98ExjoRr39h+sN+AFBLBwhMH/pc6gAAAKACAABQSwMEFAAI AAgAvYA5OAAA
AAAAAAAAAAAAACAAAABlbWZfZ2VudGVzdC9NRVRBLUlORi9NQU5JRkVTVC5N Rn2Pyw6CMBBF
9yT8Ax8gDbJk6R5jNHFrsFyaMbTFPoz+vQ2YLhDYNJOec+dRN4o6WJdfYSxp VWV7VqTJwau2
R17/aIRlRMdGosogu5uAcsHJTr0XOaloXD7yrnvif2Y0YtuCjVPPeHoyyCdc ZdoIBt7TYMG4
NmDGK0cSuzRZYLDaGw47p4/Wjcb8P2wU6i3A3pKWINctwi3raZKDNg5mi62n uVYvrMVlMwyk
xJQuxzdNvlBLBwiqD0UVsQAAAMYBAABQSwMEFAAIAAgAvYA5OAAAAAAAAAAA AAAAACEAAABl
bWZfZ2VudGVzdC9iaW4vdGVzdC9UZXN0ZXIuY2xhc3OtWAlgHFUZ/v5cs7uZ 9NhebIHSQI9N
aXfb9IJNKU2TNE2bpCEJCSlHnW4mmyl7ObtpGzxAFC8QEURA8QIUFEUJkrJU EfFA8cJbPPDA
G0W8UFGB783u5tySLZLjzZv3/uv995tHnrv/AQC1sllDiaAybabSwW4Opq2h TDDngHHQCEaN
eCS4Z/8BM5wmTNJOqFm7ETMF3tZxiK60bcUjdQLXlnDUilvprYJSf02PoKwh 0W+6UElsMzaw
L2LGFSM3BFU6ylEhmN1qxc32odh+0+429kcdyomwEe0xbEu95xYrtjh0PSiF V8ccuEg7PWil
SKh1guyUoSxmWHHBQv/50yWs6XHhBO7FKFU0aB5OR639tmEPB8xwwjY9WIyT NJwoOCVhR4Im
z5JMmUEKHgwnYrFEPDiUtqLBcztbdJyMJWQdtk0jbe6woiYXBRv9BVi2zkCr zoWlAt80kagr
Z03DqQLdoWslgoqXC8sEEvCgGiuULlYKFhTi3ONGDU7XsGqSObuGqaiYjtVY QyslhmjZBa15
8h3ETBPfNGJ1in5Qx1qso5UiZrp+fyoRHUqbHUZ6UDDfXzOdpQfrsVHDBsG8 AhR1bFKyakm1
FI17cAZCGs4U+KeqyDFHMBkdiljxYJN66XDmOuqwhfajNB1RIz2QsGOdZiox ZIfNNiMpmJsX
ylEul+oqsRXbNJxNY03a0FGP7Tx/Up3/jInay7p73fSVmulLGhoF6wtLb+cE C1qxZDSYF7PL
TLfw3YMGeN1oRouGnRRgBhJ57GU7jHA6YQ8v6zQjViptD+vYhd2Mu5b2ru76 9oYmQWiavxVL
i7pqwx4N7YJVRdLgaXR04BzB4pSZzq/mCOfpCs7yv3Shano0dAmapxKIGckk XS5LqDZLzjGu
4y61zjhFoKziO+GtpOJ7dPQqXzqBvtR0OG3GU1Yi3p3IgdJDXOhjlK1SSjlf xwW4kDksMn5I
Qdv0U00N7b3To/8YB6fy98HQ8ArByiJRdOxHOCtUQ4J5NZ5mNlzuf/GE09RK tZKZiYiGAUH1
jMA6BmExUshG5ZmWgmFwsWBJYbGbOozwxUbE1BBjfI7H4E4jNUj38SCq7JEE y84rJwWp41sp
kGmp0d8/JcXlQ3KvCweZ3aZmcqXMwzqGcQkrBz3Tyc7LZrZXTY8y96t1vAav FczKpvdxi7cW
QaFog7txGS7X8DrBpulE+02m/xxqvhAEm814m5rkfFTH6/EGgdscD/4zCshX DCk6xGV4o443
4c1jx86DMMEV9KkXpet4mF2JK/E2DVcJgseJr+NqvF3gUUXfMqLWJdS+zz8h tzckolF6AGPW
KervEJxNFoEciwBZBHIsAjHTjpgBhRoYMMJGP+f9iVhgV+Oeth3O+04zmjQd Ya/T8U5VoubT
ZybuNUSNVMqNd+FGDTcIaos/za7G3a3mQXWgm/Bu+jffN67d19rS3dRZ3yrY cByKzZOqU5Le
rOO9eB+bpZSKfiY2y4iHTWdfsLmQn85IVjn/lfiAjg/iFnqBImzECWDa9Ab2 Vf69WYjbdHxI
Qcx1WPebO1iFjXSaydiF22mz8WBU0B/R8VGlUp3QjmlV+6jhY4JFU9uH7UNW tN+0XbiLiTfo
wZ1YoYa7dYzgHgYyM74ZZyZYU7DNOgY1tlf3Unh1ZEXsiI77VEPjSieyYErG +3UcVTLOzcvY
aNmmExhq9zM6HlCJVvVAPKtpRbI+qvYe1PE5tTeLe1RVLtelNHxesK54G+Tw XPgi9cdq1JrX
30N4WMeXlWxuytZhmwPWYRceESyd6u3mYYNeYKYC0XHcr+n4usJVttxupMwc Gze+iW9peJQ5
tVBApXR8G98hx6a2ju6+fW31HapLn9pW7cP3dHwfP6BuU8ZB1bb7p8DU9Hjw GH6s4UcT2sGW
PU2Hw2ZS8dHxE9XGz05mO0TK1m0bYUr3OH6u4WeCrhkVqFwzYQeb87P6fiPJ W0C+iWg0U2Hb
SnI+qWH6heDcmQPk+GnT1Z5gMzuYTidDweChQ4fGDOQwI5PatWtrx3KcG7/G bzX8RtBRpKdM
ksqhcQzpdPwOv6crNTZ1NXS2dHTv6WTxehmPTPs/jid1/BF/Yk5jeR7fEhgF wvPl5F2zV8Of
iwmvqSQ9eApeNfxVx9/wd+qHUbvH8cWUalKLqHJTSS7LobOaP4N/afin4MyX TETHv9WNeJFT
sOxp9UdJ/h8d/8X/mL4Y0S1x5/JSsC9iSXyeRzpWSXREGbthBsZkCjhO1ZG9 52siBbU83vAw
p1jhtgRrNA/hXPRoaw+TdymvpVLG5tpf8GapMsNTUqGLJkwArshYjUkVdRF7 0SYsJ84M9+5G
y4jEE6m0FVZfDAw7QgeYV+CDAaVzdOU0kNUzdn9ON55VqoMh7LBntU68uxPE k/uO4kBU2uNX
KcHqYrtHQpNSqW1GeJ8eyMaIoGUa+ku8Jalz22Ntb/E9rVJXrsiwRB0DLX8j UNDJXMGcXGGy
p5sTySW58QbcFRlrStcdd0tKc5gTv3VMKEV1zv0mzlb3+FMAcRdO/mI1nMx/ tVo3+VBbZtLI
VhKrckohC6hDQxPGk6crayBL0azMfulyGlq2VS3xeC4/KC1quVSiyWrBrpcv 6WoSyHbY/w89
VZAm1AlXvm5qUlvgG9CxEg0R86lGk40FrhYzfFqgknIzVIN2Bzh61MdIzkrh gsZ/dj98W8Wn
+qnweu6BfjdnJZjF0cMnsIQ4J2K2s6pozBnDC/KpMMtXHcHccbQKZzGLomcB MA/z+XRjARZm
kUsPEI7Qcod30X3wtXpP4dh2FNV93tOOYHn7CPxrRhEYRa16cC9Udh82j0D3 lWVwVil6j6Kh
7wiaQuUj2BGq8JX7KjJoLWGD28nl7pCm3s9lu3aeT8si+MpPJ+reUoRcPlcG F1EnGfSX4EEc
CLmPIkq0eMjj8/jcGSRKCO/yDpFvBodK4CtfncGrShCqHMGlGVwhCOm+SoeI T8/gLQpc93ky
eCthde81GVyrJiO4PoP3qBk5vz/3vNUB+XAGd6jJUdzZ5/34EXyCRxvFJ72f 4jCK0QwyJQ7p
T/MIQ3kOGXx2XOqHvF/I4EtZqEnLX8ngq1ymqN/I4LsluB2eUJWvahQ/HMFP vb8cwa8y+IOj
wad45qeze3/xXnMv/uGr8lGKZ9XD+9xRQR/NcERKRqW8926I9Ioh/Wx2yxw7 P0AHAJ2rAqfS
zstp2RVYipWogR+rOQbpWOs438y3bViDJgTQjrXo5eog1iOFDbgCG3kF3oQb CXUbzsRdCPHi
UoeHcRYexVbyOhtPEPtJ1LOX2c6uoEEWo1Fq0CzbsFN6sZsStckA2uVidEuc Nk/xOYxeuRzn
yVXok+uwV67H+XIDLpCbcKHcyvfbcZHjnzeqUe4Qt3iU58otUinKZ3W5Wao4 K8FCuVZmyWyG
TI1cKnO4VoZtMihzxUu/bpKwzMNu6qBXzpH5soBhlWK4LpRFDJMr5DQ5QXz0 96tlMX9PZEjd
hWflJO5W8pxPy8myhLwGUC6nyFJUUeYVUi2ncnZaLnqymMvgkeVc2YCS53ng Kk1WaFjs/FU7
Y5uGZg2dGvZpOKAh6UyuhGh4rAIlslJFp/ipN6CW0j7DxmQV3HK6rJFgBe8i nK2tcDOe18l6
rm/APtnE9WbZoNZfAFBLBwi5inazrwoAAEcZAABQSwMEFAAIAAgAvYA5OAAA AAAAAAAAAAAA
ACIAAABlbWZfZ2VudGVzdC9tb2RlbC9leHRsaWJyYXJ5LmVjb3Jl7VnfT+M4 EH7nr4iyz+DC
vZyqlhXlioQEt2hhudtHN5m2Fokd+Qdt//sbO4nbpgXaOt1brbYPQNzx+JvP n2fGofd5nmfR
K0jFBO/H52edOAKeiJTxST/+9nRz+mf8+fKkB4mQ0B0+0OSFTiCa56zrJ13g pJMIP+iKqy5+
14+nWhddQmaz2ZnIJ2dCTsi/97dxbaLWTWZ/OIuLTuccze4ekynk9JRxpSlP YNW5w7E2F5KM
FQqcA8jH1skFGVqzOOI0R2OY64yNJJWL0hNX377eeh/ETSydOAcwp3mRgSLV JLKcf+aWJ8iS
5YmrBwljNq9XiC/RfQ+uM6oUGzOkJ8JAu3pRWBAlge7LGthAiBek+9EUIJ/Q SvXjT4RcM5mY
jGrcgVsNufNq/T5qaRJtJM1ugOJv2OL+SmvJRkb72DXTGT7A06rVX1RTOxDt RCNCGuLaCCcm
QVgKVI4Kx3LLdbmP9pPCmJpMP9PMwB3TgIhQxZ1OINSEapgIFEyNFhe2u3Vd j3sAhivQmo4y
S7Y0sN/CX2EMEqzGq4Wp0VMh4ygTM5ADYXiK4SxXW6L5R9poEd+XohAK/14Z JSOEqkokPbIq
yH0Veledmw2RXqUpBqRs3GECtT//H31ucD9z5GHspig8+afvsv8q7EH1ex9p SbliwHU9kIJk
r5DWj4ngmjKeLy0uK+89uOJcaPQmuIqUMDKBd3KUy0MGlybDuQaeQnoPmlri vEf0meIYy1T0
Aot+PJHCFAjZHhUMogCBWa6mzAllBUFFJNnCZBDHgKlVLAB2YnlYGf/meW+e R0JKm0J24nlQ
Gf/meW+elRYJ1nAhkRhLy5hmClaqwzr3K5y70r6Fv7AUVib+A+CUrcgH2x2I DZ1jY7eTIn3d
2SSoUfEqS1JQXEwP3BqBQNdcbQG1xLsViY8zsFsq9fwRWQeXzArKPS2GXGNU P+7gvjCe+nNb
nuLDTm1Yb+M7qEZr84BTBf+JuhpP40fZuZXcsUu5cNeWNfHbMVI1r4f1nUNu 8tWLkW+166Cq
9l5VNvcLhc+LZdCN7x8TZqO7YYmVktfb+ZsTBkxMJC2mC2970UYLXSZ6OlK4 W8l6lTw0M5hR
xhJ3QlBTLejMeWnjtoDn390ImuFGjCPVY5pAG/EnomC2jLx/Rwq6X4aeJN98 HVKJ62asecLK
cVJ5T9vYsea7ho2NayZHaxXZYldvNdl3SUyvTKSo32y31X6d9x9MKQMK4/8O 9MMrfrh8w5Rx
ZVImnpkyNNtNGb/sa6uccXxSqPiJnv48WWcDZ0pzOsG0EAwFq28GlLehIlvI v/AnWmwRTFNh
QSlXAk1dzvR5tGrj2nkdt/HmpwVunlkK4hoHQOtj05NQpTdauzfICt1xX77C ++q3Kmu60x3S
dyONe1o1TpZluoW4q+iO96J0zKTSf7t7xZFSUCvZEjn5cSjDtmz5evEYUs0p x3S8ljv8gm3U
5xVdHbfdpuVK7VbjZvA9sv4fxsuT/wBQSwcIZzQ3nl4EAACaHAAAUEsDBBQA CAAIAL2AOTgA
AAAAAAAAAAAAAAAgAAAAZW1mX2dlbnRlc3Qvc3JjL3Rlc3QvVGVzdGVyLmph dmGlV9tu2zgQ
fXaA/AOhJ3mbpYsCfWmaAlnbad3GsWF7H4rFwmCkscIsJQoUlSa76L/vkCKt i+2kSQJHoMg5
h8Ph3JSz6B+WANFQ6NPjo+MjnuZSaXLL7hjlkl5wAac7s5PZ+D6CXHOZdRZL zQUdSiEgMqvF
vuUvrLhZgt63VE1vF6RKKESC5wVQSDc0kjEkkOGcVEBxBIppqehnPzp9OfQ8 ZrkGdcEifHl4
BlGKE8LwfB19u4Q7EC/BTs3gxcBXKG3x88oLno1vmfEPVkDXmq9jtLq94ILS VGaVP6FOPJrK
jD/hGzXiz8XksGCl7PhJc1VyuSgTntGxeZnb8VMIBYUsVQR04QbPBrTi6hcx 1JkUJxJe6Mds
22FAKdHceoLvh8Epy3OeJRXJu4rK2txa6J19ejKnkiM8PsrLa8EjEglWFGSF yQoU+e/4qIe/
wYAw4xpES5IyHd0QfQMkKpWCTJNcyVvMRQXJWAofCMrnit8xDaTQTCPlUitU ystdoRQ5IwHq
u0ZfNGkxsAr0nAYOdSd5jLvxLKzwf/1NmEqKvlWqh05E7PnM4Izgk0YKcFOT TvEtDKy3D+Be
C36tGNreigf9Uw/3EfHrDB7hSMw/muZCKqNzFv/OhMyAGJEPqHlWMiEecJCT wUd3+E8DSo0V
m/aLuTJMZluyQU0y+EHMSxhQt9HyAW8jpbLUFE2baZGFG1RGn18XUpQa5kzf hP36ZG6zQwc7
iG3EkRGZC6Y3UqXeY6YsD/s0L3VohHu9xoWetGZwk9pCDeclqjGuDtpx7bDC +TBBQIKCB8OI
Tq6Wq/Or4diiGuy0AN1xdI8JkbNfOVzv8bAgm2rsVH1c2GmO5MZ043sNWYHl eSWdTG284Lfg
xFN7RTzh1kK4Z/M4SX2c0Lv9CdGqBHdzLmES8IMzEvrJ/jabIM1QYshlukBl 8C186zwM9Ecv
/onk1aBwB3fdRC3gzurFKIvj0G/cb12FuQfjcnuiazcyd4yRuAK12G+UinBr l0Y8V0r4+rbl
QXynnlPwHuTY/Lo7YleDjgXNwb1I7fF+hnKsipwJ/i+E3lb9044MGgh1YTF8 AZGDGpr0GwaH
ankKKgFqu7mNRdHbWKb062g2bbIEbe3NJkOJTspZFoHtoMJGN4Xwb+/fri8n q/Hi/HIPlGWu
RYCwdrk2eQyYBrE2aMzUB4TswCSL5t3v0dQORlyBvaEwGATkTat4vCHBAAFd KF4N6gA88Tdo
r2ePnzk3w9T9Q5YiJmVRZeprIIwIKfMuLZ7eeXcdNkbTuYINvw8DjPbL/cd5 BGyaObewe99w
z/C6MLRaZjLUJivaCrjrmwW7g7DxZUDH0/nq+3p6Pq+0+mkeka3fYeP7goCr qT2oystSo1or
xTCmGsDjI+L+0HCfhby2NlM2q2KrYCpaDBtWCk22LWbVNuCqz6RYTrYh2CIE AakJKhLKDGkz
gBhiwrNmZe3TFqR+OdDA0hEUkeK56XV3KoZxjnq95iIk7PTsFK6Wa5tvn2iY 6Wi8HC4m89Vs
Yezm+VwqchZB27i0up2rc41xj5m9FOMrNtjVTnYwzdNr88N2Q3TESWaqUjuN Vbq4mK9quxdw
pf7A5widzkbjy/V8Mfs6Hq7Wq+/zsQOYIzc/Fujc+JpJF3V7U/UhP0184uN/ UEsHCIcqTWLY
BAAAOg8AAFBLAQIUABQACAAIAL2AOTgPKnBk0gAAAKIBAAAWAAAAAAAAAAAA AAAAAAAAAABl
bWZfZ2VudGVzdC8uY2xhc3NwYXRoUEsBAhQAFAAIAAgAvYA5OEwf+lzqAAAA oAIAABQAAAAA
AAAAAAAAAAAAFgEAAGVtZl9nZW50ZXN0Ly5wcm9qZWN0UEsBAhQAFAAIAAgA vYA5OKoPRRWx
AAAAxgEAACAAAAAAAAAAAAAAAAAAQgIAAGVtZl9nZW50ZXN0L01FVEEtSU5G L01BTklGRVNU
Lk1GUEsBAhQAFAAIAAgAvYA5OLmKdrOvCgAARxkAACEAAAAAAAAAAAAAAAAA QQMAAGVtZl9n
ZW50ZXN0L2Jpbi90ZXN0L1Rlc3Rlci5jbGFzc1BLAQIUABQACAAIAL2AOThn NDeeXgQAAJoc
AAAiAAAAAAAAAAAAAAAAAD8OAABlbWZfZ2VudGVzdC9tb2RlbC9leHRsaWJy YXJ5LmVjb3Jl
UEsBAhQAFAAIAAgAvYA5OIcqTWLYBAAAOg8AACAAAAAAAAAAAAAAAAAA7RIA AGVtZl9nZW50
ZXN0L3NyYy90ZXN0L1Rlc3Rlci5qYXZhUEsFBgAAAAAGAAYAwQEAABMYAAAA AA==
--------------060709040602060309050102--
|
|
|
| Re: Exception when regenerating code in standalone mode [message #416305 is a reply to message #416301] |
Fri, 25 January 2008 15:59 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Conrad,
I was just chatting with Marcelo and he explained that JDOM can't work
stand alone and never did. You must not have been doing merging
before. Is that right?
Conrad Hoffmann wrote:
> Hi Ed,
>
> please see below.
>
> Ed Merks schrieb:
>> Conrad,
>>
>> Comments below.
>>
>> Conrad Hoffmann wrote:
>>> Ed,
>>>
>>> thanks for the hint, I really thought that might be it, but
>>> unfortunately not...
>>>
>>> When using the JDOMFacadeHelper in 3.3, I get this:
>>> java.lang.NullPointerException
>>> at java.lang.String.compareTo(Unknown Source)
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per.createCompilationUnit(JDOMFacadeHelper.java:97)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>
>>> at
>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>
>>>
>>> which originates here in JDOMFacadeHelper:
>>> String sourceCompatibility =
>>> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
>>> if ("1.4".compareTo(sourceCompatibility) < 0) // <---
>>> so JavaCore.getOption() returns null? I don't quite get it...
>> I suppose that when it's not able to get options it returns null. Is
>> null less that all strings?
>
> no, that's what actually throws the NullPointerException.
> I didn't think about it first, but it does make sense that the options
> are unavailable in a non-Eclipse environment. So maybe this should be
> guarded too?
>
>>> Anyways, I though I'd give the ASTFacadeHelper in 3.4 a shot. The
>>> latest build does sometimes go fishin' on me, so I don't know if
>>> errors should taken as 'might happen', but mostly it does work fine,
>>> and while the original exception is gone, i have a new one in the
>>> exact same place under the exact same preconditions:
>>> java.lang.NullPointerException
>>> at
>>> org.eclipse.core.resources.ResourcesPlugin.getEncoding(Resou rcesPlugin.java:301)
>>>
>>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2921 )
>> I suspect it's not all properly guarded... :-( I didn't continue to
>> test after the fix they provided....
>>> at
>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1688)
>>>
>>> at
>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2900)
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>
>>> at
>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>
>>>
>>> which boils down to this here failing:
>>> String enc =
>>> getPlugin().getPluginPreferences().getString(PREF_ENCODING);
>>>
>>> Now, I am beginning to fear that there is a ISO Layer 8 problem here
>>> somewhere, by which I mean myself.
>> Well, it's nice you are self deprecating, but that's not so clear.
>>> I have 3.2 and 3.3 running in a 32bit VM and 3.4 in a 64bit VM, so
>>> I have quite a mixture of working environments and VMs here. If you
>>> so much as suspect that I screwed up an install or something, let me
>>> know. Although on the other hand, everything else does work fine so
>>> far... :/
>> We don't have such good tests for the standalone stuff with respect
>> to code generation.
>>>
>>> If you have any more ideas, please let me know.
>> Probably we need to try to reproduce this locally. But how best to
>> do that?
>
> I packed up an example project, which generates a genmodel for the
> well-known extlibrary.ecore and the Java code respectively. With it,
> one can conviently reproduce the error (at least I can, in 3.3, not so
> in 3.2). Now, I hope the code is not too horrible, but there is just
> very little documentation regarding stand-alone model/code generation...
>
> The following oddities can be reproduced with that project:
>
> 1) The Exception I originally descried: regenerating in stand-alone
> mode will fail when trying to merge code (both facade halpers)
>
> 2) The generated genmodel does look a little odd itself. E.g.
> <genClasses>
> <ecoreClass href="extlibrary.ecore#//Book"/>
> ...
> </genClasses>
> instead of:
> <genClasses ecoreClass="extlibrary.ecore#//Book"
> labelFeature="#//extlibrary/Book/title">
> ....
> </genClasses>
> But the Genmodel editor doesnt complain, so...?
> But also see next point:
>
> 3) When using the generated genmodel to generate Java code via the
> Genmodel Editor (right click, Generate model code), the code
> generation will not complain, but, if there was aleady present code,
> generate strange duplicate things, i.e. invalid code like this:
> public void setTitle(String newTitle newTitle)
> This also does not happen in 3.2 though, so my guess is it also does
> relate to the merging process?
>
> I would really like this to work, and I would be willing to put some
> effort into fixing things, if this is required and/or possible.
> But maybe the generation code is just flat out wrong?
> I secretly hope you have some ideas already ;)
>
> I'll be gone for the weekend now, so I wish you a nice one, too.
>
>>> Thanks a lot!
>>>
>>> Ed Merks schrieb:
>>>> Conrad,
>>>>
>>>> That sounds like
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807 but this was
>>>> fixed in 3.4 not in 3.3.
>>>>
>>>> One of the Generator.Options is
>>>>
>>>> /**
>>>> * The name of the {@link
>>>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper facade
>>>> helper} class to be used in
>>>> * Java merging.
>>>> * @see org.eclipse.emf.codegen.merge.java.facade.FacadeHelper
>>>> */
>>>> public String mergerFacadeHelperClass;
>>>>
>>>> You could use that to specify
>>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per
>>>> which was the default in 3.2 but now the AST facade is the default.
>>>>
>>>> So probably gen.getOptions().mergerFacadeHelperClass =
>>>> " org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per "
>>>> will make it work as before.
>>>>
>>>>
>>>> Conrad Hoffmann wrote:
>>>>> Hi all.
>>>>>
>>>>> I am doing code generation from models in a standalone app. The
>>>>> project I work on is currently being transitioned from Eclipse 3.2
>>>>> to Eclipse 3.3. My code (which is basically straight from the
>>>>> docs) worked flawlessly in 3.2. Unfortunately, not exactly so in 3.3:
>>>>>
>>>>> When generating code for the first time, it still works fine. But
>>>>> when regenerating, the following exception occurs:
>>>>>
>>>>> java.lang.IllegalStateException: Workspace is closed.
>>>>> at
>>>>> org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
>>>>>
>>>>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
>>>>> at
>>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
>>>>>
>>>>> at
>>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>>
>>>>>
>>>>> So the merging with the already present code seems to require the
>>>>> workspace?
>>>>> This did work in 3.2, anybody know how to make it work in 3.3? I
>>>>> wouldn't care if the already present code would be totally
>>>>> disregarded...
>>>>>
>>>>> For completeness, code is below (like I said, straight from the
>>>>> docs):
>>>>>
>>>>> // Globally register the default generator adapter
>>>>> factory for GenModel
>>>>> // elements (only needed in stand-alone).
>>>>> //
>>>>> GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
>>>>> (GenModelPackage.eNS_URI,
>>>>> GenModelGeneratorAdapterFactory.DESCRIPTOR);
>>>>>
>>>>>
>>>>> Generator gen = new Generator();
>>>>> gen.setInput(genModel);
>>>>> gen.generate(
>>>>> genModel,
>>>>> GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
>>>>> new BasicMonitor.Printing(System.out));
>>>>>
>>>>>
>>>>
>>>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Exception when regenerating code in standalone mode [message #416324 is a reply to message #416305] |
Mon, 28 January 2008 10:29 |
Conrad Hoffmann
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Ed Merks schrieb:
> Conrad,
>
> I was just chatting with Marcelo and he explained that JDOM can't work
> stand alone and never did. You must not have been doing merging
> before. Is that right?
Well, technically. In 3.2, when I regenerated the code, everything got
overwritten. There was no merging of user comments or non model methods.
But that's basically all I want: just to overwrite the old stuff.
Also, the process never even gets to any actual merging. Using the JDOM
helper in latest 3.4 build still gives the same error, and I really
think it just needs an additional null check:
[JDOMFacadeHelper:94]
public JCompilationUnit createCompilationUnit(String name, String
contents)
{
String sourceCompatibility =
JavaCore.getOption(JavaCore.COMPILER_SOURCE);
if ("1.4".compareTo(sourceCompatibility) < 0)
{
....
}
else
{
sourceCompatibility = null;
}
The compareTo throws the NullPointerException, but since for the rest of
the method null is an expected value for sourceCompatibility (because of
the else block), just checking for null before comparing should be an
adequate solution?
As for the AST helper, the problem is that JavaCore.getDefaultOptions()
will call ResourcePlugin.getPlugin().getXYZ(), but
ResourcePlugin.getPlugin() is null for me. I don't see how this is
supposed to work stand alone, unless I just totally missed how one is
supposed to initialize things when running in standalone mode. also, we
are not talking headless eclipse app here, are we?
> Conrad Hoffmann wrote:
>> Hi Ed,
>>
>> please see below.
>>
>> Ed Merks schrieb:
>>> Conrad,
>>>
>>> Comments below.
>>>
>>> Conrad Hoffmann wrote:
>>>> Ed,
>>>>
>>>> thanks for the hint, I really thought that might be it, but
>>>> unfortunately not...
>>>>
>>>> When using the JDOMFacadeHelper in 3.3, I get this:
>>>> java.lang.NullPointerException
>>>> at java.lang.String.compareTo(Unknown Source)
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per.createCompilationUnit(JDOMFacadeHelper.java:97)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>
>>>>
>>>> which originates here in JDOMFacadeHelper:
>>>> String sourceCompatibility =
>>>> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
>>>> if ("1.4".compareTo(sourceCompatibility) < 0) // <---
>>>> so JavaCore.getOption() returns null? I don't quite get it...
>>> I suppose that when it's not able to get options it returns null. Is
>>> null less that all strings?
>>
>> no, that's what actually throws the NullPointerException.
>> I didn't think about it first, but it does make sense that the options
>> are unavailable in a non-Eclipse environment. So maybe this should be
>> guarded too?
>>
>>>> Anyways, I though I'd give the ASTFacadeHelper in 3.4 a shot. The
>>>> latest build does sometimes go fishin' on me, so I don't know if
>>>> errors should taken as 'might happen', but mostly it does work fine,
>>>> and while the original exception is gone, i have a new one in the
>>>> exact same place under the exact same preconditions:
>>>> java.lang.NullPointerException
>>>> at
>>>> org.eclipse.core.resources.ResourcesPlugin.getEncoding(Resou rcesPlugin.java:301)
>>>>
>>>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2921 )
>>> I suspect it's not all properly guarded... :-( I didn't continue to
>>> test after the fix they provided....
>>>> at
>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1688)
>>>>
>>>> at
>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2900)
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>
>>>> at
>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>
>>>>
>>>> which boils down to this here failing:
>>>> String enc =
>>>> getPlugin().getPluginPreferences().getString(PREF_ENCODING);
>>>>
>>>> Now, I am beginning to fear that there is a ISO Layer 8 problem here
>>>> somewhere, by which I mean myself.
>>> Well, it's nice you are self deprecating, but that's not so clear.
>>>> I have 3.2 and 3.3 running in a 32bit VM and 3.4 in a 64bit VM, so
>>>> I have quite a mixture of working environments and VMs here. If you
>>>> so much as suspect that I screwed up an install or something, let me
>>>> know. Although on the other hand, everything else does work fine so
>>>> far... :/
>>> We don't have such good tests for the standalone stuff with respect
>>> to code generation.
>>>>
>>>> If you have any more ideas, please let me know.
>>> Probably we need to try to reproduce this locally. But how best to
>>> do that?
>>
>> I packed up an example project, which generates a genmodel for the
>> well-known extlibrary.ecore and the Java code respectively. With it,
>> one can conviently reproduce the error (at least I can, in 3.3, not so
>> in 3.2). Now, I hope the code is not too horrible, but there is just
>> very little documentation regarding stand-alone model/code generation...
>>
>> The following oddities can be reproduced with that project:
>>
>> 1) The Exception I originally descried: regenerating in stand-alone
>> mode will fail when trying to merge code (both facade halpers)
>>
>> 2) The generated genmodel does look a little odd itself. E.g.
>> <genClasses>
>> <ecoreClass href="extlibrary.ecore#//Book"/>
>> ...
>> </genClasses>
>> instead of:
>> <genClasses ecoreClass="extlibrary.ecore#//Book"
>> labelFeature="#//extlibrary/Book/title">
>> ....
>> </genClasses>
>> But the Genmodel editor doesnt complain, so...?
>> But also see next point:
>>
>> 3) When using the generated genmodel to generate Java code via the
>> Genmodel Editor (right click, Generate model code), the code
>> generation will not complain, but, if there was aleady present code,
>> generate strange duplicate things, i.e. invalid code like this:
>> public void setTitle(String newTitle newTitle)
>> This also does not happen in 3.2 though, so my guess is it also does
>> relate to the merging process?
>>
>> I would really like this to work, and I would be willing to put some
>> effort into fixing things, if this is required and/or possible.
>> But maybe the generation code is just flat out wrong?
>> I secretly hope you have some ideas already ;)
>>
>> I'll be gone for the weekend now, so I wish you a nice one, too.
>>
>>>> Thanks a lot!
>>>>
>>>> Ed Merks schrieb:
>>>>> Conrad,
>>>>>
>>>>> That sounds like
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807 but this was
>>>>> fixed in 3.4 not in 3.3.
>>>>>
>>>>> One of the Generator.Options is
>>>>>
>>>>> /**
>>>>> * The name of the {@link
>>>>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper facade
>>>>> helper} class to be used in
>>>>> * Java merging.
>>>>> * @see org.eclipse.emf.codegen.merge.java.facade.FacadeHelper
>>>>> */
>>>>> public String mergerFacadeHelperClass;
>>>>>
>>>>> You could use that to specify
>>>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per
>>>>> which was the default in 3.2 but now the AST facade is the default.
>>>>>
>>>>> So probably gen.getOptions().mergerFacadeHelperClass =
>>>>> " org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per "
>>>>> will make it work as before.
>>>>>
>>>>>
>>>>> Conrad Hoffmann wrote:
>>>>>> Hi all.
>>>>>>
>>>>>> I am doing code generation from models in a standalone app. The
>>>>>> project I work on is currently being transitioned from Eclipse 3.2
>>>>>> to Eclipse 3.3. My code (which is basically straight from the
>>>>>> docs) worked flawlessly in 3.2. Unfortunately, not exactly so in 3.3:
>>>>>>
>>>>>> When generating code for the first time, it still works fine. But
>>>>>> when regenerating, the following exception occurs:
>>>>>>
>>>>>> java.lang.IllegalStateException: Workspace is closed.
>>>>>> at
>>>>>> org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
>>>>>>
>>>>>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
>>>>>> at
>>>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>>>
>>>>>>
>>>>>> So the merging with the already present code seems to require the
>>>>>> workspace?
>>>>>> This did work in 3.2, anybody know how to make it work in 3.3? I
>>>>>> wouldn't care if the already present code would be totally
>>>>>> disregarded...
>>>>>>
>>>>>> For completeness, code is below (like I said, straight from the
>>>>>> docs):
>>>>>>
>>>>>> // Globally register the default generator adapter
>>>>>> factory for GenModel
>>>>>> // elements (only needed in stand-alone).
>>>>>> //
>>>>>> GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
>>>>>> (GenModelPackage.eNS_URI,
>>>>>> GenModelGeneratorAdapterFactory.DESCRIPTOR);
>>>>>>
>>>>>>
>>>>>> Generator gen = new Generator();
>>>>>> gen.setInput(genModel);
>>>>>> gen.generate(
>>>>>> genModel,
>>>>>> GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
>>>>>> new BasicMonitor.Printing(System.out));
>>>>>>
>>>>>>
>>>>>
>>>>>
>>
|
|
|
| Re: Exception when regenerating code in standalone mode [message #416326 is a reply to message #416324] |
Mon, 28 January 2008 11:21 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Conrad,
I notice that merging will be done only if there is a facade help:
JControlModel jControlModel = getGenerator().getJControlModel();
boolean mergeSuccessful = jControlModel.canMerge();
So likely by setting a bad facade helper (or perhaps omit it) you could
disable merging, which sounds like what you really want.
More comments below.
Conrad Hoffmann wrote:
> Ed Merks schrieb:
>> Conrad,
>>
>> I was just chatting with Marcelo and he explained that JDOM can't
>> work stand alone and never did. You must not have been doing merging
>> before. Is that right?
>
> Well, technically. In 3.2, when I regenerated the code, everything got
> overwritten. There was no merging of user comments or non model
> methods. But that's basically all I want: just to overwrite the old
> stuff.
Yes, so it wasn't using JDOM or doing any kind of merge.
>
> Also, the process never even gets to any actual merging. Using the
> JDOM helper in latest 3.4 build still gives the same error, and I
> really think it just needs an additional null check:
>
> [JDOMFacadeHelper:94]
> public JCompilationUnit createCompilationUnit(String name, String
> contents)
> {
> String sourceCompatibility =
> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
> if ("1.4".compareTo(sourceCompatibility) < 0)
> {
> ....
> }
> else
> {
> sourceCompatibility = null;
> }
>
Marcelo claims the JDOM classes can't function so this problem just
masks the next one...
> The compareTo throws the NullPointerException, but since for the rest
> of the method null is an expected value for sourceCompatibility
> (because of the else block), just checking for null before comparing
> should be an adequate solution?
The documentation definitely says it will throw a null pointer exception
so a null pointer test would be needed, but as I said, Marcelo claims it
won't work downstream anyway...
>
> As for the AST helper, the problem is that
> JavaCore.getDefaultOptions() will call
> ResourcePlugin.getPlugin().getXYZ(), but ResourcePlugin.getPlugin() is
> null for me. I don't see how this is supposed to work stand alone,
> unless I just totally missed how one is supposed to initialize things
> when running in standalone mode. also, we are not talking headless
> eclipse app here, are we?
It looks like this for me right now so I assume it would return an empty
map:
public Hashtable getOptions() {
// return cached options if already computed
if (this.optionsCache != null) return new
Hashtable(this.optionsCache);
if (!Platform.isRunning()) {
return this.optionsCache = getDefaultOptionsNoInitialization();
}
>
>> Conrad Hoffmann wrote:
>>> Hi Ed,
>>>
>>> please see below.
>>>
>>> Ed Merks schrieb:
>>>> Conrad,
>>>>
>>>> Comments below.
>>>>
>>>> Conrad Hoffmann wrote:
>>>>> Ed,
>>>>>
>>>>> thanks for the hint, I really thought that might be it, but
>>>>> unfortunately not...
>>>>>
>>>>> When using the JDOMFacadeHelper in 3.3, I get this:
>>>>> java.lang.NullPointerException
>>>>> at java.lang.String.compareTo(Unknown Source)
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per.createCompilationUnit(JDOMFacadeHelper.java:97)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>>
>>>>>
>>>>> which originates here in JDOMFacadeHelper:
>>>>> String sourceCompatibility =
>>>>> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
>>>>> if ("1.4".compareTo(sourceCompatibility) < 0) // <---
>>>>> so JavaCore.getOption() returns null? I don't quite get it...
>>>> I suppose that when it's not able to get options it returns null.
>>>> Is null less that all strings?
>>>
>>> no, that's what actually throws the NullPointerException.
>>> I didn't think about it first, but it does make sense that the
>>> options are unavailable in a non-Eclipse environment. So maybe this
>>> should be guarded too?
>>>
>>>>> Anyways, I though I'd give the ASTFacadeHelper in 3.4 a shot. The
>>>>> latest build does sometimes go fishin' on me, so I don't know if
>>>>> errors should taken as 'might happen', but mostly it does work
>>>>> fine, and while the original exception is gone, i have a new one
>>>>> in the exact same place under the exact same preconditions:
>>>>> java.lang.NullPointerException
>>>>> at
>>>>> org.eclipse.core.resources.ResourcesPlugin.getEncoding(Resou rcesPlugin.java:301)
>>>>>
>>>>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2921 )
>>>> I suspect it's not all properly guarded... :-( I didn't continue
>>>> to test after the fix they provided....
>>>>> at
>>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1688)
>>>>>
>>>>> at
>>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2900)
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>
>>>>>
>>>>> which boils down to this here failing:
>>>>> String enc =
>>>>> getPlugin().getPluginPreferences().getString(PREF_ENCODING);
>>>>>
>>>>> Now, I am beginning to fear that there is a ISO Layer 8 problem
>>>>> here somewhere, by which I mean myself.
>>>> Well, it's nice you are self deprecating, but that's not so clear.
>>>>> I have 3.2 and 3.3 running in a 32bit VM and 3.4 in a 64bit VM,
>>>>> so I have quite a mixture of working environments and VMs here. If
>>>>> you so much as suspect that I screwed up an install or something,
>>>>> let me know. Although on the other hand, everything else does work
>>>>> fine so far... :/
>>>> We don't have such good tests for the standalone stuff with respect
>>>> to code generation.
>>>>>
>>>>> If you have any more ideas, please let me know.
>>>> Probably we need to try to reproduce this locally. But how best to
>>>> do that?
>>>
>>> I packed up an example project, which generates a genmodel for the
>>> well-known extlibrary.ecore and the Java code respectively. With it,
>>> one can conviently reproduce the error (at least I can, in 3.3, not
>>> so in 3.2). Now, I hope the code is not too horrible, but there is
>>> just very little documentation regarding stand-alone model/code
>>> generation...
>>>
>>> The following oddities can be reproduced with that project:
>>>
>>> 1) The Exception I originally descried: regenerating in stand-alone
>>> mode will fail when trying to merge code (both facade halpers)
>>>
>>> 2) The generated genmodel does look a little odd itself. E.g.
>>> <genClasses>
>>> <ecoreClass href="extlibrary.ecore#//Book"/>
>>> ...
>>> </genClasses>
>>> instead of:
>>> <genClasses ecoreClass="extlibrary.ecore#//Book"
>>> labelFeature="#//extlibrary/Book/title">
>>> ....
>>> </genClasses>
>>> But the Genmodel editor doesnt complain, so...?
>>> But also see next point:
>>>
>>> 3) When using the generated genmodel to generate Java code via the
>>> Genmodel Editor (right click, Generate model code), the code
>>> generation will not complain, but, if there was aleady present code,
>>> generate strange duplicate things, i.e. invalid code like this:
>>> public void setTitle(String newTitle newTitle)
>>> This also does not happen in 3.2 though, so my guess is it also does
>>> relate to the merging process?
>>>
>>> I would really like this to work, and I would be willing to put some
>>> effort into fixing things, if this is required and/or possible.
>>> But maybe the generation code is just flat out wrong?
>>> I secretly hope you have some ideas already ;)
>>>
>>> I'll be gone for the weekend now, so I wish you a nice one, too.
>>>
>>>>> Thanks a lot!
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Conrad,
>>>>>>
>>>>>> That sounds like
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807 but this was
>>>>>> fixed in 3.4 not in 3.3.
>>>>>>
>>>>>> One of the Generator.Options is
>>>>>>
>>>>>> /**
>>>>>> * The name of the {@link
>>>>>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper facade
>>>>>> helper} class to be used in
>>>>>> * Java merging.
>>>>>> * @see
>>>>>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper
>>>>>> */
>>>>>> public String mergerFacadeHelperClass;
>>>>>>
>>>>>> You could use that to specify
>>>>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per
>>>>>> which was the default in 3.2 but now the AST facade is the default.
>>>>>>
>>>>>> So probably gen.getOptions().mergerFacadeHelperClass =
>>>>>> " org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per "
>>>>>> will make it work as before.
>>>>>>
>>>>>>
>>>>>> Conrad Hoffmann wrote:
>>>>>>> Hi all.
>>>>>>>
>>>>>>> I am doing code generation from models in a standalone app. The
>>>>>>> project I work on is currently being transitioned from Eclipse
>>>>>>> 3.2 to Eclipse 3.3. My code (which is basically straight from
>>>>>>> the docs) worked flawlessly in 3.2. Unfortunately, not exactly
>>>>>>> so in 3.3:
>>>>>>>
>>>>>>> When generating code for the first time, it still works fine.
>>>>>>> But when regenerating, the following exception occurs:
>>>>>>>
>>>>>>> java.lang.IllegalStateException: Workspace is closed.
>>>>>>> at
>>>>>>> org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
>>>>>>> at
>>>>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>>>>
>>>>>>>
>>>>>>> So the merging with the already present code seems to require
>>>>>>> the workspace?
>>>>>>> This did work in 3.2, anybody know how to make it work in 3.3? I
>>>>>>> wouldn't care if the already present code would be totally
>>>>>>> disregarded...
>>>>>>>
>>>>>>> For completeness, code is below (like I said, straight from the
>>>>>>> docs):
>>>>>>>
>>>>>>> // Globally register the default generator adapter
>>>>>>> factory for GenModel
>>>>>>> // elements (only needed in stand-alone).
>>>>>>> //
>>>>>>> GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
>>>>>>> (GenModelPackage.eNS_URI,
>>>>>>> GenModelGeneratorAdapterFactory.DESCRIPTOR);
>>>>>>>
>>>>>>>
>>>>>>> Generator gen = new Generator();
>>>>>>> gen.setInput(genModel);
>>>>>>> gen.generate(
>>>>>>> genModel,
>>>>>>> GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
>>>>>>> new BasicMonitor.Printing(System.out));
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Exception when regenerating code in standalone mode [message #416335 is a reply to message #416326] |
Mon, 28 January 2008 16:33 |
Conrad Hoffmann
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
Ed Merks schrieb:
> Conrad,
>
> I notice that merging will be done only if there is a facade help:
>
> JControlModel jControlModel =
> getGenerator().getJControlModel(); boolean mergeSuccessful =
> jControlModel.canMerge();
>
> So likely by setting a bad facade helper (or perhaps omit it) you could
> disable merging, which sounds like what you really want.
Yes! Oh Joy! Setting a nonexistant facade helper will do. Thanks a
million. I did actually check what 3.2 was using, and it did say
JDOMFacadeHelper (w/o me setting anything), so I wonder, but for all I
care I am satisfied now :)
One last comment on the AST helper below, though.
> More comments below.
>
>
> Conrad Hoffmann wrote:
>> Ed Merks schrieb:
>>> Conrad,
>>>
>>> I was just chatting with Marcelo and he explained that JDOM can't
>>> work stand alone and never did. You must not have been doing merging
>>> before. Is that right?
>>
>> Well, technically. In 3.2, when I regenerated the code, everything got
>> overwritten. There was no merging of user comments or non model
>> methods. But that's basically all I want: just to overwrite the old
>> stuff.
> Yes, so it wasn't using JDOM or doing any kind of merge.
>>
>> Also, the process never even gets to any actual merging. Using the
>> JDOM helper in latest 3.4 build still gives the same error, and I
>> really think it just needs an additional null check:
>>
>> [JDOMFacadeHelper:94]
>> public JCompilationUnit createCompilationUnit(String name, String
>> contents)
>> {
>> String sourceCompatibility =
>> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
>> if ("1.4".compareTo(sourceCompatibility) < 0)
>> {
>> ....
>> }
>> else
>> {
>> sourceCompatibility = null;
>> }
>>
> Marcelo claims the JDOM classes can't function so this problem just
> masks the next one...
>> The compareTo throws the NullPointerException, but since for the rest
>> of the method null is an expected value for sourceCompatibility
>> (because of the else block), just checking for null before comparing
>> should be an adequate solution?
> The documentation definitely says it will throw a null pointer exception
> so a null pointer test would be needed, but as I said, Marcelo claims it
> won't work downstream anyway...
>>
>> As for the AST helper, the problem is that
>> JavaCore.getDefaultOptions() will call
>> ResourcePlugin.getPlugin().getXYZ(), but ResourcePlugin.getPlugin() is
>> null for me. I don't see how this is supposed to work stand alone,
>> unless I just totally missed how one is supposed to initialize things
>> when running in standalone mode. also, we are not talking headless
>> eclipse app here, are we?
> It looks like this for me right now so I assume it would return an empty
> map:
>
> public Hashtable getOptions() {
>
> // return cached options if already computed
> if (this.optionsCache != null) return new
> Hashtable(this.optionsCache);
>
> if (!Platform.isRunning()) {
> return this.optionsCache = getDefaultOptionsNoInitialization();
> }
This is JModelManager.getOptions(), I meant get_Default_Options(), which
is called (indirectly) by ASTFacadeHelper.getDefaultJavaCoreOptions().
My guess is, if getOptions does have a Platform.isRunning() clause, so
should getDefaultOptions. Actually, it is only one line in
getDefaultOptions that needs to be guarded:
1782: // get encoding through resource plugin
1783: options.put(JavaCore.CORE_ENCODING, JavaCore.getEncoding());
Either by Platform.isRunning() (sufficient?) or by
ResourcesPlugin.getPlugin() != null or also maybe just a check in
ResourcesPlugin.getEncoding() if the plugin is actually initialized. The
latter might do well because it sometimes just returns the file.encoding
system property anyways, so I think that's what should happen in this
situation, too.
Anyways, thanks again for your patience!
>>> Conrad Hoffmann wrote:
>>>> Hi Ed,
>>>>
>>>> please see below.
>>>>
>>>> Ed Merks schrieb:
>>>>> Conrad,
>>>>>
>>>>> Comments below.
>>>>>
>>>>> Conrad Hoffmann wrote:
>>>>>> Ed,
>>>>>>
>>>>>> thanks for the hint, I really thought that might be it, but
>>>>>> unfortunately not...
>>>>>>
>>>>>> When using the JDOMFacadeHelper in 3.3, I get this:
>>>>>> java.lang.NullPointerException
>>>>>> at java.lang.String.compareTo(Unknown Source)
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per.createCompilationUnit(JDOMFacadeHelper.java:97)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>>>
>>>>>>
>>>>>> which originates here in JDOMFacadeHelper:
>>>>>> String sourceCompatibility =
>>>>>> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
>>>>>> if ("1.4".compareTo(sourceCompatibility) < 0) // <---
>>>>>> so JavaCore.getOption() returns null? I don't quite get it...
>>>>> I suppose that when it's not able to get options it returns null.
>>>>> Is null less that all strings?
>>>>
>>>> no, that's what actually throws the NullPointerException.
>>>> I didn't think about it first, but it does make sense that the
>>>> options are unavailable in a non-Eclipse environment. So maybe this
>>>> should be guarded too?
>>>>
>>>>>> Anyways, I though I'd give the ASTFacadeHelper in 3.4 a shot. The
>>>>>> latest build does sometimes go fishin' on me, so I don't know if
>>>>>> errors should taken as 'might happen', but mostly it does work
>>>>>> fine, and while the original exception is gone, i have a new one
>>>>>> in the exact same place under the exact same preconditions:
>>>>>> java.lang.NullPointerException
>>>>>> at
>>>>>> org.eclipse.core.resources.ResourcesPlugin.getEncoding(Resou rcesPlugin.java:301)
>>>>>>
>>>>>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2921 )
>>>>> I suspect it's not all properly guarded... :-( I didn't continue
>>>>> to test after the fix they provided....
>>>>>> at
>>>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1688)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2900)
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>>
>>>>>>
>>>>>> which boils down to this here failing:
>>>>>> String enc =
>>>>>> getPlugin().getPluginPreferences().getString(PREF_ENCODING);
>>>>>>
>>>>>> Now, I am beginning to fear that there is a ISO Layer 8 problem
>>>>>> here somewhere, by which I mean myself.
>>>>> Well, it's nice you are self deprecating, but that's not so clear.
>>>>>> I have 3.2 and 3.3 running in a 32bit VM and 3.4 in a 64bit VM,
>>>>>> so I have quite a mixture of working environments and VMs here. If
>>>>>> you so much as suspect that I screwed up an install or something,
>>>>>> let me know. Although on the other hand, everything else does work
>>>>>> fine so far... :/
>>>>> We don't have such good tests for the standalone stuff with respect
>>>>> to code generation.
>>>>>>
>>>>>> If you have any more ideas, please let me know.
>>>>> Probably we need to try to reproduce this locally. But how best to
>>>>> do that?
>>>>
>>>> I packed up an example project, which generates a genmodel for the
>>>> well-known extlibrary.ecore and the Java code respectively. With it,
>>>> one can conviently reproduce the error (at least I can, in 3.3, not
>>>> so in 3.2). Now, I hope the code is not too horrible, but there is
>>>> just very little documentation regarding stand-alone model/code
>>>> generation...
>>>>
>>>> The following oddities can be reproduced with that project:
>>>>
>>>> 1) The Exception I originally descried: regenerating in stand-alone
>>>> mode will fail when trying to merge code (both facade halpers)
>>>>
>>>> 2) The generated genmodel does look a little odd itself. E.g.
>>>> <genClasses>
>>>> <ecoreClass href="extlibrary.ecore#//Book"/>
>>>> ...
>>>> </genClasses>
>>>> instead of:
>>>> <genClasses ecoreClass="extlibrary.ecore#//Book"
>>>> labelFeature="#//extlibrary/Book/title">
>>>> ....
>>>> </genClasses>
>>>> But the Genmodel editor doesnt complain, so...?
>>>> But also see next point:
>>>>
>>>> 3) When using the generated genmodel to generate Java code via the
>>>> Genmodel Editor (right click, Generate model code), the code
>>>> generation will not complain, but, if there was aleady present code,
>>>> generate strange duplicate things, i.e. invalid code like this:
>>>> public void setTitle(String newTitle newTitle)
>>>> This also does not happen in 3.2 though, so my guess is it also does
>>>> relate to the merging process?
>>>>
>>>> I would really like this to work, and I would be willing to put some
>>>> effort into fixing things, if this is required and/or possible.
>>>> But maybe the generation code is just flat out wrong?
>>>> I secretly hope you have some ideas already ;)
>>>>
>>>> I'll be gone for the weekend now, so I wish you a nice one, too.
>>>>
>>>>>> Thanks a lot!
>>>>>>
>>>>>> Ed Merks schrieb:
>>>>>>> Conrad,
>>>>>>>
>>>>>>> That sounds like
>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807 but this was
>>>>>>> fixed in 3.4 not in 3.3.
>>>>>>>
>>>>>>> One of the Generator.Options is
>>>>>>>
>>>>>>> /**
>>>>>>> * The name of the {@link
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper facade
>>>>>>> helper} class to be used in
>>>>>>> * Java merging.
>>>>>>> * @see
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper
>>>>>>> */
>>>>>>> public String mergerFacadeHelperClass;
>>>>>>>
>>>>>>> You could use that to specify
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per
>>>>>>> which was the default in 3.2 but now the AST facade is the default.
>>>>>>>
>>>>>>> So probably gen.getOptions().mergerFacadeHelperClass =
>>>>>>> " org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per "
>>>>>>> will make it work as before.
>>>>>>>
>>>>>>>
>>>>>>> Conrad Hoffmann wrote:
>>>>>>>> Hi all.
>>>>>>>>
>>>>>>>> I am doing code generation from models in a standalone app. The
>>>>>>>> project I work on is currently being transitioned from Eclipse
>>>>>>>> 3.2 to Eclipse 3.3. My code (which is basically straight from
>>>>>>>> the docs) worked flawlessly in 3.2. Unfortunately, not exactly
>>>>>>>> so in 3.3:
>>>>>>>>
>>>>>>>> When generating code for the first time, it still works fine.
>>>>>>>> But when regenerating, the following exception occurs:
>>>>>>>>
>>>>>>>> java.lang.IllegalStateException: Workspace is closed.
>>>>>>>> at
>>>>>>>> org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
>>>>>>>> at
>>>>>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>>>>>
>>>>>>>>
>>>>>>>> So the merging with the already present code seems to require
>>>>>>>> the workspace?
>>>>>>>> This did work in 3.2, anybody know how to make it work in 3.3? I
>>>>>>>> wouldn't care if the already present code would be totally
>>>>>>>> disregarded...
>>>>>>>>
>>>>>>>> For completeness, code is below (like I said, straight from the
>>>>>>>> docs):
>>>>>>>>
>>>>>>>> // Globally register the default generator adapter
>>>>>>>> factory for GenModel
>>>>>>>> // elements (only needed in stand-alone).
>>>>>>>> //
>>>>>>>> GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
>>>>>>>> (GenModelPackage.eNS_URI,
>>>>>>>> GenModelGeneratorAdapterFactory.DESCRIPTOR);
>>>>>>>>
>>>>>>>>
>>>>>>>> Generator gen = new Generator();
>>>>>>>> gen.setInput(genModel);
>>>>>>>> gen.generate(
>>>>>>>> genModel,
>>>>>>>> GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
>>>>>>>> new BasicMonitor.Printing(System.out));
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
|
|
|
| Re: Exception when regenerating code in standalone mode [message #416346 is a reply to message #416335] |
Mon, 28 January 2008 21:08 |
Marcelo Paternostro
Messages: 602
Registered: July 2009 |
Senior Member |
|
|
Hi Conrad,
I am glad you were able to move on with the tips Ed gave you. I've
looked into the code and I saw a few possible improvements that we could
do to make things a bit more smooth. I've opened the following bugzilla
to keep track of this issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=216821
There is also a small change that has to made on JDT:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=216817
Cheers,
Marcelo
Conrad Hoffmann wrote:
> Ed Merks schrieb:
>> Conrad,
>>
>> I notice that merging will be done only if there is a facade help:
>>
>> JControlModel jControlModel =
>> getGenerator().getJControlModel(); boolean mergeSuccessful =
>> jControlModel.canMerge();
>>
>> So likely by setting a bad facade helper (or perhaps omit it) you
>> could disable merging, which sounds like what you really want.
>
> Yes! Oh Joy! Setting a nonexistant facade helper will do. Thanks a
> million. I did actually check what 3.2 was using, and it did say
> JDOMFacadeHelper (w/o me setting anything), so I wonder, but for all I
> care I am satisfied now :)
>
> One last comment on the AST helper below, though.
>
>> More comments below.
>>
>>
>> Conrad Hoffmann wrote:
>>> Ed Merks schrieb:
>>>> Conrad,
>>>>
>>>> I was just chatting with Marcelo and he explained that JDOM can't
>>>> work stand alone and never did. You must not have been doing
>>>> merging before. Is that right?
>>>
>>> Well, technically. In 3.2, when I regenerated the code, everything
>>> got overwritten. There was no merging of user comments or non model
>>> methods. But that's basically all I want: just to overwrite the old
>>> stuff.
>> Yes, so it wasn't using JDOM or doing any kind of merge.
>>>
>>> Also, the process never even gets to any actual merging. Using the
>>> JDOM helper in latest 3.4 build still gives the same error, and I
>>> really think it just needs an additional null check:
>>>
>>> [JDOMFacadeHelper:94]
>>> public JCompilationUnit createCompilationUnit(String name, String
>>> contents)
>>> {
>>> String sourceCompatibility =
>>> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
>>> if ("1.4".compareTo(sourceCompatibility) < 0)
>>> {
>>> ....
>>> }
>>> else
>>> {
>>> sourceCompatibility = null;
>>> }
>>>
>> Marcelo claims the JDOM classes can't function so this problem just
>> masks the next one...
>>> The compareTo throws the NullPointerException, but since for the rest
>>> of the method null is an expected value for sourceCompatibility
>>> (because of the else block), just checking for null before comparing
>>> should be an adequate solution?
>> The documentation definitely says it will throw a null pointer
>> exception so a null pointer test would be needed, but as I said,
>> Marcelo claims it won't work downstream anyway...
>>>
>>> As for the AST helper, the problem is that
>>> JavaCore.getDefaultOptions() will call
>>> ResourcePlugin.getPlugin().getXYZ(), but ResourcePlugin.getPlugin()
>>> is null for me. I don't see how this is supposed to work stand alone,
>>> unless I just totally missed how one is supposed to initialize things
>>> when running in standalone mode. also, we are not talking headless
>>> eclipse app here, are we?
>> It looks like this for me right now so I assume it would return an
>> empty map:
>>
>> public Hashtable getOptions() {
>>
>> // return cached options if already computed
>> if (this.optionsCache != null) return new
>> Hashtable(this.optionsCache);
>>
>> if (!Platform.isRunning()) {
>> return this.optionsCache =
>> getDefaultOptionsNoInitialization();
>> }
>
> This is JModelManager.getOptions(), I meant get_Default_Options(), which
> is called (indirectly) by ASTFacadeHelper.getDefaultJavaCoreOptions().
> My guess is, if getOptions does have a Platform.isRunning() clause, so
> should getDefaultOptions. Actually, it is only one line in
> getDefaultOptions that needs to be guarded:
>
> 1782: // get encoding through resource plugin
> 1783: options.put(JavaCore.CORE_ENCODING, JavaCore.getEncoding());
>
> Either by Platform.isRunning() (sufficient?) or by
> ResourcesPlugin.getPlugin() != null or also maybe just a check in
> ResourcesPlugin.getEncoding() if the plugin is actually initialized. The
> latter might do well because it sometimes just returns the file.encoding
> system property anyways, so I think that's what should happen in this
> situation, too.
>
> Anyways, thanks again for your patience!
>
>>>> Conrad Hoffmann wrote:
>>>>> Hi Ed,
>>>>>
>>>>> please see below.
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Conrad,
>>>>>>
>>>>>> Comments below.
>>>>>>
>>>>>> Conrad Hoffmann wrote:
>>>>>>> Ed,
>>>>>>>
>>>>>>> thanks for the hint, I really thought that might be it, but
>>>>>>> unfortunately not...
>>>>>>>
>>>>>>> When using the JDOMFacadeHelper in 3.3, I get this:
>>>>>>> java.lang.NullPointerException
>>>>>>> at java.lang.String.compareTo(Unknown Source)
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per.createCompilationUnit(JDOMFacadeHelper.java:97)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>>>>
>>>>>>>
>>>>>>> which originates here in JDOMFacadeHelper:
>>>>>>> String sourceCompatibility =
>>>>>>> JavaCore.getOption(JavaCore.COMPILER_SOURCE);
>>>>>>> if ("1.4".compareTo(sourceCompatibility) < 0) // <---
>>>>>>> so JavaCore.getOption() returns null? I don't quite get it...
>>>>>> I suppose that when it's not able to get options it returns null.
>>>>>> Is null less that all strings?
>>>>>
>>>>> no, that's what actually throws the NullPointerException.
>>>>> I didn't think about it first, but it does make sense that the
>>>>> options are unavailable in a non-Eclipse environment. So maybe this
>>>>> should be guarded too?
>>>>>
>>>>>>> Anyways, I though I'd give the ASTFacadeHelper in 3.4 a shot. The
>>>>>>> latest build does sometimes go fishin' on me, so I don't know if
>>>>>>> errors should taken as 'might happen', but mostly it does work
>>>>>>> fine, and while the original exception is gone, i have a new one
>>>>>>> in the exact same place under the exact same preconditions:
>>>>>>> java.lang.NullPointerException
>>>>>>> at
>>>>>>> org.eclipse.core.resources.ResourcesPlugin.getEncoding(Resou rcesPlugin.java:301)
>>>>>>>
>>>>>>> at org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2921 )
>>>>>> I suspect it's not all properly guarded... :-( I didn't continue
>>>>>> to test after the fix they provided....
>>>>>>> at
>>>>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1688)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2900)
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>>>
>>>>>>>
>>>>>>> which boils down to this here failing:
>>>>>>> String enc =
>>>>>>> getPlugin().getPluginPreferences().getString(PREF_ENCODING);
>>>>>>>
>>>>>>> Now, I am beginning to fear that there is a ISO Layer 8 problem
>>>>>>> here somewhere, by which I mean myself.
>>>>>> Well, it's nice you are self deprecating, but that's not so clear.
>>>>>>> I have 3.2 and 3.3 running in a 32bit VM and 3.4 in a 64bit VM,
>>>>>>> so I have quite a mixture of working environments and VMs here.
>>>>>>> If you so much as suspect that I screwed up an install or
>>>>>>> something, let me know. Although on the other hand, everything
>>>>>>> else does work fine so far... :/
>>>>>> We don't have such good tests for the standalone stuff with
>>>>>> respect to code generation.
>>>>>>>
>>>>>>> If you have any more ideas, please let me know.
>>>>>> Probably we need to try to reproduce this locally. But how best
>>>>>> to do that?
>>>>>
>>>>> I packed up an example project, which generates a genmodel for the
>>>>> well-known extlibrary.ecore and the Java code respectively. With
>>>>> it, one can conviently reproduce the error (at least I can, in 3.3,
>>>>> not so in 3.2). Now, I hope the code is not too horrible, but there
>>>>> is just very little documentation regarding stand-alone model/code
>>>>> generation...
>>>>>
>>>>> The following oddities can be reproduced with that project:
>>>>>
>>>>> 1) The Exception I originally descried: regenerating in stand-alone
>>>>> mode will fail when trying to merge code (both facade halpers)
>>>>>
>>>>> 2) The generated genmodel does look a little odd itself. E.g.
>>>>> <genClasses>
>>>>> <ecoreClass href="extlibrary.ecore#//Book"/>
>>>>> ...
>>>>> </genClasses>
>>>>> instead of:
>>>>> <genClasses ecoreClass="extlibrary.ecore#//Book"
>>>>> labelFeature="#//extlibrary/Book/title">
>>>>> ....
>>>>> </genClasses>
>>>>> But the Genmodel editor doesnt complain, so...?
>>>>> But also see next point:
>>>>>
>>>>> 3) When using the generated genmodel to generate Java code via the
>>>>> Genmodel Editor (right click, Generate model code), the code
>>>>> generation will not complain, but, if there was aleady present
>>>>> code, generate strange duplicate things, i.e. invalid code like this:
>>>>> public void setTitle(String newTitle newTitle)
>>>>> This also does not happen in 3.2 though, so my guess is it also
>>>>> does relate to the merging process?
>>>>>
>>>>> I would really like this to work, and I would be willing to put
>>>>> some effort into fixing things, if this is required and/or possible.
>>>>> But maybe the generation code is just flat out wrong?
>>>>> I secretly hope you have some ideas already ;)
>>>>>
>>>>> I'll be gone for the weekend now, so I wish you a nice one, too.
>>>>>
>>>>>>> Thanks a lot!
>>>>>>>
>>>>>>> Ed Merks schrieb:
>>>>>>>> Conrad,
>>>>>>>>
>>>>>>>> That sounds like
>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=208807 but this
>>>>>>>> was fixed in 3.4 not in 3.3.
>>>>>>>>
>>>>>>>> One of the Generator.Options is
>>>>>>>>
>>>>>>>> /**
>>>>>>>> * The name of the {@link
>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper facade
>>>>>>>> helper} class to be used in
>>>>>>>> * Java merging.
>>>>>>>> * @see
>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.FacadeHelper
>>>>>>>> */
>>>>>>>> public String mergerFacadeHelperClass;
>>>>>>>>
>>>>>>>> You could use that to specify
>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per
>>>>>>>> which was the default in 3.2 but now the AST facade is the default.
>>>>>>>>
>>>>>>>> So probably gen.getOptions().mergerFacadeHelperClass =
>>>>>>>> " org.eclipse.emf.codegen.merge.java.facade.jdom.JDOMFacadeHel per "
>>>>>>>> will make it work as before.
>>>>>>>>
>>>>>>>>
>>>>>>>> Conrad Hoffmann wrote:
>>>>>>>>> Hi all.
>>>>>>>>>
>>>>>>>>> I am doing code generation from models in a standalone app. The
>>>>>>>>> project I work on is currently being transitioned from Eclipse
>>>>>>>>> 3.2 to Eclipse 3.3. My code (which is basically straight from
>>>>>>>>> the docs) worked flawlessly in 3.2. Unfortunately, not exactly
>>>>>>>>> so in 3.3:
>>>>>>>>>
>>>>>>>>> When generating code for the first time, it still works fine.
>>>>>>>>> But when regenerating, the following exception occurs:
>>>>>>>>>
>>>>>>>>> java.lang.IllegalStateException: Workspace is closed.
>>>>>>>>> at
>>>>>>>>> org.eclipse.core.resources.ResourcesPlugin.getWorkspace(Reso urcesPlugin.java:326)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765 )
>>>>>>>>> at
>>>>>>>>> org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOpt ions(JavaModelManager.java:1605)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.jav a:2752)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.getJavaCoreOptions(ASTFacadeHelper.java:358)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createASTParser(ASTFacadeHelper.java:251)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:263)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelpe r.createCompilationUnit(ASTFacadeHelper.java:1)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.merge.java.JMerger.createCompilation UnitForContents(JMerger.java:382)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generateJava(AbstractGeneratorAdapter.java:985)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generatePackageInterface(GenPackageGenerator Adapter.java:371)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageG eneratorAdapter.generateModel(GenPackageGeneratorAdapter.jav a:211)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGene ratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAda pter.generate(AbstractGeneratorAdapter.java:290)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:617)
>>>>>>>>>
>>>>>>>>> at
>>>>>>>>> org.eclipse.emf.codegen.ecore.generator.Generator.generate(G enerator.java:528)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So the merging with the already present code seems to require
>>>>>>>>> the workspace?
>>>>>>>>> This did work in 3.2, anybody know how to make it work in 3.3?
>>>>>>>>> I wouldn't care if the already present code would be totally
>>>>>>>>> disregarded...
>>>>>>>>>
>>>>>>>>> For completeness, code is below (like I said, straight from the
>>>>>>>>> docs):
>>>>>>>>>
>>>>>>>>> // Globally register the default generator adapter
>>>>>>>>> factory for GenModel
>>>>>>>>> // elements (only needed in stand-alone).
>>>>>>>>> //
>>>>>>>>> GeneratorAdapterFactory.Descriptor.Registry.INSTANCE.addDesc riptor
>>>>>>>>> (GenModelPackage.eNS_URI,
>>>>>>>>> GenModelGeneratorAdapterFactory.DESCRIPTOR);
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Generator gen = new Generator();
>>>>>>>>> gen.setInput(genModel);
>>>>>>>>> gen.generate(
>>>>>>>>> genModel,
>>>>>>>>> GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
>>>>>>>>> new BasicMonitor.Printing(System.out));
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 20:52:45 GMT 2024
Powered by FUDForum. Page generated in 0.03204 seconds |
] 
Search
Help
Register
Login
Home
