Eclipse Community Forums: M2T (model-to-text transformation) » [Acceleo] Invalid attributes during template invocation

Home

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 09:52

Eclipse User

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 15:56

Eclipse User

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 03:39

Eclipse User

Hi,

I'll be a little picky ...

Ed Willink wrote on Wed, 07 November 2012 15:56

Acceleo'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 Razz

). 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 05:07

Eclipse User

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 05:44] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #976114 is a reply to message #976005]

Thu, 08 November 2012 05:18

Eclipse User

Hi Laurent
>> Acceleo's messages are not always perfect.
> You do realize that this error stems from OCL?
Indeed, OCL's 'invalid' leaves a lot to be desired.
> It would probably be better if OCL encapsulated the exceptions in a
> more specific sub-class to allow for safer catches/better error messages.
The new Pivot-based Eclipse OCL implementation ignores the
over-interpretation of 'invalid' as a singleton. Instead, 'invalid' is
normally propagated as a (nest of) InvalidValueException, when the cause
is something sensibly detected by OCL such as an illegal index for
Sequence::at(), or as a Java exception, for something beyond OCL such as
a StackOverflow. When the exception is reified as an InvalidValueImpl,
the InvalidValueImpl is just a wrapper for the exception.

For the particular case of navigation from a non-EObject, it would seem
that something is not well-formed so either
- validation of the Acceleo/OCL template was inadequate
- the source of the non-EObject failed to validate the cast when passing
an EObject parameter
In either case it is not clear that OCL evaluation should be burdened by
'redundant' well-formedness checks, so a default CCE would seem reasonable.

Regards

Ed Willink

Re: [Acceleo] Invalid attributes during template invocation [message #976162 is a reply to message #976114]

Thu, 08 November 2012 06:06

Eclipse User

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 07:15] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #976259 is a reply to message #976162]

Thu, 08 November 2012 07:37

Eclipse User

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 08:10

Eclipse User

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 08:15] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #976344 is a reply to message #976289]

Thu, 08 November 2012 09:02

Eclipse User

Hi

In your presentation you simplified. You can therefore produce a
correspondingly simple zipped project that reproduces the problem, and
so we can investigate and help, or you fail to reproduce and maybe gain
some insight into what your actual problem is.

Regards

Ed Willink

On 08/11/2012 13:10, Michaël Melchiore wrote:
> 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". My real template involves the same
> class hierarchy and the same three String attributes.
> I should have mentionned that A is abstract but I noticed it recently
> while investing 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.

Re: [Acceleo] Invalid attributes during template invocation [message #976393 is a reply to message #976344]

Thu, 08 November 2012 09:50

Eclipse User

I have installed OCL and Acceleo SDK to be able to step through the code of PropertyCallExpImpl.accept.

The IllegalArgumentException is thrown by the EcoreEvaluationEnvironment.navigateProperty(EStructuralFeature property, List<?> qualifiers, Object target) method.

"target" is an instance of EObject, but "property" is not listed in "target" eClass structural features on line 221. Indeed, the looked-up "property" is "A.Attr1". But the look-up is performed on C structural features and "A.Attr1" != "C.Attr1".

I will try to create a small test case to reproduce the behavior, but now the root of the problem is identified.

Re: [Acceleo] Invalid attributes during template invocation [message #976405 is a reply to message #976393]

Thu, 08 November 2012 09:57

Eclipse User

Hi

C.Attr1 is indeed not equal to A.Attr1.

In UML/Ecore/Java/C++,... operations exhibit polymorphic overriding but
properties/features/attributes/fields/member variables are cumulative.

Seems like your exception was that navigation from the 'wrong' Attr1
tried to navigate from null which results in the invalid.

Regards

Ed Willink

On 08/11/2012 14:50, Michaël Melchiore wrote:
> I have installed OCL and Acceleo SDK to be able to step through the
> code of PropertyCallExpImpl.accept.
>
> The IllegalArgumentException is thrown by the
> EcoreEvaluationEnvironment.navigateProperty(EStructuralFeature
> property, List<?> qualifiers, Object target) method.
> "target" is an instance of EObject, but "property" is not listed in
> "target" eClass structural features on line 221. Indeed, the looked-up
> "property" is "A.Attr1". But the look-up is performed on C structural
> features and "A.Attr1" != "C.Attr1".
>
> I will try to create a small test case to reproduce the behavior, but
> now the root of the problem is identified.
>
>
>
>

Re: [Acceleo] Invalid attributes during template invocation [message #976484 is a reply to message #976405]

Thu, 08 November 2012 11:09

Eclipse User

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

Attachment: test-case-code.tar.gz
(Size: 190.78KB, Downloaded 436 times)
Attachment: test-case-model.tar.gz
(Size: 0.90KB, Downloaded 375 times)

Re: [Acceleo] Invalid attributes during template invocation [message #976501 is a reply to message #976484]

Thu, 08 November 2012 11:20

Eclipse User

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 #976545 is a reply to message #976501]

Thu, 08 November 2012 12:07

Eclipse User

I have further compared the working case and the faulty one.

In both, the looked-up property belong to the EClass where the feature is actually defined.

In the working case though, A.Attr1 and C.Attr1 properties share the same identity (java id).
In the faulty one, A.Attr1 and C.Attr1 properties are equal but have different java id

Interestingly, the BasicEList.contains(Object object) method can operate using both, but identity is much cheaper to check for and is the chosen way in my case.

I will ultimately proceed as you suggest but this a very time-demanding effort. If someone is inspired by my findings, please step up Shocked

Re: [Acceleo] Invalid attributes during template invocation [message #977321 is a reply to message #976545]

Fri, 09 November 2012 02:20

Eclipse User

Hi

You keep making vague statements. 'identity is much cheaper' that
indicate where some issue might arise.

Only someone capable of remote code viewing could possibly step up to
help you since you have kept secret all relevant details.

Bug search by 'binary' reduction is indeed time-consuming, but I do it
regularly to identify my own and other peoples problems. Welcome to the
club.

Regards

Ed Willink

On 08/11/2012 17:07, Michaël Melchiore wrote:
> I have further compared the working case and the faulty one.
>
> In both, the looked-up property belong to the EClass where the feature
> is actually defined.
>
> In the working case though, A.Attr1 and C.Attr1 properties share the
> same identity (java id).
> In the faulty one, A.Attr1 and C.Attr1 properties are equal but have
> different java id
>
>
> Interestingly, the BasicEList.contains(Object object) method can
> operate using both, but identity is much cheaper to check for and is
> the chosen way in my case.
>
> I will ultimately proceed as you suggest but this a very
> time-demanding effort. If someone is inspired by my findings, please
> step up 8o
>

Re: [Acceleo] Invalid attributes during template invocation [message #977447 is a reply to message #977321]

Fri, 09 November 2012 04:43

Eclipse User

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)

Attachment: eclipse-0-projects.zip
(Size: 38.25KB, Downloaded 346 times)
Attachment: eclipse-2-projects.zip
(Size: 2.57KB, Downloaded 345 times)
Attachment: eclipse-1-projects.zip
(Size: 337.66KB, Downloaded 406 times)

[Updated on: Tue, 04 December 2012 08:40] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #989013 is a reply to message #977447]

Tue, 04 December 2012 05:29

Eclipse User

Hi,

Any news regarding my problem ? Does the submitted test case successfully reproduce the issue ?

Regards,

Michaël

Re: [Acceleo] Invalid attributes during template invocation [message #989021 is a reply to message #989013]

Tue, 04 December 2012 05:41

Eclipse User

Hi

My Thunderbird newsgroup client shows no earlier message from you. Try
reposting.

Regards

Ed Willink

On 04/12/2012 10:29, Michaël Melchiore wrote:
> Hi,
>
> Any news regarding my problem ? Does the submitted test case
> successfully reproduce the issue ?
>
> Regards,
>
> Michaël

Re: [Acceleo] Invalid attributes during template invocation [message #989027 is a reply to message #989021]

Tue, 04 December 2012 05:55

Eclipse User

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)

Attachment: eclipse-0-projects.zip
(Size: 38.25KB, Downloaded 369 times)
Attachment: eclipse-2-projects.zip
(Size: 2.57KB, Downloaded 385 times)
Attachment: eclipse-1-projects.zip
(Size: 337.66KB, Downloaded 421 times)

[Updated on: Tue, 04 December 2012 08:39] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #989028 is a reply to message #989027]

Tue, 04 December 2012 05:55

Eclipse User

Done, there are 3 attachments in the reposted messages.

Regards,

Michaël

Re: [Acceleo] Invalid attributes during template invocation [message #989034 is a reply to message #989028]

Tue, 04 December 2012 06:18

Eclipse User

Hi

Apologies for the confusion. Your correspondence demonstrates some solid
evidence of the malfunctioning of the newsgroup/forum synchronization.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=395687 raised; maybe
someone'll manage to fix it now.

FYI: many/most Eclipse committers only look at the newsgroup view of the
forum.

I'll try to take a look at the projects.

Regards

Ed Willink

On 04/12/2012 10:55, Michaël Melchiore wrote:
> Done, there are 3 attachments in the reposted messages.
>
> Regards,
>
> Michaël

Re: [Acceleo] Invalid attributes during template invocation [message #989044 is a reply to message #989013]

Tue, 04 December 2012 07:22

Eclipse User

Hi

I downloaded the projects and using my current Kepler M3 workspace, I
see no problems but I don't know what I'm looking for. Your problem
changed a few times during the thread.

You appear to have a problem in the first nested Eclipse, so I don't
understand why you provide a ZIP for a nested-nested Eclipse.

In the first nested Eclipse I don't see why you provide a copy of
org.eclipse.ocl.ecore. Is it modified, am I expected to test it to find
out why it's there?

You provide many more plugins than are necessary; surely the *.edit and
*.editor plugins do not contribute to the problem.

Your introductory comment "I have finally managed to reproduce the
problem. The key is to have the root metamodel installed in Eclipse."
spurred me to try and help since you've clearly tried and successfully
identified a significant factor in the reproducibility. My instinctive
reaction to your comment is that this now looks like an Acceleo package
registration issue rather than an OCL name lookup issue, but without
actually seeing any problem it's a bit of a guess.

Regards

Ed Willink

On 04/12/2012 10:29, Michaël Melchiore wrote:
> Hi,
>
> Any news regarding my problem ? Does the submitted test case
> successfully reproduce the issue ?
>
> Regards,
>
> Michaël

Re: [Acceleo] Invalid attributes during template invocation [message #989053 is a reply to message #989044]

Tue, 04 December 2012 08:09

Eclipse User

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 #989069 is a reply to message #989053]

Tue, 04 December 2012 08:56

Eclipse User

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 #989077 is a reply to message #989069]

Tue, 04 December 2012 09:36

Eclipse User

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 10:05

Eclipse User

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 10:07] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #997699 is a reply to message #989084]

Tue, 08 January 2013 10:11

Eclipse User

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 10:24] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #1011849 is a reply to message #997699]

Wed, 20 February 2013 06:11

Eclipse User

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 07:42

Eclipse User

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 10:22

Eclipse User

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

. However, when loading the model later on, it references its metamodel through the "normal" way, the NsURI. Then, we end up with Ed's beloved "metamodel schyzophrenia" : MM0 is loaded through two distinct means : the module references it as "platform:/plugin/org.example.mm0/model/mm0.ecore", the model references it through "http://example.org/mm0". This never ends well.

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 10:26] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #1011986 is a reply to message #1011951]

Wed, 20 February 2013 11:22

Eclipse User

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 03:03

Eclipse User

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 06:10

Eclipse User

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 #1012391 is a reply to message #1012331]

Thu, 21 February 2013 08:30

Eclipse User

This is deviating from the original subject, and will most likely end up in a stalemate.

To sum this up, Michael, the easiest workaround for you is to setup the URI mapping between the "platform:/plugin/<metamodel>" URI and its NsURI. This should solve all issues you have with your generation.

Laurent Goubet
Obeo

Re: [Acceleo] Invalid attributes during template invocation [message #1012482 is a reply to message #1012391]

Thu, 21 February 2013 11:38

Eclipse User

Thank you for help Laurent. I will try the suggested fix as soon as I can find the time.

I do not understand if the problem is fixed in later versions of Eclipse?

Re: [Acceleo] Invalid attributes during template invocation [message #1012813 is a reply to message #1012482]

Fri, 22 February 2013 04:09

Eclipse User

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 #1013053 is a reply to message #1012813]

Fri, 22 February 2013 12:18

Eclipse User

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 #1013065 is a reply to message #1013053]

Fri, 22 February 2013 12:40

Eclipse User

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 #1014849 is a reply to message #1013065]

Tue, 26 February 2013 10:34

Eclipse User

Hi,

I have finished recreating the situation in my "real" code with the suggested workaround (...getURIMap.put(platformURI, NsUri) in the Acceleo generated java file). I am running on Linux:
- Eclipse 3.6.2
- EMF 2.6.1
- Acceleo 3.3.2.v201302130808 (updated)

I still get java.lang.IllegalArgumentException thrown when trying to access fields that are defined in the plugin-contained metamodel.

I have put a breakpoint in Acceleo where the exception is thrown (just before OCL invocation: AcceleoEvaluationVisitor on line 1904). I do not know if this is helpful but here is what I get from the debugger:

expression (self.null): PropertyCallExpImpl
- referredProperty: org.eclipse.emf.ecore.impl.EAttributeImpl@3c37114f (eProxyURI: platform:/plugin/org.example.mm0/model/mm0.ecore#//Z/Attr0)

Re: [Acceleo] Invalid attributes during template invocation [message #1014869 is a reply to message #1014849]

Tue, 26 February 2013 11:04

Eclipse User

Hi

Yes: eProxyURI is very smelly.

You have almost certainly failed to ensure that MM0 is registered in a
way that corresponds to its plugin:/... references.

Regards

Ed Willink

On 26/02/2013 15:34, Michaël Melchiore wrote:
> Hi,
>
> I have finished recreating the situation in my "real" code with the
> suggested workaround (...getURIMap.put(platformURI, NsUri) in the
> Acceleo generated java file). I am running on Linux:
> - Eclipse 3.6.2
> - EMF 2.6.1
> - Acceleo 3.3.2.v201302130808 (updated)
>
> I still get java.lang.IllegalArgumentException thrown when trying to
> access fields that are defined in the plugin-contained metamodel.
>
> I have put a breakpoint in Acceleo where the exception is thrown (just
> before OCL invocation: AcceleoEvaluationVisitor on line 1904). I do
> not know if this is helpful but here is what I get from the debugger:
>
> expression (self.null): PropertyCallExpImpl
> - referredProperty:
> mailto:org.eclipse.emf.ecore.impl.EAttributeImpl@3c37114f (eProxyURI:
> platform:/plugin/org.example.mm0/model/mm0.ecore#//Z/Attr0)
>
>

Re: [Acceleo] Invalid attributes during template invocation [message #1015015 is a reply to message #1014849]

Wed, 27 February 2013 03:22

Eclipse User

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 #1015066 is a reply to message #1015015]

Wed, 27 February 2013 05:56

Eclipse User

Hi,

Thank you both four your replies.

The URI string was correct. I triple checked by copying it straight from the debugger.

Re: [Acceleo] Invalid attributes during template invocation [message #1015389 is a reply to message #1015066]

Thu, 28 February 2013 08:12

Eclipse User

It may not be clear from my previous message, but I am still stuck with java.lang.IllegalArgumentException. So, I am more than ever open to suggestions.

Michaël

Re: [Acceleo] Invalid attributes during template invocation [message #1015572 is a reply to message #1015389]

Fri, 01 March 2013 04:14

Eclipse User

Hi

As I wrote before:

/Yes: eProxyURI is very smelly.

You have almost certainly failed to ensure that MM0 is registered in a
way that corresponds to its plugin:/... references. /

So if you are unable to resolve the problem by analysis you have to
resolve it by debugging.

In EcoreUtil.resolve(EObject proxy, ResourceSet resourceSet)

set a breakpoint on the second

resolvedObject = resourceSet.getEObject(proxyURI, false);

and see why the retry fails.

Regards

Ed Willink

On 28/02/2013 13:12, Michaël Melchiore wrote:
> It may not be clear from my previous message, but I am still stuck
> with java.lang.IllegalArgumentException. So, I am more than ever open
> to suggestions.
>
> Michaël

Re: [Acceleo] Invalid attributes during template invocation [message #1015598 is a reply to message #1015389]

Fri, 01 March 2013 05:37

Eclipse User

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 11:20

Eclipse User

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 11:34] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #1016048 is a reply to message #1016033]

Mon, 04 March 2013 12:41

Eclipse User

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 12:44] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #1016155 is a reply to message #1016048]

Tue, 05 March 2013 04:42

Eclipse User

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 #1016383 is a reply to message #1016155]

Wed, 06 March 2013 05:15

Eclipse User

Hi Michaël Melchiore,

I have contributed a fix for your issue and I have tested it on Eclipse 3.6 and 3.7.

https://lh6.googleusercontent.com/-MDXt1xvC364/UTcVjUcMqgI/AAAAAAAANqE/v7ksF_bRcJY/s600/Fix.png

By the way, upon investigation, I've seen that if the MANIFEST.MF of your project does not contain any dependencies to the plug-ins containing your dependencies (which seems to be the case in the first projects that you had attached) our fix cannot work (since our builder can't compute all the meta-models that should be registered in our dedicated package registry).

An integration build containing the fix is available on this update site.

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 #1016442 is a reply to message #1016383]

Wed, 06 March 2013 08:25

Eclipse User

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 11:14] by Moderator

Re: [Acceleo] Invalid attributes during template invocation [message #1016525 is a reply to message #1016442]

Wed, 06 March 2013 13:51

Eclipse User

Hi,

Quote:

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)?

It is strongly recommended to use all three.

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 #1017762 is a reply to message #1016442]

Tue, 12 March 2013 09:48

Eclipse User

Hi,

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).

I have successfully found a use case in which I can reproduce your issue. I am working on it.

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 #1017780 is a reply to message #1017762]

Tue, 12 March 2013 10:26

Eclipse User

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 #1017785 is a reply to message #1017780]

Tue, 12 March 2013 10:38

Eclipse User

I am on it. Expect an update soon

Re: [Acceleo] Invalid attributes during template invocation [message #1017800 is a reply to message #1017780]

Tue, 12 March 2013 11:04

Eclipse User

I confirm this build fixes every problem I reported in this thread.

Will you release a new version or should I deploy the fix in my team using the hudson release site?

It has been a long road, thanks a bunch.

Michaël

Re: [Acceleo] Invalid attributes during template invocation [message #1017825 is a reply to message #1017800]

Tue, 12 March 2013 11:54

Eclipse User

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

Re: [Acceleo] Invalid attributes during template invocation [message #1017841 is a reply to message #1017825]

Tue, 12 March 2013 12:15

Eclipse User

I will wait for 3.3.3 then.

I want to be able to enforce in my generators a minimal Acceleo version range that guarantees your fix is deployed in my colleagues' environments. If not , my generators will not compile. Simple and yet, safe.

Regards,

Michaël

Re: [Acceleo] Invalid attributes during template invocation [message #1018781 is a reply to message #1017841]

Thu, 14 March 2013 09:13

Eclipse User

Hi,

We have released Acceleo 3.3.3 and it is now available on the Acceleo 3.3.x update site: http://download.eclipse.org/modeling/m2t/acceleo/updates/releases/3.3

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 #1018815 is a reply to message #1018781]

Thu, 14 March 2013 10:21

Eclipse User

Thanks, I am currently deploying it.

Michaël

[Updated on: Thu, 14 March 2013 10:32] by Moderator

Previous Topic:	target folder from mtl file
Next Topic:	[Acceleo] How to make a type cast?

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Mar 26 04:27:00 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter