[news.eclipse.tools.emf] Re: Exception when regenerating code in standal

[Conrad Hoffmann <conrausch@xxxxxx>]

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.JDOMFacadeHelper.createCompilationUnit(JDOMFacadeHelper.java:97) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.merge.java.JMerger.createCompilationUnitForContents(JMerger.java:382) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generateJava(AbstractGeneratorAdapter.java:985) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageGeneratorAdapter.generatePackageInterface(GenPackageGeneratorAdapter.java:371) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageGeneratorAdapter.generateModel(GenPackageGeneratorAdapter.java:211) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGeneratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generate(AbstractGeneratorAdapter.java:290) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.ecore.generator.Generator.generate(Generator.java:617) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.ecore.generator.Generator.generate(Generator.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(ResourcesPlugin.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.getDefaultOptions(JavaModelManager.java:1688) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.java:2900)
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.getJavaCoreOptions(ASTFacadeHelper.java:358) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.createASTParser(ASTFacadeHelper.java:251) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.createCompilationUnit(ASTFacadeHelper.java:263) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.createCompilationUnit(ASTFacadeHelper.java:1) 
> > > > > >
> > > > > >     at 
> > > > > > org.eclipse.emf.codegen.merge.java.JMerger.createCompilationUnitForContents(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.JDOMFacadeHelper 
> > > > > > > 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.JDOMFacadeHelper" 
> > > > > > > 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(ResourcesPlugin.java:326) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.jdt.core.JavaCore.getEncoding(JavaCore.java:2765)
> > > > > > > >     at 
> > > > > > > > org.eclipse.jdt.internal.core.JavaModelManager.getDefaultOptions(JavaModelManager.java:1605) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.jdt.core.JavaCore.getDefaultOptions(JavaCore.java:2752)
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.getDefaultJavaCoreOptions(ASTFacadeHelper.java:375) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.getJavaCoreOptions(ASTFacadeHelper.java:358) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.createASTParser(ASTFacadeHelper.java:251) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.createCompilationUnit(ASTFacadeHelper.java:263) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.merge.java.facade.ast.ASTFacadeHelper.createCompilationUnit(ASTFacadeHelper.java:1) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.merge.java.JMerger.createCompilationUnitForContents(JMerger.java:382) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generateJava(AbstractGeneratorAdapter.java:985) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageGeneratorAdapter.generatePackageInterface(GenPackageGeneratorAdapter.java:371) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.ecore.genmodel.generator.GenPackageGeneratorAdapter.generateModel(GenPackageGeneratorAdapter.java:211) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.ecore.genmodel.generator.GenBaseGeneratorAdapter.doGenerate(GenBaseGeneratorAdapter.java:218) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.generate(AbstractGeneratorAdapter.java:290) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.ecore.generator.Generator.generate(Generator.java:617) 
> > > > > > > >
> > > > > > > >     at 
> > > > > > > > org.eclipse.emf.codegen.ecore.generator.Generator.generate(Generator.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.addDescriptor
> > > > > > > >              (GenModelPackage.eNS_URI, 
> > > > > > > > GenModelGeneratorAdapterFactory.DESCRIPTOR);
> > > > > > > >
> > > > > > > >
> > > > > > > >             Generator gen = new Generator();
> > > > > > > >             gen.setInput(genModel);
> > > > > > > >             gen.generate(
> > > > > > > >                     genModel,
> > > > > > > >                     GenBaseGeneratorAdapter.MODEL_PROJECT_TYPE,
> > > > > > > >                     new BasicMonitor.Printing(System.out));