Home » Modeling » EMF » Java model *in* ecore?
| |
Re: Java model *in* ecore? [message #414156 is a reply to message #414151] |
Fri, 26 October 2007 14:43 |
Marcelo Paternostro Messages: 602 Registered: July 2009 |
Senior Member |
|
|
Hi,
Actually back at the beginning of the year we changed the example to use
AST (it actually uses a set of interfaces that we created to hide the
underlying Java parsing tool). We didn't have the time to update the
model and the code to properly support Java 5, though.
So, in other words, although you won't see any Java 5 constructs in the
model, it won't throw exceptions because them.
Cheers,
Marcelo
Ed Merks wrote:
> Miles,
>
> The org.eclipse.emf.java model does that. Its part of our examples, but
> is based on JDOM so it doesn't handle Java 5.0. You'll find it in the
> team project set file I've attached.
>
>
> Miles Parker wrote:
>>
>> Just wondering if anyone haqs come across any efforts to build a
>> generic .ecore model for Java, with importers from source, natch. :)
>> Such a thing would be enormously useful for analysis and
>> transformation of existing java code..I'm not speaking of some kind of
>> deep parsing of methods of course, just down to the stubs, but
>> including modifiers, etc..
>>
>
|
|
|
Re: Java model *in* ecore? [message #414237 is a reply to message #414156] |
Fri, 26 October 2007 17:35 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
Fantastic! I couldn't figure out where/how to use a parser for existing
Java classes.. any hints there?
On 2007-10-26 07:43:13 -0700, Marcelo Paternostro <marcelop@ca.ibm.com> said:
> Hi,
>
> Actually back at the beginning of the year we changed the example to
> use AST (it actually uses a set of interfaces that we created to
> hide the underlying Java parsing tool). We didn't have the time to
> update the model and the code to properly support Java 5, though.
>
> So, in other words, although you won't see any Java 5 constructs in the
> model, it won't throw exceptions because them.
>
> Cheers,
> Marcelo
>
> Ed Merks wrote:
>> Miles,
>>
>> The org.eclipse.emf.java model does that. Its part of our examples,
>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it in
>> the team project set file I've attached.
>>
>>
>> Miles Parker wrote:
>>>
>>> Just wondering if anyone haqs come across any efforts to build a
>>> generic .ecore model for Java, with importers from source, natch. :)
>>> Such a thing would be enormously useful for analysis and transformation
>>> of existing java code..I'm not speaking of some kind of deep parsing of
>>> methods of course, just down to the stubs, but including modifiers,
>>> etc..
|
|
|
Re: Java model *in* ecore? [message #414241 is a reply to message #414237] |
Fri, 26 October 2007 17:46 |
Marcelo Paternostro Messages: 602 Registered: July 2009 |
Senior Member |
|
|
You can definitely take a pick at the example's code or at the tests we
have in org.eclipse.emf.test.tool
(/org.eclipse.emf.test.tools/src/org/eclipse/emf/test/tools/ merger/facade/FacadeTest_Example1.java
to be more precise).
I have one disclaimer though ;-) The "J" interfaces in
org.eclipse.emf.codegen.merge.java.facade (as well as the JDOM and AST
implementations) have been designed with the requirements of a merging
tool in mind. Please don't expect them to be a complete and
well-thought API to parse Java code.
Cheers,
Marcelo
Miles Parker wrote:
>
> Fantastic! I couldn't figure out where/how to use a parser for existing
> Java classes.. any hints there?
>
> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro <marcelop@ca.ibm.com>
> said:
>
>> Hi,
>>
>> Actually back at the beginning of the year we changed the example to
>> use AST (it actually uses a set of interfaces that we created to
>> hide the underlying Java parsing tool). We didn't have the time to
>> update the model and the code to properly support Java 5, though.
>>
>> So, in other words, although you won't see any Java 5 constructs in
>> the model, it won't throw exceptions because them.
>>
>> Cheers,
>> Marcelo
>>
>> Ed Merks wrote:
>>> Miles,
>>>
>>> The org.eclipse.emf.java model does that. Its part of our examples,
>>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it
>>> in the team project set file I've attached.
>>>
>>>
>>> Miles Parker wrote:
>>>>
>>>> Just wondering if anyone haqs come across any efforts to build a
>>>> generic .ecore model for Java, with importers from source, natch. :)
>>>> Such a thing would be enormously useful for analysis and
>>>> transformation of existing java code..I'm not speaking of some kind
>>>> of deep parsing of methods of course, just down to the stubs, but
>>>> including modifiers, etc..
>
>
|
|
|
Re: Java model *in* ecore? [message #414243 is a reply to message #414237] |
Fri, 26 October 2007 17:48 |
Ed Merks Messages: 33217 Registered: July 2009 |
Senior Member |
|
|
Miles,
Note that in the plugin.xml we have this:
<!--
These aren't registered to avoid collision with the Visual Editor.
<extension point = "org.eclipse.emf.ecore.extension_parser">
<parser type="java"
class="org.eclipse.emf.java.util.JavaResourceFactoryImpl"/ >
</extension>
<extension point = "org.eclipse.emf.ecore.extension_parser">
<parser type="packages"
class="org.eclipse.emf.java.util.JavaPackageResourceFactoryImpl "/>
</extension>
-->
It should be sufficient just to register the factories and create a
resource in the normal way with .java extension. In the IDE you should
be able to do "Open With->Java Model Editor"...
Miles Parker wrote:
>
> Fantastic! I couldn't figure out where/how to use a parser for
> existing Java classes.. any hints there?
>
> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro
> <marcelop@ca.ibm.com> said:
>
>> Hi,
>>
>> Actually back at the beginning of the year we changed the example to
>> use AST (it actually uses a set of interfaces that we created to
>> hide the underlying Java parsing tool). We didn't have the time to
>> update the model and the code to properly support Java 5, though.
>>
>> So, in other words, although you won't see any Java 5 constructs in
>> the model, it won't throw exceptions because them.
>>
>> Cheers,
>> Marcelo
>>
>> Ed Merks wrote:
>>> Miles,
>>>
>>> The org.eclipse.emf.java model does that. Its part of our examples,
>>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it
>>> in the team project set file I've attached.
>>>
>>>
>>> Miles Parker wrote:
>>>>
>>>> Just wondering if anyone haqs come across any efforts to build a
>>>> generic .ecore model for Java, with importers from source, natch.
>>>> :) Such a thing would be enormously useful for analysis and
>>>> transformation of existing java code..I'm not speaking of some kind
>>>> of deep parsing of methods of course, just down to the stubs, but
>>>> including modifiers, etc..
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Java model *in* ecore? [message #414246 is a reply to message #414243] |
Fri, 26 October 2007 20:11 |
Marcelo Paternostro Messages: 602 Registered: July 2009 |
Senior Member |
|
|
Hehe... I am just banging my head on the wall after reading Ed's post ;-)
So instead of assuming that I missed the point entirely, let's say that
Ed's answer is how you can use the EMF code in the example to load/save
Java files - the example has a resource implementation that reads and
writes Java. My answer is more into the "technology" that we used to
develop this resource ;-)
Cheers,
Marcelo
Ed Merks wrote:
> Miles,
>
> Note that in the plugin.xml we have this:
>
> <!--
> These aren't registered to avoid collision with the Visual Editor.
>
> <extension point = "org.eclipse.emf.ecore.extension_parser">
> <parser type="java"
> class="org.eclipse.emf.java.util.JavaResourceFactoryImpl"/ >
> </extension>
>
> <extension point = "org.eclipse.emf.ecore.extension_parser">
> <parser type="packages"
> class="org.eclipse.emf.java.util.JavaPackageResourceFactoryImpl "/>
> </extension>
> -->
>
> It should be sufficient just to register the factories and create a
> resource in the normal way with .java extension. In the IDE you should
> be able to do "Open With->Java Model Editor"...
>
>
>
> Miles Parker wrote:
>>
>> Fantastic! I couldn't figure out where/how to use a parser for
>> existing Java classes.. any hints there?
>>
>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro
>> <marcelop@ca.ibm.com> said:
>>
>>> Hi,
>>>
>>> Actually back at the beginning of the year we changed the example to
>>> use AST (it actually uses a set of interfaces that we created to
>>> hide the underlying Java parsing tool). We didn't have the time to
>>> update the model and the code to properly support Java 5, though.
>>>
>>> So, in other words, although you won't see any Java 5 constructs in
>>> the model, it won't throw exceptions because them.
>>>
>>> Cheers,
>>> Marcelo
>>>
>>> Ed Merks wrote:
>>>> Miles,
>>>>
>>>> The org.eclipse.emf.java model does that. Its part of our examples,
>>>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it
>>>> in the team project set file I've attached.
>>>>
>>>>
>>>> Miles Parker wrote:
>>>>>
>>>>> Just wondering if anyone haqs come across any efforts to build a
>>>>> generic .ecore model for Java, with importers from source, natch.
>>>>> :) Such a thing would be enormously useful for analysis and
>>>>> transformation of existing java code..I'm not speaking of some kind
>>>>> of deep parsing of methods of course, just down to the stubs, but
>>>>> including modifiers, etc..
>>
>>
|
|
|
Re: Java model *in* ecore? [message #414247 is a reply to message #414246] |
Fri, 26 October 2007 20:40 |
Ed Merks Messages: 33217 Registered: July 2009 |
Senior Member |
|
|
Marcelo,
If you damage your brains, that book will never get done, so don't do
that! :-P
Marcelo Paternostro wrote:
> Hehe... I am just banging my head on the wall after reading Ed's post ;-)
>
> So instead of assuming that I missed the point entirely, let's say
> that Ed's answer is how you can use the EMF code in the example to
> load/save Java files - the example has a resource implementation that
> reads and writes Java. My answer is more into the "technology" that
> we used to develop this resource ;-)
>
> Cheers,
> Marcelo
>
> Ed Merks wrote:
>> Miles,
>>
>> Note that in the plugin.xml we have this:
>>
>> <!--
>> These aren't registered to avoid collision with the Visual Editor.
>>
>> <extension point = "org.eclipse.emf.ecore.extension_parser">
>> <parser type="java"
>> class="org.eclipse.emf.java.util.JavaResourceFactoryImpl"/ >
>> </extension>
>>
>> <extension point = "org.eclipse.emf.ecore.extension_parser">
>> <parser type="packages"
>> class="org.eclipse.emf.java.util.JavaPackageResourceFactoryImpl "/>
>> </extension>
>> -->
>>
>> It should be sufficient just to register the factories and create a
>> resource in the normal way with .java extension. In the IDE you
>> should be able to do "Open With->Java Model Editor"...
>>
>>
>>
>> Miles Parker wrote:
>>>
>>> Fantastic! I couldn't figure out where/how to use a parser for
>>> existing Java classes.. any hints there?
>>>
>>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro
>>> <marcelop@ca.ibm.com> said:
>>>
>>>> Hi,
>>>>
>>>> Actually back at the beginning of the year we changed the example
>>>> to use AST (it actually uses a set of interfaces that we created
>>>> to hide the underlying Java parsing tool). We didn't have the time
>>>> to update the model and the code to properly support Java 5, though.
>>>>
>>>> So, in other words, although you won't see any Java 5 constructs in
>>>> the model, it won't throw exceptions because them.
>>>>
>>>> Cheers,
>>>> Marcelo
>>>>
>>>> Ed Merks wrote:
>>>>> Miles,
>>>>>
>>>>> The org.eclipse.emf.java model does that. Its part of our
>>>>> examples, but is based on JDOM so it doesn't handle Java 5.0.
>>>>> You'll find it in the team project set file I've attached.
>>>>>
>>>>>
>>>>> Miles Parker wrote:
>>>>>>
>>>>>> Just wondering if anyone haqs come across any efforts to build a
>>>>>> generic .ecore model for Java, with importers from source, natch.
>>>>>> :) Such a thing would be enormously useful for analysis and
>>>>>> transformation of existing java code..I'm not speaking of some
>>>>>> kind of deep parsing of methods of course, just down to the
>>>>>> stubs, but including modifiers, etc..
>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Java model *in* ecore? [message #414248 is a reply to message #414246] |
Fri, 26 October 2007 21:08 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
Yes, you can pretty much take my questions in the simplest possible way ;).
This works perfectly.. As they are in the SDO-XSD example set I ended
up using those instead of the whole PSF build, but that was interesting
to look at anyway..
FWIW, my usage is to automagically load libraries such as
java.lang.Math, grab the metadatam, and then transform them into a
meta-fuction instances library in my own metamodel -- I then have all
of the metadata I need to reconstruct arbitrary calls on the code
generation end. whew..I appear to be one of those programmers who would
rather spend a week creating something taht can do something
'automatically' that I could do by hand in a half a day..
On 2007-10-26 13:11:45 -0700, Marcelo Paternostro <marcelop@ca.ibm.com> said:
> Hehe... I am just banging my head on the wall after reading Ed's post ;-)
>
> So instead of assuming that I missed the point entirely, let's say that
> Ed's answer is how you can use the EMF code in the example to load/save
> Java files - the example has a resource implementation that reads and
> writes Java. My answer is more into the "technology" that we used to
> develop this resource ;-)
>
> Cheers,
> Marcelo
>
> Ed Merks wrote:
>> Miles,
>>
>> Note that in the plugin.xml we have this:
>>
>> <!--
>> These aren't registered to avoid collision with the Visual Editor.
>>
>> <extension point = "org.eclipse.emf.ecore.extension_parser">
>> <parser type="java"
>> class="org.eclipse.emf.java.util.JavaResourceFactoryImpl"/ >
>> </extension>
>>
>> <extension point = "org.eclipse.emf.ecore.extension_parser">
>> <parser type="packages"
>> class="org.eclipse.emf.java.util.JavaPackageResourceFactoryImpl "/>
>> </extension>
>> -->
>>
>> It should be sufficient just to register the factories and create a
>> resource in the normal way with .java extension. In the IDE you should
>> be able to do "Open With->Java Model Editor"...
>>
>>
>>
>> Miles Parker wrote:
>>>
>>> Fantastic! I couldn't figure out where/how to use a parser for existing
>>> Java classes.. any hints there?
>>>
>>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro <marcelop@ca.ibm.com> said:
>>>
>>>> Hi,
>>>>
>>>> Actually back at the beginning of the year we changed the example to
>>>> use AST (it actually uses a set of interfaces that we created to
>>>> hide the underlying Java parsing tool). We didn't have the time to
>>>> update the model and the code to properly support Java 5, though.
>>>>
>>>> So, in other words, although you won't see any Java 5 constructs in the
>>>> model, it won't throw exceptions because them.
>>>>
>>>> Cheers,
>>>> Marcelo
>>>>
>>>> Ed Merks wrote:
>>>>> Miles,
>>>>>
>>>>> The org.eclipse.emf.java model does that. Its part of our examples,
>>>>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it in
>>>>> the team project set file I've attached.
>>>>>
>>>>>
>>>>> Miles Parker wrote:
>>>>>>
>>>>>> Just wondering if anyone haqs come across any efforts to build a
>>>>>> generic .ecore model for Java, with importers from source, natch. :)
>>>>>> Such a thing would be enormously useful for analysis and transformation
>>>>>> of existing java code..I'm not speaking of some kind of deep parsing of
>>>>>> methods of course, just down to the stubs, but including modifiers,
>>>>>> etc..
|
|
| |
Re: Java model *in* ecore? [message #414250 is a reply to message #414156] |
Fri, 26 October 2007 23:48 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
Hi Marcelo et.al.,
I am just doing a somewhat braindead thing to try to load
programmatically.. it works for some utility methods for my own ecore
models but fails here -- just wondering what I might be doing
wrong..I'm calling this from an install with ..emf.java as plugin.
This..
JavaResourceFactoryImpl resourceFactory = new
JavaResourceFactoryImpl();
Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "java",
resourceFactory);
Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "packages",
new JavaPackageResourceFactoryImpl());
ResourceSet resourceSet = new ResourceSetImpl();
JavaPackage jp = JavaPackage.eINSTANCE;
resourceSet.getLoadOptions().put(XMLResource.OPTION_DEFER_ID REF_RESOLUTION,
Boolean.TRUE);
JavaFactory jf = JavaFactory.eINSTANCE;
File f = new
File(platformPath("../org.metaabm.oaw.tools/javasrc/java/lang/Math.java "));
URI uri = URI.createFileURI(f.getCanonicalPath());
Resource resource = resourceSet.getResource(uri, true);
JClass rootClass = (JClass) resource.getEObject("/");
Gives..
Caused by: 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.java.util.JavaResourceImpl.doLoad(JavaResour ceImpl.java:52)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1155)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:256)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:271)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:398)
at
org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
On 2007-10-26 07:43:13 -0700, Marcelo Paternostro <marcelop@ca.ibm.com> said:
> Hi,
>
> Actually back at the beginning of the year we changed the example to
> use AST (it actually uses a set of interfaces that we created to
> hide the underlying Java parsing tool). We didn't have the time to
> update the model and the code to properly support Java 5, though.
>
> So, in other words, although you won't see any Java 5 constructs in the
> model, it won't throw exceptions because them.
>
> Cheers,
> Marcelo
>
> Ed Merks wrote:
>> Miles,
>>
>> The org.eclipse.emf.java model does that. Its part of our examples,
>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it in
>> the team project set file I've attached.
>>
>>
>> Miles Parker wrote:
>>>
>>> Just wondering if anyone haqs come across any efforts to build a
>>> generic .ecore model for Java, with importers from source, natch. :)
>>> Such a thing would be enormously useful for analysis and transformation
>>> of existing java code..I'm not speaking of some kind of deep parsing of
>>> methods of course, just down to the stubs, but including modifiers,
>>> etc..
|
|
|
Re: Java model *in* ecore? [message #414251 is a reply to message #414250] |
Sat, 27 October 2007 15:47 |
Ed Merks Messages: 33217 Registered: July 2009 |
Senior Member |
|
|
Miles,
You appear to be using it standalone and although JDT is supposed to
work standalone, I gather from this stack trace that asking for the
Java throws an exception. Probably we could add a guard for and I
suppose we'd have to assume Java 5.0 source. Maybe you can try hacking
the code to see how far it can get standalone...
Miles Parker wrote:
>
> Hi Marcelo et.al.,
>
> I am just doing a somewhat braindead thing to try to load
> programmatically.. it works for some utility methods for my own ecore
> models but fails here -- just wondering what I might be doing
> wrong..I'm calling this from an install with ..emf.java as plugin.
>
> This..
>
> JavaResourceFactoryImpl resourceFactory = new
> JavaResourceFactoryImpl();
>
> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "java",
> resourceFactory);
>
> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "packages",
> new JavaPackageResourceFactoryImpl());
> ResourceSet resourceSet = new ResourceSetImpl();
> JavaPackage jp = JavaPackage.eINSTANCE;
>
> resourceSet.getLoadOptions().put(XMLResource.OPTION_DEFER_ID REF_RESOLUTION,
> Boolean.TRUE);
> JavaFactory jf = JavaFactory.eINSTANCE;
>
> File f = new
> File(platformPath("../org.metaabm.oaw.tools/javasrc/java/lang/Math.java "));
>
>
>
> URI uri = URI.createFileURI(f.getCanonicalPath());
> Resource resource = resourceSet.getResource(uri, true);
> JClass rootClass = (JClass) resource.getEObject("/");
>
>
> Gives..
>
> Caused by: 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.java.util.JavaResourceImpl.doLoad(JavaResour ceImpl.java:52)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1155)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:256)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:271)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:398)
>
> at
> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>
>
>
> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro
> <marcelop@ca.ibm.com> said:
>
>> Hi,
>>
>> Actually back at the beginning of the year we changed the example to
>> use AST (it actually uses a set of interfaces that we created to
>> hide the underlying Java parsing tool). We didn't have the time to
>> update the model and the code to properly support Java 5, though.
>>
>> So, in other words, although you won't see any Java 5 constructs in
>> the model, it won't throw exceptions because them.
>>
>> Cheers,
>> Marcelo
>>
>> Ed Merks wrote:
>>> Miles,
>>>
>>> The org.eclipse.emf.java model does that. Its part of our examples,
>>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it
>>> in the team project set file I've attached.
>>>
>>>
>>> Miles Parker wrote:
>>>>
>>>> Just wondering if anyone haqs come across any efforts to build a
>>>> generic .ecore model for Java, with importers from source, natch.
>>>> :) Such a thing would be enormously useful for analysis and
>>>> transformation of existing java code..I'm not speaking of some kind
>>>> of deep parsing of methods of course, just down to the stubs, but
>>>> including modifiers, etc..
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Java model *in* ecore? [message #414252 is a reply to message #414251] |
Sat, 27 October 2007 17:40 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
Nope, I'm using it from w/in Eclipse with JDT, EMF, etc..??
btw, the XMLResource call is obviously an oversight.
On 2007-10-27 08:47:03 -0700, Ed Merks <merks@ca.ibm.com> said:
> Miles,
>
> You appear to be using it standalone and although JDT is supposed to
> work standalone, I gather from this stack trace that asking for the
> Java throws an exception. Probably we could add a guard for and I
> suppose we'd have to assume Java 5.0 source. Maybe you can try hacking
> the code to see how far it can get standalone...
>
>
> Miles Parker wrote:
>>
>> Hi Marcelo et.al.,
>>
>> I am just doing a somewhat braindead thing to try to load
>> programmatically.. it works for some utility methods for my own ecore
>> models but fails here -- just wondering what I might be doing
>> wrong..I'm calling this from an install with ..emf.java as plugin.
>>
>> This..
>>
>> JavaResourceFactoryImpl resourceFactory = new
>> JavaResourceFactoryImpl();
>>
>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "java",
>> resourceFactory);
>>
>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "packages",
>> new JavaPackageResourceFactoryImpl());
>> ResourceSet resourceSet = new ResourceSetImpl();
>> JavaPackage jp = JavaPackage.eINSTANCE;
>>
>> resourceSet.getLoadOptions().put(XMLResource.OPTION_DEFER_ID REF_RESOLUTION,
>> Boolean.TRUE);
>> JavaFactory jf = JavaFactory.eINSTANCE;
>>
>> File f = new
>> File(platformPath("../org.metaabm.oaw.tools/javasrc/java/lang/Math.java "));
>>
>> URI uri = URI.createFileURI(f.getCanonicalPath());
>> Resource resource = resourceSet.getResource(uri, true);
>> JClass rootClass = (JClass) resource.getEObject("/");
>>
>>
>> Gives..
>>
>> Caused by: 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.java.util.JavaResourceImpl.doLoad(JavaResour ceImpl.java:52)
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1155)
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:256)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:271)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:398)
>>
>> at
>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>
>>
>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro <marcelop@ca.ibm.com> said:
>>
>>> Hi,
>>>
>>> Actually back at the beginning of the year we changed the example to
>>> use AST (it actually uses a set of interfaces that we created to
>>> hide the underlying Java parsing tool). We didn't have the time to
>>> update the model and the code to properly support Java 5, though.
>>>
>>> So, in other words, although you won't see any Java 5 constructs in the
>>> model, it won't throw exceptions because them.
>>>
>>> Cheers,
>>> Marcelo
>>>
>>> Ed Merks wrote:
>>>> Miles,
>>>>
>>>> The org.eclipse.emf.java model does that. Its part of our examples,
>>>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it in
>>>> the team project set file I've attached.
>>>>
>>>>
>>>> Miles Parker wrote:
>>>>>
>>>>> Just wondering if anyone haqs come across any efforts to build a
>>>>> generic .ecore model for Java, with importers from source, natch. :)
>>>>> Such a thing would be enormously useful for analysis and transformation
>>>>> of existing java code..I'm not speaking of some kind of deep parsing of
>>>>> methods of course, just down to the stubs, but including modifiers,
>>>>> etc..
|
|
|
Re: Java model *in* ecore? [message #414253 is a reply to message #414252] |
Sat, 27 October 2007 17:47 |
Ed Merks Messages: 33217 Registered: July 2009 |
Senior Member |
|
|
Miles,
The workspace closed message seems to indicate that you don't have a
workspace though. You're sure you're running it as an Eclipse application?
Miles Parker wrote:
>
> Nope, I'm using it from w/in Eclipse with JDT, EMF, etc..??
>
> btw, the XMLResource call is obviously an oversight.
>
> On 2007-10-27 08:47:03 -0700, Ed Merks <merks@ca.ibm.com> said:
>
>> Miles,
>>
>> You appear to be using it standalone and although JDT is supposed to
>> work standalone, I gather from this stack trace that asking for the
>> Java throws an exception. Probably we could add a guard for and I
>> suppose we'd have to assume Java 5.0 source. Maybe you can try
>> hacking the code to see how far it can get standalone...
>>
>>
>> Miles Parker wrote:
>>>
>>> Hi Marcelo et.al.,
>>>
>>> I am just doing a somewhat braindead thing to try to load
>>> programmatically.. it works for some utility methods for my own
>>> ecore models but fails here -- just wondering what I might be doing
>>> wrong..I'm calling this from an install with ..emf.java as plugin.
>>>
>>> This..
>>>
>>> JavaResourceFactoryImpl resourceFactory = new
>>> JavaResourceFactoryImpl();
>>>
>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "java",
>>> resourceFactory);
>>>
>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "packages",
>>> new JavaPackageResourceFactoryImpl());
>>> ResourceSet resourceSet = new ResourceSetImpl();
>>> JavaPackage jp = JavaPackage.eINSTANCE;
>>>
>>> resourceSet.getLoadOptions().put(XMLResource.OPTION_DEFER_ID REF_RESOLUTION,
>>> Boolean.TRUE);
>>> JavaFactory jf = JavaFactory.eINSTANCE;
>>>
>>> File f = new
>>> File(platformPath("../org.metaabm.oaw.tools/javasrc/java/lang/Math.java "));
>>>
>
>
>
>>>
>>> URI uri = URI.createFileURI(f.getCanonicalPath());
>>> Resource resource = resourceSet.getResource(uri, true);
>>> JClass rootClass = (JClass) resource.getEObject("/");
>>>
>>>
>>> Gives..
>>>
>>> Caused by: 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.java.util.JavaResourceImpl.doLoad(JavaResour ceImpl.java:52)
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>>>
>
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1155)
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:256)
>>>
>
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:271)
>>>
>
>>>
>>> at
>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:398)
>>>
>
>>>
>>> at
>>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>>
>>>
>>>
>>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro
>>> <marcelop@ca.ibm.com> said:
>>>
>>>> Hi,
>>>>
>>>> Actually back at the beginning of the year we changed the example
>>>> to use AST (it actually uses a set of interfaces that we created
>>>> to hide the underlying Java parsing tool). We didn't have the time
>>>> to update the model and the code to properly support Java 5, though.
>>>>
>>>> So, in other words, although you won't see any Java 5 constructs in
>>>> the model, it won't throw exceptions because them.
>>>>
>>>> Cheers,
>>>> Marcelo
>>>>
>>>> Ed Merks wrote:
>>>>> Miles,
>>>>>
>>>>> The org.eclipse.emf.java model does that. Its part of our
>>>>> examples, but is based on JDOM so it doesn't handle Java 5.0.
>>>>> You'll find it in the team project set file I've attached.
>>>>>
>>>>>
>>>>> Miles Parker wrote:
>>>>>>
>>>>>> Just wondering if anyone haqs come across any efforts to build a
>>>>>> generic .ecore model for Java, with importers from source, natch.
>>>>>> :) Such a thing would be enormously useful for analysis and
>>>>>> transformation of existing java code..I'm not speaking of some
>>>>>> kind of deep parsing of methods of course, just down to the
>>>>>> stubs, but including modifiers, etc..
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Java model *in* ecore? [message #414254 is a reply to message #414253] |
Sat, 27 October 2007 18:50 |
Rafael Chaves Messages: 362 Registered: July 2009 |
Senior Member |
|
|
If the stack trace is complete, from the first frame you can tell he is not:
org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
Rafael
Ed Merks wrote:
> Miles,
>
> The workspace closed message seems to indicate that you don't have a
> workspace though. You're sure you're running it as an Eclipse application?
>
>
> Miles Parker wrote:
>>
>> Nope, I'm using it from w/in Eclipse with JDT, EMF, etc..??
>>
>> btw, the XMLResource call is obviously an oversight.
>>
>> On 2007-10-27 08:47:03 -0700, Ed Merks <merks@ca.ibm.com> said:
>>
>>> Miles,
>>>
>>> You appear to be using it standalone and although JDT is supposed to
>>> work standalone, I gather from this stack trace that asking for the
>>> Java throws an exception. Probably we could add a guard for and I
>>> suppose we'd have to assume Java 5.0 source. Maybe you can try
>>> hacking the code to see how far it can get standalone...
>>>
>>>
>>> Miles Parker wrote:
>>>>
>>>> Hi Marcelo et.al.,
>>>>
>>>> I am just doing a somewhat braindead thing to try to load
>>>> programmatically.. it works for some utility methods for my own
>>>> ecore models but fails here -- just wondering what I might be doing
>>>> wrong..I'm calling this from an install with ..emf.java as plugin.
>>>>
>>>> This..
>>>>
>>>> JavaResourceFactoryImpl resourceFactory = new
>>>> JavaResourceFactoryImpl();
>>>>
>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "java",
>>>> resourceFactory);
>>>>
>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "packages",
>>>> new JavaPackageResourceFactoryImpl());
>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>> JavaPackage jp = JavaPackage.eINSTANCE;
>>>>
>>>> resourceSet.getLoadOptions().put(XMLResource.OPTION_DEFER_ID REF_RESOLUTION,
>>>> Boolean.TRUE);
>>>> JavaFactory jf = JavaFactory.eINSTANCE;
>>>>
>>>> File f = new
>>>> File(platformPath("../org.metaabm.oaw.tools/javasrc/java/lang/Math.java "));
>>>>
>>
>>
>>
>>>>
>>>> URI uri = URI.createFileURI(f.getCanonicalPath());
>>>> Resource resource = resourceSet.getResource(uri, true);
>>>> JClass rootClass = (JClass) resource.getEObject("/");
>>>>
>>>>
>>>> Gives..
>>>>
>>>> Caused by: 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.java.util.JavaResourceImpl.doLoad(JavaResour ceImpl.java:52)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>>>>
>>
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1155)
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:256)
>>>>
>>
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:271)
>>>>
>>
>>>>
>>>> at
>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:398)
>>>>
>>
>>>>
>>>> at
>>>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>>>
>>>>
>>>>
>>>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro
>>>> <marcelop@ca.ibm.com> said:
>>>>
>>>>> Hi,
>>>>>
>>>>> Actually back at the beginning of the year we changed the example
>>>>> to use AST (it actually uses a set of interfaces that we created
>>>>> to hide the underlying Java parsing tool). We didn't have the time
>>>>> to update the model and the code to properly support Java 5, though.
>>>>>
>>>>> So, in other words, although you won't see any Java 5 constructs in
>>>>> the model, it won't throw exceptions because them.
>>>>>
>>>>> Cheers,
>>>>> Marcelo
>>>>>
>>>>> Ed Merks wrote:
>>>>>> Miles,
>>>>>>
>>>>>> The org.eclipse.emf.java model does that. Its part of our
>>>>>> examples, but is based on JDOM so it doesn't handle Java 5.0.
>>>>>> You'll find it in the team project set file I've attached.
>>>>>>
>>>>>>
>>>>>> Miles Parker wrote:
>>>>>>>
>>>>>>> Just wondering if anyone haqs come across any efforts to build a
>>>>>>> generic .ecore model for Java, with importers from source, natch.
>>>>>>> :) Such a thing would be enormously useful for analysis and
>>>>>>> transformation of existing java code..I'm not speaking of some
>>>>>>> kind of deep parsing of methods of course, just down to the
>>>>>>> stubs, but including modifiers, etc..
>>
>>
|
|
|
Re: Java model *in* ecore? [message #414255 is a reply to message #414254] |
Sat, 27 October 2007 19:41 |
Ed Merks Messages: 33217 Registered: July 2009 |
Senior Member |
|
|
Rafael,
That and the workspace closed message was the reason for my assumption.
Probably Miles is confusing running a Java application within Eclipse
with running as an Eclipse application. I'm not sure this stuff will
work well unless you open files within a Java project because we won't
know the class path or how to find source files in general without the
Java project information.
Rafael Chaves wrote:
> If the stack trace is complete, from the first frame you can tell he
> is not:
>
> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>
>
> Rafael
>
> Ed Merks wrote:
>> Miles,
>>
>> The workspace closed message seems to indicate that you don't have a
>> workspace though. You're sure you're running it as an Eclipse
>> application?
>>
>>
>> Miles Parker wrote:
>>>
>>> Nope, I'm using it from w/in Eclipse with JDT, EMF, etc..??
>>>
>>> btw, the XMLResource call is obviously an oversight.
>>>
>>> On 2007-10-27 08:47:03 -0700, Ed Merks <merks@ca.ibm.com> said:
>>>
>>>> Miles,
>>>>
>>>> You appear to be using it standalone and although JDT is supposed
>>>> to work standalone, I gather from this stack trace that asking for
>>>> the Java throws an exception. Probably we could add a guard for
>>>> and I suppose we'd have to assume Java 5.0 source. Maybe you can
>>>> try hacking the code to see how far it can get standalone...
>>>>
>>>>
>>>> Miles Parker wrote:
>>>>>
>>>>> Hi Marcelo et.al.,
>>>>>
>>>>> I am just doing a somewhat braindead thing to try to load
>>>>> programmatically.. it works for some utility methods for my own
>>>>> ecore models but fails here -- just wondering what I might be
>>>>> doing wrong..I'm calling this from an install with ..emf.java as
>>>>> plugin.
>>>>>
>>>>> This..
>>>>>
>>>>> JavaResourceFactoryImpl resourceFactory = new
>>>>> JavaResourceFactoryImpl();
>>>>>
>>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "java",
>>>>> resourceFactory);
>>>>>
>>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "packages",
>>>>> new JavaPackageResourceFactoryImpl());
>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>> JavaPackage jp = JavaPackage.eINSTANCE;
>>>>>
>>>>> resourceSet.getLoadOptions().put(XMLResource.OPTION_DEFER_ID REF_RESOLUTION,
>>>>> Boolean.TRUE);
>>>>> JavaFactory jf = JavaFactory.eINSTANCE;
>>>>>
>>>>> File f = new
>>>>> File(platformPath("../org.metaabm.oaw.tools/javasrc/java/lang/Math.java "));
>>>>>
>>>
>>>
>>>
>>>>>
>>>>> URI uri = URI.createFileURI(f.getCanonicalPath());
>>>>> Resource resource = resourceSet.getResource(uri, true);
>>>>> JClass rootClass = (JClass) resource.getEObject("/");
>>>>>
>>>>>
>>>>> Gives..
>>>>>
>>>>> Caused by: 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.java.util.JavaResourceImpl.doLoad(JavaResour ceImpl.java:52)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>>>>>
>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1155)
>>>>>
>>>>> at
>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:256)
>>>>>
>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:271)
>>>>>
>>>
>>>>>
>>>>> at
>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:398)
>>>>>
>>>
>>>>>
>>>>> at
>>>>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>>>>
>>>>>
>>>>>
>>>>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro
>>>>> <marcelop@ca.ibm.com> said:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Actually back at the beginning of the year we changed the example
>>>>>> to use AST (it actually uses a set of interfaces that we
>>>>>> created to hide the underlying Java parsing tool). We didn't
>>>>>> have the time to update the model and the code to properly
>>>>>> support Java 5, though.
>>>>>>
>>>>>> So, in other words, although you won't see any Java 5 constructs
>>>>>> in the model, it won't throw exceptions because them.
>>>>>>
>>>>>> Cheers,
>>>>>> Marcelo
>>>>>>
>>>>>> Ed Merks wrote:
>>>>>>> Miles,
>>>>>>>
>>>>>>> The org.eclipse.emf.java model does that. Its part of our
>>>>>>> examples, but is based on JDOM so it doesn't handle Java 5.0.
>>>>>>> You'll find it in the team project set file I've attached.
>>>>>>>
>>>>>>>
>>>>>>> Miles Parker wrote:
>>>>>>>>
>>>>>>>> Just wondering if anyone haqs come across any efforts to build
>>>>>>>> a generic .ecore model for Java, with importers from source,
>>>>>>>> natch. :) Such a thing would be enormously useful for analysis
>>>>>>>> and transformation of existing java code..I'm not speaking of
>>>>>>>> some kind of deep parsing of methods of course, just down to
>>>>>>>> the stubs, but including modifiers, etc..
>>>
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Java model *in* ecore? [message #414256 is a reply to message #414255] |
Sat, 27 October 2007 23:11 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
Aha, I see. I made exactly the assumption that Ed assumes...It doesn't
make any sense to me why Eclipse can't utilize the launching
workbench's classpath and projects, but then a lot of Eclipse doesn't
make sense to me. :) I couldn't understand why it broke but running the
same thing with regular ecore resources worked fine...but no matter as
recasting the main as an IApp did the trick -- thanks.
On 2007-10-27 12:41:56 -0700, Ed Merks <merks@ca.ibm.com> said:
> Rafael,
>
> That and the workspace closed message was the reason for my assumption.
> Probably Miles is confusing running a Java application within Eclipse
> with running as an Eclipse application. I'm not sure this stuff will
> work well unless you open files within a Java project because we won't
> know the class path or how to find source files in general without the
> Java project information.
>
>
> Rafael Chaves wrote:
>> If the stack trace is complete, from the first frame you can tell he is not:
>>
>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>
>> Rafael
>>
>> Ed Merks wrote:
>>> Miles,
>>>
>>> The workspace closed message seems to indicate that you don't have a
>>> workspace though. You're sure you're running it as an Eclipse
>>> application?
>>>
>>>
>>> Miles Parker wrote:
>>>>
>>>> Nope, I'm using it from w/in Eclipse with JDT, EMF, etc..??
>>>>
>>>> btw, the XMLResource call is obviously an oversight.
>>>>
>>>> On 2007-10-27 08:47:03 -0700, Ed Merks <merks@ca.ibm.com> said:
>>>>
>>>>> Miles,
>>>>>
>>>>> You appear to be using it standalone and although JDT is supposed to
>>>>> work standalone, I gather from this stack trace that asking for the
>>>>> Java throws an exception. Probably we could add a guard for and I
>>>>> suppose we'd have to assume Java 5.0 source. Maybe you can try hacking
>>>>> the code to see how far it can get standalone...
>>>>>
>>>>>
>>>>> Miles Parker wrote:
>>>>>>
>>>>>> Hi Marcelo et.al.,
>>>>>>
>>>>>> I am just doing a somewhat braindead thing to try to load
>>>>>> programmatically.. it works for some utility methods for my own ecore
>>>>>> models but fails here -- just wondering what I might be doing
>>>>>> wrong..I'm calling this from an install with ..emf.java as plugin.
>>>>>>
>>>>>> This..
>>>>>>
>>>>>> JavaResourceFactoryImpl resourceFactory = new
>>>>>> JavaResourceFactoryImpl();
>>>>>>
>>>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "java",
>>>>>> resourceFactory);
>>>>>>
>>>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "packages",
>>>>>> new JavaPackageResourceFactoryImpl());
>>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>> JavaPackage jp = JavaPackage.eINSTANCE;
>>>>>>
>>>>>> resourceSet.getLoadOptions().put(XMLResource.OPTION_DEFER_ID REF_RESOLUTION,
>>>>>> Boolean.TRUE);
>>>>>> JavaFactory jf = JavaFactory.eINSTANCE;
>>>>>>
>>>>>> File f = new
>>>>>> File(platformPath("../org.metaabm.oaw.tools/javasrc/java/lang/Math.java "));
>>>>>>
>>>>>> URI uri = URI.createFileURI(f.getCanonicalPath());
>>>>>> Resource resource = resourceSet.getResource(uri, true);
>>>>>> JClass rootClass = (JClass) resource.getEObject("/");
>>>>>>
>>>>>>
>>>>>> Gives..
>>>>>>
>>>>>> Caused by: 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.java.util.JavaResourceImpl.doLoad(JavaResour ceImpl.java:52)
>>>>>> at
>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1155)
>>>>>> at
>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:256)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:271)
>>>>>>
>>>>>> at
>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:398)
>>>>>>
>>>>>> at
>>>>>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>>>>>
>>>>>>
>>>>>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro <marcelop@ca.ibm.com> said:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Actually back at the beginning of the year we changed the example to
>>>>>>> use AST (it actually uses a set of interfaces that we created to
>>>>>>> hide the underlying Java parsing tool). We didn't have the time to
>>>>>>> update the model and the code to properly support Java 5, though.
>>>>>>>
>>>>>>> So, in other words, although you won't see any Java 5 constructs in the
>>>>>>> model, it won't throw exceptions because them.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Marcelo
>>>>>>>
>>>>>>> Ed Merks wrote:
>>>>>>>> Miles,
>>>>>>>>
>>>>>>>> The org.eclipse.emf.java model does that. Its part of our examples,
>>>>>>>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it in
>>>>>>>> the team project set file I've attached.
>>>>>>>>
>>>>>>>>
>>>>>>>> Miles Parker wrote:
>>>>>>>>>
>>>>>>>>> Just wondering if anyone haqs come across any efforts to build a
>>>>>>>>> generic .ecore model for Java, with importers from source, natch. :)
>>>>>>>>> Such a thing would be enormously useful for analysis and transformation
>>>>>>>>> of existing java code..I'm not speaking of some kind of deep parsing of
>>>>>>>>> methods of course, just down to the stubs, but including modifiers,
>>>>>>>>> etc..
|
|
|
Re: Java model *in* ecore? [message #414257 is a reply to message #414256] |
Sun, 28 October 2007 04:09 |
Rafael Chaves Messages: 362 Registered: July 2009 |
Senior Member |
|
|
The problem is not with classpaths, the problem is that by launching as
a standalone Java app you don't get most of the nice features provided
by the Eclipse runtime. Anything that relies on those features will not
work, often in a way that makes it hard to figure out the reason. The
Resources API, for instance, relies on the workspace being open, and
that only happens when the Resources plug-in is activated (which happens
automatically when the first class/interface defined in that plug-in is
loaded).
Currently, most code shipped in the Eclipse SDK will only work properly
in the context of the Eclipse runtime, even when it seems quite obvious
that an API would be very useful in a standalone Java application and
there is no technical reasons preventing that from being done. It is
just something that has not been pushed for and is not part of the
committers' mindset. The current mindset seems to be to make the Eclipse
runtime more flexible so its features would be available in more
environments (for example, web application containers, mobile
applications etc).
Rafael
Miles Parker wrote:
>
> Aha, I see. I made exactly the assumption that Ed assumes...It doesn't
> make any sense to me why Eclipse can't utilize the launching workbench's
> classpath and projects, but then a lot of Eclipse doesn't make sense to
> me. :) I couldn't understand why it broke but running the same thing
> with regular ecore resources worked fine...but no matter as recasting
> the main as an IApp did the trick -- thanks.
>
>
> On 2007-10-27 12:41:56 -0700, Ed Merks <merks@ca.ibm.com> said:
>
>> Rafael,
>>
>> That and the workspace closed message was the reason for my
>> assumption. Probably Miles is confusing running a Java application
>> within Eclipse with running as an Eclipse application. I'm not sure
>> this stuff will work well unless you open files within a Java project
>> because we won't know the class path or how to find source files in
>> general without the Java project information.
>>
>>
>> Rafael Chaves wrote:
>>> If the stack trace is complete, from the first frame you can tell he
>>> is not:
>>>
>>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>>
>>>
>>> Rafael
>>>
>>> Ed Merks wrote:
>>>> Miles,
>>>>
>>>> The workspace closed message seems to indicate that you don't have a
>>>> workspace though. You're sure you're running it as an Eclipse
>>>> application?
>>>>
>>>>
>>>> Miles Parker wrote:
>>>>>
>>>>> Nope, I'm using it from w/in Eclipse with JDT, EMF, etc..??
>>>>>
>>>>> btw, the XMLResource call is obviously an oversight.
>>>>>
>>>>> On 2007-10-27 08:47:03 -0700, Ed Merks <merks@ca.ibm.com> said:
>>>>>
>>>>>> Miles,
>>>>>>
>>>>>> You appear to be using it standalone and although JDT is supposed
>>>>>> to work standalone, I gather from this stack trace that asking
>>>>>> for the Java throws an exception. Probably we could add a guard
>>>>>> for and I suppose we'd have to assume Java 5.0 source. Maybe you
>>>>>> can try hacking the code to see how far it can get standalone...
>>>>>>
>>>>>>
>>>>>> Miles Parker wrote:
>>>>>>>
>>>>>>> Hi Marcelo et.al.,
>>>>>>>
>>>>>>> I am just doing a somewhat braindead thing to try to load
>>>>>>> programmatically.. it works for some utility methods for my own
>>>>>>> ecore models but fails here -- just wondering what I might be
>>>>>>> doing wrong..I'm calling this from an install with ..emf.java as
>>>>>>> plugin.
>>>>>>>
>>>>>>> This..
>>>>>>>
>>>>>>> JavaResourceFactoryImpl resourceFactory = new
>>>>>>> JavaResourceFactoryImpl();
>>>>>>>
>>>>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "java",
>>>>>>> resourceFactory);
>>>>>>>
>>>>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "packages",
>>>>>>> new JavaPackageResourceFactoryImpl());
>>>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>>> JavaPackage jp = JavaPackage.eINSTANCE;
>>>>>>>
>>>>>>> resourceSet.getLoadOptions().put(XMLResource.OPTION_DEFER_ID REF_RESOLUTION,
>>>>>>> Boolean.TRUE);
>>>>>>> JavaFactory jf = JavaFactory.eINSTANCE;
>>>>>>>
>>>>>>> File f = new
>>>>>>> File(platformPath("../org.metaabm.oaw.tools/javasrc/java/lang/Math.java "));
>>>>>>>
>
>
>
>
>
>>>>>>>
>>>>>>> URI uri = URI.createFileURI(f.getCanonicalPath());
>>>>>>> Resource resource = resourceSet.getResource(uri, true);
>>>>>>> JClass rootClass = (JClass) resource.getEObject("/");
>>>>>>>
>>>>>>>
>>>>>>> Gives..
>>>>>>>
>>>>>>> Caused by: 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.java.util.JavaResourceImpl.doLoad(JavaResour ceImpl.java:52)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>>>>>>>
>
>
>
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1155)
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:256)
>>>>>>>
>
>
>
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:271)
>>>>>>>
>
>
>
>>>>>>>
>>>>>>> at
>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:398)
>>>>>>>
>
>
>
>>>>>>>
>>>>>>> at
>>>>>>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro
>>>>>>> <marcelop@ca.ibm.com> said:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Actually back at the beginning of the year we changed the
>>>>>>>> example to use AST (it actually uses a set of interfaces that
>>>>>>>> we created to hide the underlying Java parsing tool). We didn't
>>>>>>>> have the time to update the model and the code to properly
>>>>>>>> support Java 5, though.
>>>>>>>>
>>>>>>>> So, in other words, although you won't see any Java 5 constructs
>>>>>>>> in the model, it won't throw exceptions because them.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Marcelo
>>>>>>>>
>>>>>>>> Ed Merks wrote:
>>>>>>>>> Miles,
>>>>>>>>>
>>>>>>>>> The org.eclipse.emf.java model does that. Its part of our
>>>>>>>>> examples, but is based on JDOM so it doesn't handle Java 5.0.
>>>>>>>>> You'll find it in the team project set file I've attached.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Miles Parker wrote:
>>>>>>>>>>
>>>>>>>>>> Just wondering if anyone haqs come across any efforts to build
>>>>>>>>>> a generic .ecore model for Java, with importers from source,
>>>>>>>>>> natch. :) Such a thing would be enormously useful for analysis
>>>>>>>>>> and transformation of existing java code..I'm not speaking of
>>>>>>>>>> some kind of deep parsing of methods of course, just down to
>>>>>>>>>> the stubs, but including modifiers, etc..
>
>
|
|
|
OT? Runtime Eclipse Dependencies Re: Java model *in* ecore? [message #414288 is a reply to message #414257] |
Mon, 29 October 2007 18:23 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
[A little OT]
On 2007-10-27 21:09:26 -0700, Rafael Chaves <rafael@no.spam.abstratt.com> said:
> The problem is not with classpaths, the problem is that by launching as
> a standalone Java app you don't get most of the nice features provided
> by the Eclipse runtime. Anything that relies on those features will not
> work, often in a way that makes it hard to figure out the reason.
Yes, or a solution! It took some effort but I was able to get my
complete EMF generation and alll of my own test generation via oAW
working purely form w/in headless ant. The EMF and oAW teams both have
a clear apreciation for dependency issues even as they are constrained
by platform requirements. The JDT (and PDE and platform I suppose) for
perfectly understandable reasons seem to have less..
> Resources API, for instance, relies on the workspace being open, and
> that only happens when the Resources plug-in is activated (which
> happens automatically when the first class/interface defined in that
> plug-in is loaded).
The EMF XSD resorce stuff does seems to avoid this somehow..perhaps
because so much of the specific resource stack is implemented w/in
EMF..?
>
> Currently, most code shipped in the Eclipse SDK will only work properly
> in the context of the Eclipse runtime, even when it seems quite obvious
> that an API would be very useful in a standalone Java application and
> there is no technical reasons preventing that from being done. It is
> just something that has not been pushed for and is not part of the
> committers' mindset. The current mindset seems to be to make the
> Eclipse runtime more flexible so its features would be available in
> more environments (for example, web application containers, mobile
> applications etc).
A nice synopsis. I am having a difficult time with this as -- and I
suspect I'm not alone in this -- over the last half-a-dozen years I
have attained the tool independence religion where for example for all
of the repos I've worked with we have had a hard and fast rule that all
code must be buildable and testable headlessly using only java, ant,
junit and included jars. And now I find that I've joined a different
cult unwittingly. ;)
IMNSHO, all Eclipse projects should be strictly following a layered
approach in which the core is free of any non-core tool dependencies
and that all of those are specified as genericly as possible and so on.
I know that this is a little too much t ask for, but I hope things get
closer.
As you suggest I think the deep design of some aspects of the platform
reflect a fixation on the platform as target. For example, the name of
the IApplication interface and related tools are unnecessarily specific
and confusing. In my usage, this is really simply a job or task.
Anyway, enough complaining - for the most part it works well _once I
have been properly indoctrinated_. :)
>
> Rafael
>
> Miles Parker wrote:
>>
>> Aha, I see. I made exactly the assumption that Ed assumes...It doesn't
>> make any sense to me why Eclipse can't utilize the launching
>> workbench's classpath and projects, but then a lot of Eclipse doesn't
>> make sense to me. :) I couldn't understand why it broke but running the
>> same thing with regular ecore resources worked fine...but no matter as
>> recasting the main as an IApp did the trick -- thanks.
>>
>>
>> On 2007-10-27 12:41:56 -0700, Ed Merks <merks@ca.ibm.com> said:
>>
>>> Rafael,
>>>
>>> That and the workspace closed message was the reason for my assumption.
>>> Probably Miles is confusing running a Java application within Eclipse
>>> with running as an Eclipse application. I'm not sure this stuff will
>>> work well unless you open files within a Java project because we won't
>>> know the class path or how to find source files in general without the
>>> Java project information.
>>>
>>>
>>> Rafael Chaves wrote:
>>>> If the stack trace is complete, from the first frame you can tell he is not:
>>>>
>>>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>>>
>>>> Rafael
>>>>
>>>> Ed Merks wrote:
>>>>> Miles,
>>>>>
>>>>> The workspace closed message seems to indicate that you don't have a
>>>>> workspace though. You're sure you're running it as an Eclipse
>>>>> application?
>>>>>
>>>>>
>>>>> Miles Parker wrote:
>>>>>>
>>>>>> Nope, I'm using it from w/in Eclipse with JDT, EMF, etc..??
>>>>>>
>>>>>> btw, the XMLResource call is obviously an oversight.
>>>>>>
>>>>>> On 2007-10-27 08:47:03 -0700, Ed Merks <merks@ca.ibm.com> said:
>>>>>>
>>>>>>> Miles,
>>>>>>>
>>>>>>> You appear to be using it standalone and although JDT is supposed to
>>>>>>> work standalone, I gather from this stack trace that asking for the
>>>>>>> Java throws an exception. Probably we could add a guard for and I
>>>>>>> suppose we'd have to assume Java 5.0 source. Maybe you can try hacking
>>>>>>> the code to see how far it can get standalone...
>>>>>>>
>>>>>>>
>>>>>>> Miles Parker wrote:
>>>>>>>>
>>>>>>>> Hi Marcelo et.al.,
>>>>>>>>
>>>>>>>> I am just doing a somewhat braindead thing to try to load
>>>>>>>> programmatically.. it works for some utility methods for my own ecore
>>>>>>>> models but fails here -- just wondering what I might be doing
>>>>>>>> wrong..I'm calling this from an install with ..emf.java as plugin.
>>>>>>>>
>>>>>>>> This..
>>>>>>>>
>>>>>>>> JavaResourceFactoryImpl resourceFactory = new
>>>>>>>> JavaResourceFactoryImpl();
>>>>>>>>
>>>>>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "java",
>>>>>>>> resourceFactory);
>>>>>>>>
>>>>>>>> Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap( ).put( "packages",
>>>>>>>> new JavaPackageResourceFactoryImpl());
>>>>>>>> ResourceSet resourceSet = new ResourceSetImpl();
>>>>>>>> JavaPackage jp = JavaPackage.eINSTANCE;
>>>>>>>>
>>>>>>>> resourceSet.getLoadOptions().put(XMLResource.OPTION_DEFER_ID REF_RESOLUTION,
>>>>>>>> Boolean.TRUE);
>>>>>>>> JavaFactory jf = JavaFactory.eINSTANCE;
>>>>>>>>
>>>>>>>> File f = new
>>>>>>>> File(platformPath("../org.metaabm.oaw.tools/javasrc/java/lang/Math.java "));
>>>>>>>>
>>>>>>>> URI uri = URI.createFileURI(f.getCanonicalPath());
>>>>>>>> Resource resource = resourceSet.getResource(uri, true);
>>>>>>>> JClass rootClass = (JClass) resource.getEObject("/");
>>>>>>>>
>>>>>>>>
>>>>>>>> Gives..
>>>>>>>>
>>>>>>>> Caused by: 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.java.util.JavaResourceImpl.doLoad(JavaResour ceImpl.java:52)
>>>>>>>> at
>>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1155)
>>>>>>>> at
>>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:256)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:271)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:398)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.metaabm.util.oaw.ExtractJavaFunctions.main(ExtractJavaFu nctions.java:52)
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2007-10-26 07:43:13 -0700, Marcelo Paternostro <marcelop@ca.ibm.com> said:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Actually back at the beginning of the year we changed the example to
>>>>>>>>> use AST (it actually uses a set of interfaces that we created to
>>>>>>>>> hide the underlying Java parsing tool). We didn't have the time to
>>>>>>>>> update the model and the code to properly support Java 5, though.
>>>>>>>>>
>>>>>>>>> So, in other words, although you won't see any Java 5 constructs in the
>>>>>>>>> model, it won't throw exceptions because them.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Marcelo
>>>>>>>>>
>>>>>>>>> Ed Merks wrote:
>>>>>>>>>> Miles,
>>>>>>>>>>
>>>>>>>>>> The org.eclipse.emf.java model does that. Its part of our examples,
>>>>>>>>>> but is based on JDOM so it doesn't handle Java 5.0. You'll find it in
>>>>>>>>>> the team project set file I've attached.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Miles Parker wrote:
>>>>>>>>>>>
>>>>>>>>>>> Just wondering if anyone haqs come across any efforts to build a
>>>>>>>>>>> generic .ecore model for Java, with importers from source, natch. :)
>>>>>>>>>>> Such a thing would be enormously useful for analysis and transformation
>>>>>>>>>>> of existing java code..I'm not speaking of some kind of deep parsing of
>>>>>>>>>>> methods of course, just down to the stubs, but including modifiers,
>>>>>>>>>>> etc..
|
|
|
Goto Forum:
Current Time: Mon Sep 23 17:37:04 GMT 2024
Powered by FUDForum. Page generated in 0.06077 seconds
|