Home » Modeling » M2T (model-to-text transformation) » [Acceleo] Invalid attributes during template invocation
| [Acceleo] Invalid attributes during template invocation [message #975044] |
Wed, 07 November 2012 14:52  |
 Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
Hi,
I am using Eclipse 3.6.2, EMF 2.6.1 and Acceleo 3.3.1.v20120912 on Linux.
I have defined the following metamodels
MM1
Class A
Attr1 : String
Attr2 : String
MM2
Class B extends A
Attr3 : String (derived from Attr1 and Attr2)
MM3
Class C extends B
*** more attributes***
Class D extends B
*** more attributes***
I should probably mention that MM1 lives in a plugin installed in my Eclipse while MM2 and MM3 containing plugins live in my workspace.
Now, I have written a simple Acceleo template which iterates over C instances
[template public AcceleoMain(anInstance: C)]
[comment @main /]
[file ('stdout', false, 'UTF-8')]
Generating [anInstance.Attr3 /] from [anInstance.Attr1 /] and [anInstance.Attr2 /]
[/file]
[/template]
This template is successfully compiled by Acceleo. Yet, I am running into trouble when launching the generation
!ENTRY org.eclipse.ocl 4 10 2012-11-07 15:26:57.015
!MESSAGE Evaluation failed with an exception: (no message)
!STACK 0
java.lang.IllegalArgumentException
at org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigateProperty(EcoreEvaluationEnvironment.java:226)
at org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigateProperty(EcoreEvaluationEnvironment.java:1)
at org.eclipse.ocl.EvaluationVisitorImpl.visitPropertyCallExp(EvaluationVisitorImpl.java:1925)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitPropertyCallExp(AcceleoEvaluationVisitor.java:1239)
at org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(PropertyCallExpImpl.java:238)
at org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(AbstractEvaluationVisitor.java:247)
at org.eclipse.ocl.EvaluationVisitorDecorator.visitExpression(EvaluationVisitorDecorator.java:156)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1887)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1042)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoFileBlock(AcceleoEvaluationVisitor.java:423)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1848)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1042)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoForBlock(AcceleoEvaluationVisitor.java:536)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1835)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1042)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoTemplate(AcceleoEvaluationVisitor.java:914)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1819)
at org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1042)
at org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(QueryImpl.java:152)
at org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:62)
at org.eclipse.acceleo.engine.generation.AcceleoEngine.doEvaluate(AcceleoEngine.java:365)
at org.eclipse.acceleo.engine.generation.AcceleoEngine.evaluate(AcceleoEngine.java:142)
at org.eclipse.acceleo.engine.service.AcceleoService.doGenerateTemplate(AcceleoService.java:884)
at org.eclipse.acceleo.engine.service.AcceleoService.doGenerate(AcceleoService.java:575)
at org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.generate(AbstractAcceleoGenerator.java:193)
at org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.doGenerate(AbstractAcceleoGenerator.java:158)
...
On stdout, I get the following values:
Attr3: Correct value, as derived from Attr1 and Attr2
Attr1/2: org.eclipse.emf.ecore.impl.DynamicEObjectImpl@27979138 (eClass: org.eclipse.emf.ecore.impl.EClassImpl@4fbf07d6 (name: OclInvalid_Class) (instanceClassName: null) (abstract: false, interface: false))
It looks like that Acceleo cannot access Attr1 and Attr2 fields at runtime, but I have no idea why. Before Acceleo activation, I checked in the Debugger that all three attributes were correctly set for all C instances.
Worse, I do not face these issues with the generator that operates on D instances.
Were should I start investigating ?
Thanks,
Michaël
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #975392 is a reply to message #975044] |
Wed, 07 November 2012 20:56  |
Ed Willink
Messages: 7681
Registered: July 2009 |
Senior Member |
|
|
Hi
Acceleo's messages are not always perfect. I suspect that navigation
from null has yielded invalid.
If you do a Debug launch as a Java application you can examine the stack
context of the PropertyCallExpImpl.accept and work out what navigation
is probably failing.
Regards
Ed Willink
On 07/11/2012 14:52, Michaël Melchiore wrote:
> Hi,
>
> I am using Eclipse 3.6.2, EMF 2.6.1 and Acceleo 3.3.1.v20120912 on Linux.
>
> I have defined the following metamodels
>
> MM1
> Class A
> Attr1 : String
> Attr2 : String
>
> MM2
> Class B extends A
> Attr3 : String (derived from Attr1 and Attr2)
>
> MM3
> Class C extends B
> *** more attributes***
> Class D extends B
> *** more attributes***
>
> I should probably mention that MM1 lives in a plugin installed in my
> Eclipse while MM2 and MM3 containing plugins live in my workspace.
>
> Now, I have written a simple Acceleo template which iterates over C
> instances
>
> [template public AcceleoMain(anInstance: C)]
> [comment @main /]
> [file ('stdout', false, 'UTF-8')]
> Generating [anInstance.Attr3 /] from [anInstance.Attr1 /] and
> [anInstance.Attr2 /]
> [/file]
> [/template]
>
> This template is successfully compiled by Acceleo. Yet, I am running
> into trouble when launching the generation
>
> !ENTRY org.eclipse.ocl 4 10 2012-11-07 15:26:57.015
> !MESSAGE Evaluation failed with an exception: (no message)
> !STACK 0
> java.lang.IllegalArgumentException
> at
> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigateProperty(EcoreEvaluationEnvironment.java:226)
> at
> org.eclipse.ocl.ecore.EcoreEvaluationEnvironment.navigateProperty(EcoreEvaluationEnvironment.java:1)
> at
> org.eclipse.ocl.EvaluationVisitorImpl.visitPropertyCallExp(EvaluationVisitorImpl.java:1925)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitPropertyCallExp(AcceleoEvaluationVisitor.java:1239)
> at
> org.eclipse.ocl.ecore.impl.PropertyCallExpImpl.accept(PropertyCallExpImpl.java:238)
> at
> org.eclipse.ocl.AbstractEvaluationVisitor.visitExpression(AbstractEvaluationVisitor.java:247)
> at
> org.eclipse.ocl.EvaluationVisitorDecorator.visitExpression(EvaluationVisitorDecorator.java:156)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1887)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1042)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoFileBlock(AcceleoEvaluationVisitor.java:423)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1848)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1042)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoForBlock(AcceleoEvaluationVisitor.java:536)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1835)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1042)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitAcceleoTemplate(AcceleoEvaluationVisitor.java:914)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.switchExpression(AcceleoEvaluationVisitor.java:1819)
> at
> org.eclipse.acceleo.engine.internal.evaluation.AcceleoEvaluationVisitor.visitExpression(AcceleoEvaluationVisitor.java:1042)
> at
> org.eclipse.ocl.internal.evaluation.QueryImpl.evaluate(QueryImpl.java:152)
> at org.eclipse.ocl.ecore.QueryImpl.evaluate(QueryImpl.java:62)
> at
> org.eclipse.acceleo.engine.generation.AcceleoEngine.doEvaluate(AcceleoEngine.java:365)
> at
> org.eclipse.acceleo.engine.generation.AcceleoEngine.evaluate(AcceleoEngine.java:142)
> at
> org.eclipse.acceleo.engine.service.AcceleoService.doGenerateTemplate(AcceleoService.java:884)
> at
> org.eclipse.acceleo.engine.service.AcceleoService.doGenerate(AcceleoService.java:575)
> at
> org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.generate(AbstractAcceleoGenerator.java:193)
> at
> org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.doGenerate(AbstractAcceleoGenerator.java:158)
> ..
>
> On stdout, I get the following values:
> Attr3: Correct value, as derived from Attr1 and Attr2
> Attr1/2: mailto:org.eclipse.emf.ecore.impl.DynamicEObjectImpl@27979138
> (eClass: mailto:org.eclipse.emf.ecore.impl.EClassImpl@4fbf07d6 (name:
> OclInvalid_Class) (instanceClassName: null) (abstract: false,
> interface: false))
>
> It looks like that Acceleo cannot access Attr1 and Attr2 fields at
> runtime, but I have no idea why. Before Acceleo activation, I checked
> in the Debugger that all three attributes were correctly set for all C
> instances.
>
> Worse, I do not face these issues with the generator that operates on
> D instances.
>
> Were should I start investigating ?
>
> Thanks,
>
> Michaël
>
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #976005 is a reply to message #975392] |
Thu, 08 November 2012 08:39 |
|
Hi,
I'll be a little picky ...
Ed Willink wrote on Wed, 07 November 2012 15:56Acceleo's messages are not always perfect.
You do realize that this error stems from OCL? This is a recurrent exception from the property navigation of OCL when we try and navigate a property on something that is not an EObject (which fails for obvious reasons  ). We cannot just catch 'RuntimeException' or 'IllegalException' from our code and then try and infer what really happened underneath. It would probably be better if OCL encapsulated the exceptions in a more specific sub-class to allow for safer catches/better error messages.
Michaël,
As you can probably understand from the above rant, there is no real straightforward way to debug this. The underlying error is that "anInstance" is not an EObject (i.e. not an instance of "C") in your example. You can try and print it alone to understand what happened : add [anInstance/] at the beginning of the file block... followed by [anInstance.oclIsUndefined()/] in case it is actually 'null'.
If it is null, you will have to properly guard your template against the possibility. If it is not an EObject, you will have to debug why.
Laurent Goubet
Obeo
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #976099 is a reply to message #976005] |
Thu, 08 November 2012 10:07 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
Thanks for your replies.
As Laurent suggested, I have added [anInstance/] and [anInstance.oclIsUndefined()/] in my template. The results show that anInstance is always a non-null instance of C.
[anInstance/] sucessfully invokes anInstance.toString() method. Again Attr1, Attr2 and Attr3 values are correct in the resulting string displayed on stdout.
As seen by Java, anInstance is a perfectly valid instance of the C->B->A class.
In OCL, navigation from B(MM2) to A(MM1) classes fails for some reason.
Maybe I got the dependencies wrong betwen my Acceleo plugins and my MM plugins ? From comment 3 of this bug report, I understand that some requirements apply, but they are not always clear to me.
Two examples:
A metamodel and its generated java classes can live in separate plugins. In my Acceleo plugin, which should I register as dependencies ?
In MM2 plugin, MM1 plugin is registered as a dependency. Will Acceleo be able to navigate to MM1 if I only register MM2 as a dependency ?
Regards,
[Updated on: Thu, 08 November 2012 10:44] Report message to a moderator |
|
| |
| Re: [Acceleo] Invalid attributes during template invocation [message #976162 is a reply to message #976114] |
Thu, 08 November 2012 11:06 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
I have found a working workaround.
In B class, I added two new attributes AAttr1 and AAttr2.
MM2
Class B extends A
Attr3 : String (derived from Attr1 and Attr2)
AAttr1 : String
AAttr2 : String
Then, I have modified BImpl.java so that setAAttr1 and setAAttr2 are automatically called within setAttr1 and setAttr2 are invocated (I forgot to mention that A is an abtract class so that all its method are implemented in B).
In Acceleo templates, I now use AAttr1 and AAttr2 which always mirror Attr1 and Attr2 values.
This strongly indicates that OCL navigation from B to A is the culprit.
[Updated on: Thu, 08 November 2012 12:15] Report message to a moderator |
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #976259 is a reply to message #976162] |
Thu, 08 November 2012 12:37 |
Ed Willink
Messages: 7681
Registered: July 2009 |
Senior Member |
|
|
Hi
You are making assumptions that you understand the problem and so you
present a subjective view that makes it impossible to reproduce your
problems.
For instance, you omitted abstract, and you wrote
"On stdout, I get the following values:
Attr3: Correct value, as derived from Attr1 and Attr2
Attr1/2: mailto:org.eclipse.emf.ecore.impl.DynamicEObjectImpl@27979138
(eClass: mailto:org.eclipse.emf.ecore.impl.EClassImpl@4fbf07d6 (name:
OclInvalid_Class) (instanceClassName: null) (abstract: false, interface:
false)) "
This does not look like the output of your transformation.
Please provide a zipped project so that your actual problem can be examined.
Regards
Ed Willink
On 08/11/2012 11:06, Michaël Melchiore wrote:
> I have found a working workaround.
>
> In B class, I added two new attributes AAttr1 and AAttr2.
>
> MM2
> Class B extends A
> Attr3 : String (derived from Attr1 and Attr2)
> AAttr1 : String
> AAttr2 : String[/code]
>
> Then, I have modified BImpl.java so that setAAttr1 and setAAttr2 are
> automatically called within setAttr1 and setAttr2 are invocated (I
> forgot to mention that A is an abtract class so that all its method
> are implemented in B).
>
> In Acceleo templates, I now use AAttr1 and AAttr2 which always mirror
> Attr1 and Attr2 values.
> This strongly indicates that OCL navigation from B to A is the culprit.
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #976289 is a reply to message #976259] |
Thu, 08 November 2012 13:10 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
MM1 is a proprietary COTS from an external provider, I am not allowed to submit a zipped project. This is why I am asking for pointers to investigate the problem myself. As you said, I also have an incomplete understanding of the situation.
What makes you think the presented output is wrong ?
The presented example is indeed a simplified view of my real use case which contains a lot of "noise". Yet, my real case involves the same class hierarchy with the same three String attributes. The only differences are the attrobute names.
I should have mentionned that A is abstract but I only noticed it while investigating the COTS documentation. Please keep in mind that B and C are not abstract classes. As mentionned in my first post, the template operates on C instances.
[Updated on: Thu, 08 November 2012 13:15] Report message to a moderator |
|
| | | | |
| Re: [Acceleo] Invalid attributes during template invocation [message #976501 is a reply to message #976484] |
Thu, 08 November 2012 16:20 |
Ed Willink
Messages: 7681
Registered: July 2009 |
Senior Member |
|
|
Hi
That is why we need a reproducible example. It appears that the problem
is not where you think it is and so not in what we have seen.
On these occasions I resort to a kind of binary search.
Take a complete copy of the faulty system and repeatedly delete 50%
until the problem goes away, back up and try a different deletion.
Eventually a small repro emerges and too often an irritation at being so
stupid. Sometimes the irritation can be assuaged slightly by reporting a
bug against some poor error detection.
Regards
Ed Willink
On 08/11/2012 16:09, Michaël Melchiore wrote:
> I have created a small example, but I am unable to reproduce the problem. At least, you can examine it to understand what I am trying to achieve. In a real project, I would have separate templates to deal with B, C and D instances.
>
> test-case-code.tar.gz contains the metamodels, the Acceleo template and launcher projects.
> test-case-model.tar.gz contains a single project with a sample model. Launch Acceleo on it using the popup menu
>
>
> If you have suggestions on how to trigger the faulty behavior, I am listening.
>
> Regards,
>
> Michaël
|
|
| | |
| Re: [Acceleo] Invalid attributes during template invocation [message #977447 is a reply to message #977321] |
Fri, 09 November 2012 09:43 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
I have finally managed to reproduce the problem. The key is to have the root metamodel installed in Eclipse.
The class hierarchy is as follows :
MM0
Z
MM1
A extend Z
MM2
B extend A
genRoot
MM3
C extend B
D extend B
In the example, I used nested Eclipse applications to emulate MM0 plugin installation
Eclipse 0 (MM0) <- Eclipse 1(MM1, MM2, MM3, Acceleo template, Acceleo launcher) <- Eclipse 2 (Example model)
[Updated on: Tue, 04 December 2012 13:40] Report message to a moderator |
|
| | |
| Re: [Acceleo] Invalid attributes during template invocation [message #989027 is a reply to message #989021] |
Tue, 04 December 2012 10:55 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
As suggested, I am reposting my message from November, 9th
I have finally managed to reproduce the problem. The key is to have the root metamodel installed in Eclipse.
The class hierarchy is as follows :
MM0
Z
MM1
A extend Z
MM2
B extend A
genRoot
MM3
C extend B
D extend B
In the example, I used nested Eclipse applications to emulate MM0 plugin installation
Eclipse 0 (MM0) <- Eclipse 1(MM1, MM2, MM3, Acceleo template, Acceleo launcher) <- Eclipse 2 (Example model)
[Updated on: Tue, 04 December 2012 13:39] Report message to a moderator |
|
| | | | | |
| Re: [Acceleo] Invalid attributes during template invocation [message #989077 is a reply to message #989069] |
Tue, 04 December 2012 14:36 |
Ed Willink
Messages: 7681
Registered: July 2009 |
Senior Member |
|
|
Hi
Knowing what to launch I can see a variety of problems.
Launching an "Acceleo Plugin Application (Default)" runner locks my
Eclipse up; probably
https://bugs.eclipse.org/bugs/show_bug.cgi?id=346233 again.
Launching an "Java Application (Advanced)" gives informative content in
the stack trace.
Exception in thread "main"
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException:
org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri
'http://example.org/mm2' not found.
(file:/C:/Development/Buck/runtime-New_configuration/org.example.acceleo/tasks/model.mm2,
2, 227)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.handleDemandLoadException(ResourceSetImpl.java:319)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:278)
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:406)
at
org.eclipse.acceleo.common.utils.ModelUtils.load(ModelUtils.java:361)
at
org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.initialize(AbstractAcceleoGenerator.java:457)
at org.example.acceleo.Main.<init>(Main.java:90)
at org.example.acceleo.Main.main(Main.java:144)
Caused by: org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package
with uri 'http://example.org/mm2' not found.
(file:/C:/Development/Buck/runtime-New_configuration/org.example.acceleo/tasks/model.mm2,
2, 227)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.getPackageForURI(XMLHandler.java:2593)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.getFactoryForPrefix(XMLHandler.java:2423)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1300)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1469)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:1020)
at
org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMIHandler.java:77)
which is because you have not reacted to the comments in Main.java
telling you how to register your packages.
Looking at your manifests by eye, it looks like you may have a later
problem that mm0 is not exported and so should be invisible.
Your difficulty in reproducing your problem may be because the URI
resolution in Acceleo is inconsistent between the editing and execution
contexts. There is helpful heuristic code that seems to work in simple
cases. Unfortunately in complex cases it seems to add to the debugging
complexity.
I suggest that the Acceleo guys try launching your main.mtl in the
nested Eclipse using the model.mm2 from the nested nested Eclipse. Keep
the org.eclipse.ocl.ecore, that has an inheritance error since
attempting to Run As -> Launch Acceleo Application for main.mtl first
creates a launch but fails to run, and subsequent attempts give an
obsure "Model is missing" diagnostic in the Error Log without any clue
as to the source application. Once the missing model.mm2 is is corrected
in the launch, the "Acceleo Plugin Application (Default)" lock up can be
encountered.
All in all, you provide useful examples of how things can go wrong and
how missing diagnostics can make moderate problems that are very common
user errors very confusing.
If you
a) use "Java Application (Advanced)" runner
b) register your packages in Main.java as commented
c) make your packages visible on the classpath
you might make progress.
Regards
Ed Willink
On 04/12/2012 13:56, Ed Willink wrote:
> Hi
>
> You're getting vague again.
>
> It seems the nested nested Eclipse was just a confusing red herring.
>
> You didn't provide a launch configuration so how do I know what to
> launch and how?
>
> [If you use an "Acceleo Plugin Application (Default)" runner, the
> problem is solved; it never works for me. I only use "Java Application
> (Advanced)".]
>
> Regards
>
> Ed Willink
>
>
> On 04/12/2012 13:09, Michaël Melchiore wrote:
>> As stated in my first post, I am working with Eclipse 3.6.2 and EMF
>> 2.6.1. I could try to run the test case in a updated Eclipse
>> installation. But this will not be an option for my real work. Do
>> Helios packages still receive bug fixes ?
>>
>> The org.eclipse.ocl.ecore plug-in copy was there so that I could step
>> through its code with the java debugger. I will edit my previous
>> posts so that it is no longer provided in the corresponding archive.
>>
>> Regarding the other plugins I chose to provide, I think this is
>> purely a matter of personal view. I wanted the examples to run "out
>> of the box" so that kind helpers can use them quickly. You want the
>> least amount of nose possible. This is a different, yet perfectly
>> valid, point of view on the matter of test case packaging.
>>
>> The problem I am trying the reproduce is the
>> java.lang.IllegalArgumentException exception that is thrown by
>> Acceleo during code generation (see my first post).
>> Thanks for your help
>>
>> Michaël
>>
>>
>>
>
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #989084 is a reply to message #989069] |
Tue, 04 December 2012 15:05 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
No, the nested nested Eclipse is not a red herring.
I built this example trying to mimic the real code I am working on. From the feedback I received in this thread, my issue seems to involve metamodel resolving and navigation. I have two different kinds of metamodels :
- installed in Eclipse
- contained in a workspace plugin
Precisely, I have defined a few classes, which are organized in several metamodels spread across different plugins in my workspace. All these classes inherit from a single class. In my use case, issues arise when I try to access the root class attributes from children class instances in Acceleo. The only distinguishing feature of the root class is that it is the only class which metamodel that is not contained in my workspace.It is is installed in Eclipse.
The nested nested Eclipse was the only way I found to reproduce the situation. In the test case, MM0 contains the root class Z, while MM1, 2 and 3 define children classes of Z.
If MM0, 1, 2 and 3 all live in the same workspace, the Acceleo generation run without error. I simply launch an Eclipse application, create an example project and launch generation using Acceleo launcher popup menu entry.
To reproduce my issue, I had to find a trick so that MM0 looks "installed" from MM1, 2 and 3 point of view. This is why MM0 has its own workspace.
Workspace0
ProjectMM0
EclipseApplication1
Workspace1
ProjectMM1
ProjectMM2
ProjectMM3
EclipseApplication2
Workspace2
ProjectWithExampleModel
All EclipseApplication use default launch settings besides setting the right workspace locations.
I hope this helps. English is not my native language, I am trying my best to be clear.
[Updated on: Tue, 04 December 2012 15:07] Report message to a moderator |
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #997699 is a reply to message #989084] |
Tue, 08 January 2013 15:11 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
Hi guys,
First, I wish you all a happy new year.
Ed, I have fixed my Main.java so that Mm0Package is properly registered with Acceleo (using the UML example as reference). What do you mean by "mm0 is not exported" ? The generated packages are exported in the MANIFEST.MF and an extension to "org.eclipse.emf.ecore.generated_package" does register the Mm0Package. Is there an other step I am not aware of ?
I have installed Acceleo 3.3.1.v20120912 in three different Eclipse:
- Eclipse SDK (3.6.2.M20110210-1200) and EMF - Eclipse Modeling Framework SDK (2.6.1.v20100914-1218)
- Eclipse Modeling Tools Indigo (1.4.2.20120213-0813)
- Eclipse Modeling Tools Juno (1.5.1.20120917-1257)
The first installation is my target developping environment where I first found the issues. The two others are Eclipse Modeling Tools packages downloaded straight from the Indigo and Juno website.
Running the provided example (with Ed suggested fix and without the OCL plugin in workspace), Acceleo still throws java.lang.IllegalArgumentException exception in all cases but the last (Juno). Ed also demonstrated that the example runs perfectly fine in Kepler.
It would be nice to have Acceleo guys help on the subject.
Regards,
Michaël
[Updated on: Tue, 08 January 2013 15:24] Report message to a moderator |
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #1011849 is a reply to message #997699] |
Wed, 20 February 2013 11:11 |
|
Michael,
I had mistakenly thought that this thread was resolved, please forgive the long delay. Do not hesitate to "ping" us by commenting on your forum threads if they stale too long, chances are we overlooked them.
Trying to untangle the useful information from the noise was a little hard, but here are the steps I settled on to try this :
- download a new "eclipse classic" bundle
- launch this eclipse, install the corresponding EMF version (2.6 in Helios, 2.7 in Indigo, did not try others) along with Acceleo 3.4.0 (http://download.eclipse.org/releases/kepler), restart eclipse
- import eclipse-0-projects
- "run > Run Configurations..." create a new "Eclipse application", change the Xmx and MaxPermSize to more intelligent values that the default (-Xmx512m -XX:MaxPermSize=256m)
- import eclipse-1-projects in the second eclipse
- "run > Run Configurations..." create a new "Eclipse application", change the Xmx and MaxPermSize as well as the workspace location (appended "2" at the end of the default)
- import eclipse-2-projects in the third eclipse
- right-click /org.example.model/model/model.mm2 > Acceleo > Generate Acceleo
This works without a hitch in Indigo. I then went back to Helios using the same steps.
The first try resulted in java.lang.NoClassDefFoundError: org/eclipse/ocl/helper/OCLSyntaxHelper . Somehow, using the Kepler update site to install Acceleo in Helios resulted in me having "org.eclipse.ocl" version 3.0 and "org.eclipse.ocl.ecore" version 3.2... which is totally incoherent.
I then repeated the steps using the Acceleo update site directly instead of Kepler, which resulted in a sound installation (o.e.ocl 3.0.2 and o.e.ocl.ecore 3.0.2). This indeed fails in IllegalArgumentException.
Since these two were using the very same steps with the same versions of Acceleo, my very first guess is that it was a bug in OCL that's been fixed somewhere on the road between Helios and Juno. However, I will still try again with my Indigo install but without the Kepler update site (to avoid updating OCL along with Acceleo).
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #1011891 is a reply to message #1011849] |
Wed, 20 February 2013 12:42 |
|
Short version :
this was a bug in either OCL or EMF, fixed for Juno. If you cannot update to Juno, we'll have to try and understand _exactly_ what bug this was. I'll try and debug one of the failing instances.
Long version :
Following my first hunch, I repeated these very same steps with Indigo (3.7.2) but using the Acceleo update site instead of Kepler. This indeed resulted in the IllegalArgumentException you mentionned.
The only two bundles from OCL that were installed were the dependencies of Acceleo :
- org.eclipse.ocl 3.1.0_v20120206-0606
- org.eclipse.ocl.ecore 3.1.2_20111015-2027
This is what could be found by p2 without changing the update sites and leaving the "contact all update sites" box ticked when installing Acceleo. After this first "failing" test, I closed the two nested Eclipses and, in the first, I installed the OCL SDK 3.1.2 through the Indigo update site. Versions of OCL are now :
- org.eclipse.ocl 3.1.0_v20120206-0606 (unchanged)
- org.eclipse.ocl.doc 3.1.1_v20120206-0606
- org.eclipse.ocl.ecore 3.1.2_20111015-2027 (unchanged)
- org.eclipse.ocl.ecore.edit 3.1.0_20110526-1523
- org.eclipse.ocl.edit 3.1.0_v20120206-0606
- org.eclipse.ocl.uml 3.1.0_v20120206-0606
- org.eclipse.ocl.uml.edit 3.1.0_20110526-1523
This still fails in IllegalArgumentException.
Afterwards, I tried to update OCL through the OCL maintenance update site (Ed, I believe this is the correct update site for Juno SR2 release candidates)? However, OCL as a whole depends on UML, which evolved to 4.0 in Juno, and which in turn depends on EMF 2.8.
Acceleo only depends on the "ecore" part ... but the OCL update site does not allow us to avoid the UML dependency. As such, I needed to switch back to using the Juno update site in order to update the OCL End-User SDK to 4.0.2. After the update, your example works fine.
OCL versions range from 1.0.0 (? common and common UI) to 4.0.0 (for the UML support).
This is a bug in either EMF or OCL. It has been fixed for Juno, but I have no idea exactly how, or when. Some debugging might shed some light on this.
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #1011951 is a reply to message #1011891] |
Wed, 20 February 2013 15:22 |
|
Okay, the "bug was fixed in Juno" is wrong. All that's done in Juno is that OCL now ignores the failures silently (http://git.eclipse.org/c/mdt/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.ecore/src/org/eclipse/ocl/ecore/EcoreEvaluationEnvironment.java#n248).
What you have is basically EMF screwing us.
mm1.ecore references mm0.ecore through a "platform:/plugin" URI. Naturally, when OCL compiles the call to "aB.Attr", it references "Attr" through that same URI when compiling : platform:/plugin/org.example.mm0/model/mm0.ecore#//Z/Attr
The problem lies at compile time, because mm1.ecore references mm0 through "platform:/plugin" instead of referencing it through its NsURI.
The best workaround I can give you is to register the mapping from "platform:/plugin/org.example.mm0/model/mm0.ecore" to "http://example.org/mm0". i.e. if I add this in your Main#registerPackage() then the generation works resourceSet.getURIConverter().getURIMap().put(URI.createURI("platform:/plugin/org.example.mm0/model/mm0.ecore"), URI.createURI(Mm0Package.eNS_URI));
Ed, I think one of the EcorePlugin or EcoreUtil methods could do this automatically?
Laurent Goubet
Obeo
[Updated on: Wed, 20 February 2013 15:26] Report message to a moderator |
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #1011986 is a reply to message #1011951] |
Wed, 20 February 2013 16:22 |
Ed Willink
Messages: 7681
Registered: July 2009 |
Senior Member |
|
|
On 20/02/2013 15:22, Laurent Goubet wrote:
> Ed, I think one of the EcorePlugin or EcoreUtil methods could do this
> automatically?
Hi Laurent
Assuming you mean Ed W rather than Ed M, ...
From my comments on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=360926#c7, the default EMF
Eclipse-hosted (Acceleo compile/edit-time) behaviour is correct. All
URIs should be correctly normalized to the many locations underlying
platform:/resource and platform:/plugin
The problem arises through reuse of the same URIs in a standalone
environment. You must re-establish the same platform:/resource,
platform:/plugin normalization. Acceleo and other tools have heuristics
that make ../.. sort of work for the easy cases, but that make the
failures even worse and more obscure for the harder, particularly
multi-GIT cases.
I created StandaloneProjectMap to re-establish that normalization.
Subsequently, 27-Oct-2012, similar functionality has become available in
EcorePlugin.computePlatformURIMap and similar, so I strongly recommend
Acceleo to revisit all its URI heuristics, since with a correct
normalization, EMF URIs work beautifully rather than "basically EMF
screwing us". There is nothing fundamentally clever in
StandaloneProjectMap so it could easily be back-ported to support
Helios. EcorePlugin.computePlatformURIMap exploits a variety of minor
API relaxations that mandate the associated EMF classes.
Regards
Ed Willink
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #1012256 is a reply to message #1011986] |
Thu, 21 February 2013 08:03 |
|
Ed Willink wrote on Wed, 20 February 2013 11:22
> Ed, I think one of the EcorePlugin or EcoreUtil methods could do this
> automatically?
Hi Laurent
Assuming you mean Ed W rather than Ed M, ...
yup 
Ed Willink wrote on Wed, 20 February 2013 11:22
From my comments on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=360926#c7, the default EMF
Eclipse-hosted (Acceleo compile/edit-time) behaviour is correct. All
URIs should be correctly normalized to the many locations underlying
platform:/resource and platform:/plugin
The problem arises through reuse of the same URIs in a standalone
environment. You must re-establish the same platform:/resource,
platform:/plugin normalization. Acceleo and other tools have heuristics
that make ../.. sort of work for the easy cases, but that make the
failures even worse and more obscure for the harder, particularly
multi-GIT cases.
Though no one said anything about standalone here. The compilation occurs within Eclipse, the generation too. Both called from within running Eclipse bundles.
The problem here is that mm1.ecore references mm0.ecore through "platform:/plugin". When we load mm1.ecore, that reference is preserved as-is. However, EMF decides _not_ to use this kind of reference when it loads mm1.ecore as an EPackage itself. The reference, then, is made through the NsURI instead of the xmi's platform URI. How? It is established from the MM1PackageImpl#initializePackageContents() through this code
Mm0Package theMm0Package = (Mm0Package)EPackage.Registry.INSTANCE.getEPackage(Mm0Package.eNS_URI);
aEClass.getESuperTypes().add(theMm0Package.getZ());
instead of going through the "normal" resource set URI normalization.
Thus, we either :
- need a way to tell EMF that the "platform:/plugin" reference is equivalent to a given nsURI. That's one more "magic" conversion to add in the URIConverter, and seems sub-optimal. This is the workaround I proposed to Michael, and the easiest to set up.
- need to be able to tell Acceleo/OCL, at compile time, that it should use the NsURI instead of the platform:/plugin URI to reference metamodel artefacts. This seems like the best course of action.
Acceleo's "target" metamodel, in the current case, is mm2. mm2 references mm1 that in turn references mm0. All references are in the form of "platform" URIs. For the first (mm2 to mm1), both ecores are in the workspace. Acceleo already kicks in here to replace the platform/resource URI with the NsURI in the compiled emtl file. So that reference does not end in a metamodel being loaded twice. However, for the second (mm1 to mm0), mm0 lies in the plugins, and Acceleo does not force that (platform/plugin) URI into an nsURI... that might be where we should plug ourselves.
Laurent Goubet
Obeo
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #1012331 is a reply to message #1012256] |
Thu, 21 February 2013 11:10 |
Ed Willink
Messages: 7681
Registered: July 2009 |
Senior Member |
|
|
Hi Laurent
I think EMF is still consistent.
Anything that is loaded as compiled Java is referenced by nsURI.
Anything loaded as a *.ecore file is referenced as platform:/...
For Acceleo this should work provided the original import is
consistently platform:/... rather than an http:/... 'helpfully'
discovered to be platform:/...
I notice that one of my transformations is:
[module
org::eclipse::ocl::examples::build::acceleo::generateXBNF2LPG('http://www.eclipse.org/ocl/XBNF','http://www.eclipse.org/emf/2002/Ecore')/]
even though http://www.eclipse.org/ocl/XBNF has never been genmodelled.
IMHO this is a bug. I should have to specify
platform:/resource/org.eclipse.ocl.examples.xtext2lpg/model/XBNF.ecore.
IMHO it also unhelpful and wasteful for Accelo to scan *.ecore on the
classpath to discover possible nsURIs. At any rate Acceleo should be
aware that http://www.eclipse.org/ocl/XBNF was discovered in
platform:/resource/org.eclipse.ocl.examples.xtext2lpg/model/XBNF.ecore
and generate references accordingly.
<referredProperty xsi:type="ecore:EReference"
href="http://www.eclipse.org/ocl/XBNF#//Syntax/grammars"/>
is wrong. There is no Java-loadable http://www.eclipse.org/ocl/XBNF.
For code generation it can be more troublesome, a *.ecore is loaded and
converted to *.java. ProjectMap supports this by allowing a potentially
three-way metamodel schizophrenia between platform:/resource/...,
platform:/plugin/..., http:/... to be mediated by cross-mapping EPackage
registry entries. (The EcorePlugin enhancements don't support this.). So
for default usage, loading *.ecore with an nsURI that has a Java package
causes the Java package resource to be returned. With ProjectMap you
should only be able to have metamodel schizophrenia where you
specifically enable it.
Regards
Ed
On 21/02/2013 08:03, Laurent Goubet wrote:
> Ed Willink wrote on Wed, 20 February 2013 11:22
>> > Ed, I think one of the EcorePlugin or EcoreUtil methods could do
>> this > automatically?
>> Hi Laurent
>>
>> Assuming you mean Ed W rather than Ed M, ...
>
>
> yup :)
>
> Ed Willink wrote on Wed, 20 February 2013 11:22
>> From my comments on
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=360926#c7, the default
>> EMF Eclipse-hosted (Acceleo compile/edit-time) behaviour is correct.
>> All URIs should be correctly normalized to the many locations
>> underlying platform:/resource and platform:/plugin
>>
>> The problem arises through reuse of the same URIs in a standalone
>> environment. You must re-establish the same platform:/resource,
>> platform:/plugin normalization. Acceleo and other tools have
>> heuristics that make ../.. sort of work for the easy cases, but that
>> make the failures even worse and more obscure for the harder,
>> particularly multi-GIT cases.
>
>
> Though no one said anything about standalone here. The compilation
> occurs within Eclipse, the generation too. Both called from within
> running Eclipse bundles.
>
> The problem here is that mm1.ecore references mm0.ecore through
> "platform:/plugin". When we load mm1.ecore, that reference is
> preserved as-is. However, EMF decides _not_ to use this kind of
> reference when it loads mm1.ecore as an EPackage itself. The
> reference, then, is made through the NsURI instead of the xmi's
> platform URI. How? It is established from the
> MM1PackageImpl#initializePackageContents() through this code
>
> Mm0Package theMm0Package =
> (Mm0Package)EPackage.Registry.INSTANCE.getEPackage(Mm0Package.eNS_URI);
> aEClass.getESuperTypes().add(theMm0Package.getZ());
>
> instead of going through the "normal" resource set URI normalization.
>
> Thus, we either :
> - need a way to tell EMF that the "platform:/plugin" reference is
> equivalent to a given nsURI. That's one more "magic" conversion to add
> in the URIConverter, and seems sub-optimal. This is the workaround I
> proposed to Michael, and the easiest to set up.
> - need to be able to tell Acceleo/OCL, at compile time, that it should
> use the NsURI instead of the platform:/plugin URI to reference
> metamodel artefacts. This seems like the best course of action.
>
> Acceleo's "target" metamodel, in the current case, is mm2. mm2
> references mm1 that in turn references mm0. All references are in the
> form of "platform" URIs. For the first (mm2 to mm1), both ecores are
> in the workspace. Acceleo already kicks in here to replace the
> platform/resource URI with the NsURI in the compiled emtl file. So
> that reference does not end in a metamodel being loaded twice.
> However, for the second (mm1 to mm0), mm0 lies in the plugins, and
> Acceleo does not force that (platform/plugin) URI into an nsURI...
> that might be where we should plug ourselves.
>
> Laurent Goubet
> Obeo
|
|
| | |
| Re: [Acceleo] Invalid attributes during template invocation [message #1012813 is a reply to message #1012482] |
Fri, 22 February 2013 09:09 |
|
Michael,
No, this will still fail in later versions of Eclipse.
We will try to fix it in a future version of Acceleo; for now, you should avoid the situation where :
- you have the "target" metamodel of a generation in the workspace where you compile your module, and
- this "target" metamodel references another, that is itself located within the plugins and not in the workspace.
Laurent Goubet
Obeo
|
|
| |
| Re: [Acceleo] Invalid attributes during template invocation [message #1013065 is a reply to message #1013053] |
Fri, 22 February 2013 17:40 |
Ed Willink
Messages: 7681
Registered: July 2009 |
Senior Member |
|
|
Hi Michael
I fought against these problems, and mostly won, for some MDT/OCL
auto-generation where I had the extra challenge that I was
auto-generating new OCL from development OCL while Acceleo was executing
installed OCL.
It can be done, but you have to outwit Acceleo's helpful heuristics. My
main weapon was my ProjectMap class that eliminated the distinction
between the three forms of model reference. Thereafter a minor override
of some URL creation methods in the initialization and the problem was
solved.
You can find the relevant scripts in org.eclipse.ocl.examples.build.
Note that all the invocations are from MWE scripts, so what you find in
the auto-generated main's is only part of the story.
Don't even look at the code unless you are prepared to have a couple of
very trying days before you achieve success.
Regards
Ed Willink
On 22/02/2013 17:18, Michaël Melchiore wrote:
> Sadly, I think this situation is nearly unavoidable when designing
> frameworks with Acceleo as a code generation backend.
>
> As I understand it, Acceleo workflow naturally produces a significant
> amount of metamodels. Users are encouraged to build detailed
> metamodels to simplify template code. Moreover, different generation
> requirements should be adressed by refining metamodels.
>
> Finally, users are often required to subclass some public API classes
> to plug their work in the framework workflow.
>
>
> I have started the process of recreating the problematic situation in
> my product so that I can test your fix. I am running into transient
> compilation errors as Acceleo fails to load the plugin-contained
> metamodel. I have noticed the following changes seem to matter:
>
>
> in workspace metamodels, switch external metamodel imports between
> "../../*" and "platform:/resource|plugin" URI scheme
> on Acceleo projects, switch between"workspace relative" and "absolute
> file system" compilation path kind
>
> Could you provide me with some guidelines on those settings ? From
> Acceleo best practice pages, I just recall that all my Acceleo
> projects should be set to XMI module serialization format.
|
|
| | |
| Re: [Acceleo] Invalid attributes during template invocation [message #1015015 is a reply to message #1014849] |
Wed, 27 February 2013 08:22 |
|
Michael,
Quote:eProxyURI: platform:/plugin/org.example.mm0/model/mm0.ecore#//Z/Attr0
That would mean that what you registered
Quote:getURIMap.put(platformURI, NsUri)
does not correspond to the real URI : "platformURI", here, needs to be what you see as the "eProxyURI" (platform:/plugin/org.example.mm0/model/mm0.ecore). Can you double-check that?
Laurent Goubet
Obeo
|
|
| | | |
| Re: [Acceleo] Invalid attributes during template invocation [message #1015598 is a reply to message #1015389] |
Fri, 01 March 2013 10:37 |
|
Michaël,
Just double-checked from my end ... Seems like I had done something else when tinkering with your samples, since it indeed does not work. EMF will not use the normalized URI when checking if an URI is that of an ePackage in the resource resolution process.
So the only workaround for this is to change the way your models reference themselves, i.e. open "mm1.ecore" textually, and replace occurences of "platform:/plugin/org.example.mm0/model/mm0.ecore" with "http://example.org/mm0" (leave the fragments "#..." intact, only change the ecore URI). Ed mentionned that
Quote:href="http://www.eclipse.org/ocl/XBNF#//Syntax/grammars" is wrong. ... but that is exactly how EMF references metamodels, and it makes use of a specific handling for such URIs (which is part of why your use case is failing).
The only impact you will see after having done this is that when you open "mm1.ecore" in the ecore editor, you will not "see" a tree node for the "mm0" resource. It will remain hidden. That is the only change : you will still be able to reference parts of that other metamodel, you will still be able to edit and save your model. Once you've change the platform URI once, you won't have to do it again after edits. You will also need to recompile the mtl file since the references there will react to the change in mm1 too.
As I previously mentionned, we can implement changes in Acceleo to allow for this uses case without forcing this cumbersome workaround on you, but that is not a planned change yet.
Laurent Goubet
Obeo
|
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #1016033 is a reply to message #1015598] |
Mon, 04 March 2013 16:20 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
Laurent,
The proposed fix prevents me from reloading the "mm1.genmodel" file. I get the following exception:
java.lang.reflect.InvocationTargetException
at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:121)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:464)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:372)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1008)
at org.eclipse.emf.converter.ui.contribution.base.ModelConverterWizard.performFinish(ModelConverterWizard.java:246)
at org.eclipse.emf.importer.ui.contribution.base.ModelImporterWizard.performFinish(ModelImporterWizard.java:157)
at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:811)
at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:430)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3540)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3161)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:825)
at org.eclipse.jface.window.Window.open(Window.java:801)
at org.eclipse.ui.internal.handlers.WizardHandler$New.executeHandler(WizardHandler.java:254)
at org.eclipse.ui.internal.handlers.WizardHandler.execute(WizardHandler.java:274)
at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508)
at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169)
at org.eclipse.ui.internal.handlers.SlaveHandlerService.executeCommand(SlaveHandlerService.java:241)
at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:157)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3540)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3161)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2640)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2438)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:664)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
at org.eclipse.equinox.launcher.Main.main(Main.java:1384)
Caused by: org.eclipse.core.runtime.CoreException: An error occurred while performing this operation.
at org.eclipse.emf.common.util.DiagnosticException.toCoreException(DiagnosticException.java:47)
at org.eclipse.emf.converter.ui.contribution.base.ModelConverterWizard$1.execute(ModelConverterWizard.java:235)
at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118)
... 51 more
Caused by: org.eclipse.emf.common.util.DiagnosticException: An error occurred while performing this operation.
at org.eclipse.emf.converter.ui.contribution.base.ModelConverterWizard$1.execute(ModelConverterWizard.java:234)
... 54 more
Caused by: java.io.IOException: PUT failed with HTTP response code 503
at org.eclipse.emf.ecore.resource.impl.URIHandlerImpl$1.close(URIHandlerImpl.java:129)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.saveOnlyIfChangedWithMemoryBuffer(ResourceImpl.java:1223)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.save(ResourceImpl.java:980)
at org.eclipse.emf.importer.ModelImporter.saveGenModelAndEPackages(ModelImporter.java:769)
at org.eclipse.emf.importer.ui.contribution.base.ModelImporterWizard.doPerformFinish(ModelImporterWizard.java:150)
at org.eclipse.emf.converter.ui.contribution.base.ModelConverterWizard$1.execute(ModelConverterWizard.java:228)
... 54 more [Updated on: Mon, 04 March 2013 16:34] Report message to a moderator |
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #1016048 is a reply to message #1016033] |
Mon, 04 March 2013 17:41 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
The proposed fix does solve my problem on a confined test case: a specific generator of my framework ported to Acceleo 3.
But, as I said in my previous port, the "URI switch" also prevents every directly or indirectly depending genmodel from being synchronized w.r.t to their metamodels.
I think Acceleo 3 could improve on the issues my team currently faces when maintaining or adding features in our software. Currently, I have small internal test projects which I use to build a more educated opinion on your technology. Ideally, I would like Acceleo 3 to support the next major release of our framework.
Considering the issues I keep running into since last year, I am growing more and more hesitant to port more ambitious code generators....
For now, the trick is to apply the "URI switch" after all genmodel have been synchronized and model java classes generated
[Updated on: Mon, 04 March 2013 17:44] Report message to a moderator |
|
|
| Re: [Acceleo] Invalid attributes during template invocation [message #1016155 is a reply to message #1016048] |
Tue, 05 March 2013 09:42 |
|
Michael,
Changing the URI "textually" did not prevent me from doing anything with the model, I must admit I did not test with a genmodel, though I do not really understand why that would fail.
As mentionned, this is something Acceleo can fix. I only tried to find a workaround you could use for now, seems like there aren't any viable ones.
Laurent Goubet
Obeo
|
|
| |
| Re: [Acceleo] Invalid attributes during template invocation [message #1016442 is a reply to message #1016383] |
Wed, 06 March 2013 13:25 |
Michaël Melchiore
Messages: 47
Registered: April 2012 |
Member |
|
|
Stephane,
I have installed the integration update site, upgrading my Acceleo installtion from 3.3.2 to 3.4.x. I have also followed your advice and taken special care of my metamodel dependencies. Here is my dependency structure
MM1 (contained in an installed plugin)
MM2 (in workspace)
requires MM1
MM3 (in workspace)
requires MM2, MM1
MM3.m2t (in workspace)
requires MM3
Now, I get compile time errors in the editors: every use of Attr1 et Attr2 is detected as an "Unrecognized variable" error. I still think this is an improvement because errors are now detected before runtime and reliably (every use of Attr1 and Attr2 in every project triggers an error).
A small question: in your template, you have referenced all three metamodels. Am I correct to think that only MM3 is required (provided all dependencies are properly set in plugins) ?
Regards,
Michaël
[Updated on: Wed, 06 March 2013 16:14] Report message to a moderator |
|
| | |
| Re: [Acceleo] Invalid attributes during template invocation [message #1017780 is a reply to message #1017762] |
Tue, 12 March 2013 14:26 |
|
Hi again,
So the use case where I could reproduce your issue involved the following situation. We are loading mm3 since it is a project dependency of our project (using the MANIFEST.MF) located in the workspace, but mm3 is referencing mm2 with the following relative path "../../mm2/model/mm2.ecore" whle we had loaded mm2 thanks to the following workspace relative path (/mm2/model/mm2.ecore), in a similar fashion we could have a problem finding mm1. This fix improves the consistency of our own package registry regarding metamodels in the workspace with dependencies to other metamodels. The new fix also improves Ctrl+click on attributes, references and variable declarations for types located in metamodels in the workspace (in my previous screenshot, Ctrl+clicking on 'AttrX' and 'aC : C').
The new build can be found on this update site. Tell me if this new build fixes all your problems regarding to this situation. Thanks.
Regards,
Stephane Begaudeau, Obeo
--
Twitter: @sbegaudeau
Google+: +stephane.begaudeau
Blog: http://stephanebegaudeau.tumblr.com | Eclipse Java Development Tools Tips and Tricks
|
|
| | |
| Re: [Acceleo] Invalid attributes during template invocation [message #1017825 is a reply to message #1017800] |
Tue, 12 March 2013 15:54 |
|
Hi,
This fix will be available in Acceleo 3.4.0 which will be release at the end of June. I will backport it on Acceleo 3.3 to make a new release for Acceleo 3.3.3 this week. If you need this fix as soon as possible, you can use the integration build of Acceleo 3.4.0 that I gave you since it contains almost no changes from Acceleo 3.3.2 released last month. We have just changed the way, Acceleo modules wrapping Java services are automatically generated by the new module wizard (nothing to worry about for your need here). If it's not critical, you could wait for Acceleo 3.3.3 which should be released this week. Given the minimal difference between the two version, I would personnaly just use the integration build of Acceleo 3.4.0.
Regards,
Stephane Begaudeau, Obeo
--
Twitter: @sbegaudeau
Google+: +stephane.begaudeau
Blog: http://stephanebegaudeau.tumblr.com | Eclipse Java Development Tools Tips and Tricks
|
|
| | | |
Goto Forum:
Current Time: Mon Dec 30 14:33:49 GMT 2024
Powered by FUDForum. Page generated in 0.12119 seconds |
] 
Search
Help
Register
Login
Home
