Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » [Acceleo 3] Casting to supertype necessary!
[Acceleo 3] Casting to supertype necessary! [message #646490] Sat, 25 December 2010 13:28 Go to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
Hello,

you can reproduce this issue following these steps (using Helios/Indigo and Acceleo 3.0.1).

Create this meta model:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="MyModel"
    nsURI="http://my" nsPrefix="my">
  <eClassifiers xsi:type="ecore:EClass" name="ClassEx" eSuperTypes="platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Class">
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="ex" eType="ecore:EDataType platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Integer"/>
  </eClassifiers>
</ecore:EPackage>


Create Genmodel and create "model", "edit" and "editor"
Deploy and install meta model as plug-in and restart Eclipse.

We consider the following model now.

<?xml version="1.0" encoding="ASCII"?>
<uml:Model xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:my="http://my" xmlns:uml="http://www.eclipse.org/uml2/3.0.0/UML" name="My Model">
  <packagedElement xsi:type="uml:Class" name="NameClass"/>
  <packagedElement xsi:type="my:ClassEx" name="NameClassEx" ex="3"/>
</uml:Model>


I would expect that the following Acceleo transformation works:

[comment encoding = UTF-8 /]
[module generate('http://www.eclipse.org/uml2/3.0.0/UML', 'http://my')/]

[template public generate(m : Model)]
	
	[comment @main /]
	
	[for (e : my::ClassEx | m.allOwnedElements()->select( oclIsKindOf(my::ClassEx) ) )]
	  [file (e.name.concat('.java'), false, 'UTF-8')]
	    [e.name /]
	    [e.ex /]
	  [/file]
	[/for]
	
[/template]


It does not work. However, it can be changed in order that it works. Somehow, it seems that objects have to be casted to the types of the according meta model. If I have "my::ClassEx", I have to cast to "uml::Class" in order to get the UML attributes. If I have "uml::Class", I have to cast to "my:ClassEx" in order to access its attribute "ex". The following to examples work:

	[for (e : my::ClassEx | m.allOwnedElements()->select( oclIsKindOf(my::ClassEx) ) )]
	  [file (e.oclAsType(uml::Class).name.concat('.java'), false, 'UTF-8')]
	    [e.oclAsType(uml::Class).name /]
	    [e.ex /]
	  [/file]
	[/for]


or

	[for (e : uml::Class | m.allOwnedElements()->select( oclIsKindOf(my::ClassEx) ) )]
	  [file (e.name.concat('.java'), false, 'UTF-8')]
	    [e.name /]
	    [e.oclAsType(my::ClassEx).ex /]
	  [/file]
	[/for]


I guess, that this is an issue which must be resolved?

BTW: With Acceleo 3.1.0M4 the example does not work at all. The loop is never entered, the file never created.

[Updated on: Sat, 25 December 2010 14:31]

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #646733 is a reply to message #646490] Thu, 30 December 2010 16:19 Go to previous messageGo to next message
Stephane Begaudeau is currently offline Stephane BegaudeauFriend
Messages: 458
Registered: April 2010
Location: Nantes (France)
Senior Member
Hi Vultur,

>> I guess, that this is an issue which must be resolved?

Not really, this is the correct behavior, let me explain why and how to improve your code. You have with "m.allOwnedElements()" a collection of Element. With select it will return a collection of the same type which means that even if you know without any single doubt that " m.allOwnedElements()->select( oclIsKindOf(my::ClassEx)" is a collection of ClassEx it is in fact a collection of Element with instances of ClassEx inside and just like in Java if you want to manipulate those instances as ClassEx, you have to cast them. And this is the intended behavior.

http://lh5.ggpht.com/_R0aPxLxg16E/TRytrO-MIII/AAAAAAAAAFA/UjmSJAnNbTw/Java.png

With Acceleo 3.1M5 we will have an improved warning system that will warn you when we find some possible incompatibilities between your types, and as you can see a code similar to yours would produce a warning:

http://lh3.ggpht.com/_R0aPxLxg16E/TRytro9AYuI/AAAAAAAAAFE/Vx93fHd8ejc/AcceleoWarning.png
Possible incompatible type between 'Image' and 'Set(Element)'.


But since this a problem that is often encountered, we choose to add a new operations to handle this problem. And this is the solution I would recommend you. Filter is just a simple way to write "select(e | e.oclIsKindOf(type)).oclAsType(type)."

http://lh4.ggpht.com/_R0aPxLxg16E/TRytrixVLUI/AAAAAAAAAFI/m2Qe0MAlFMM/AcceleoFilter.png

If you need more informations about the available operation you can use:
- the OCL operation reference: http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse. acceleo.doc/doc/html/ocl_operation_reference.html
- the Acceleo operation reference: http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse. acceleo.doc/doc/html/acceleo_operation_reference.html

Stephane Begaudeau, Obeo.

[Updated on: Thu, 30 December 2010 16:20]

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #646849 is a reply to message #646733] Sat, 01 January 2011 13:04 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
Hi Stephane,

thanks for your nice reply. Your explanation makes sense. However, and that's why I am totally confused, I cannot reconstruct the behavior of Acceleo completely.

Please have a look:

	[for (e : uml::Class | m.allOwnedElements()->select( oclIsKindOf(my::ClassEx) ) )]
	  [file (e.oclAsType(uml::NamedElement).name.concat('.java'), false, 'UTF-8')]
	    [e.name /]
	  [/file]
	[/for]


	[for (e : my::ClassEx | m.allOwnedElements()->select( oclIsKindOf(my::ClassEx) ) )]
	  [file (e.oclAsType(uml::NamedElement).name.concat('.java'), false, 'UTF-8')]
	    [e.name /]
	  [/file]
	[/for]


I know that I should use "uml::Element", because this is returned by "allOwnedElements()". BUT, the first example WORKS. The second does not! And such things are confusing me.

The first example creates a file with

	    NameClassEx


The second example creates a file with

	    org.eclipse.emf.ecore.impl.DynamicEObjectImpl@1884a40 (eClass: org.eclipse.emf.ecore.impl.EClassImpl@c2ee15 (name: OclInvalid_Class) (instanceClassName: null) (abstract: false, interface: false))


Something, I have learned now and is very interesting:
BOTH examples work, if I don't deploy my model plug-in. If I "start" my editor plug-in as "Eclipse application" and the Acceleo transformation there, I don't have problems!?!?

I am really very confused Sad

BTW: I cannot use Acceleo 3.1.0 with my example at all (don't know what's going wrong!). Therefore, I am still using 3.0.1.

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #646850 is a reply to message #646849] Sat, 01 January 2011 13:22 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
I also want to add the following:

	[for (e : my::ClassEx | m.allOwnedElements()->select( oclIsKindOf(my::ClassEx) ).oclAsType(my::ClassEx) )]
	  [file (e.oclAsType(uml::NamedElement).name.concat('.java'), false, 'UTF-8')]
	    [e.name /]
	    [e.ex /]
	  [/file]
	[/for]


As you can see, I actually cast to "my:ClassEx" in this example. It creates the following file:

	     org.eclipse.emf.ecore.impl.DynamicEObjectImpl@1fe8ce8 (eClass: org.eclipse.emf.ecore.impl.EClassImpl@d4d66b (name: OclInvalid_Class) (instanceClassName: null) (abstract: false, interface: false))
	    3


You see, that this "problem" is not directly related to your post.

The example only works, if I cast to the supertype "uml::Class" explicitly.

	    [e.oclAsType(uml::Class).name /]

[Updated on: Sat, 01 January 2011 13:25]

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #646851 is a reply to message #646849] Sat, 01 January 2011 13:39 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Vultur

org.eclipse.emf.ecore.impl.DynamicEObjectImpl@1884a40 (eClass:
org.eclipse.emf.ecore.impl.EClassImpl@c2ee15 (name: OclInvalid_Class)
(instanceClassName: null) (abstract: false, interface: false))

is Eclipse OCL's very inelegant way of describing the 'invalid' object.
It lacks a decent toString() override.
(Bugzilla already raised.)

You are getting invalid since presumably my::ClassEx does not conform to
uml::NamedElement, whereas of course uml::Class does.

Regards

Ed Willink


On 01/01/2011 13:04, vultur wrote:
> Hi Stephane,
>
> thanks for your nice reply. Your explanation makes sense. However, and
> that's why I am totally confused, I cannot reconstruct the behavior of
> Acceleo completely.
> Please have a look:
>
> [for (e : uml::Class | m.allOwnedElements()->select(
> oclIsKindOf(my::ClassEx) ) )]
> [file (e.oclAsType(uml::NamedElement).name.concat('.java'),
> false, 'UTF-8')]
> [e.name /]
> [/file]
> [/for]
>
> [for (e : my::ClassEx | m.allOwnedElements()->select(
> oclIsKindOf(my::ClassEx) ) )]
> [file (e.oclAsType(uml::NamedElement).name.concat('.java'),
> false, 'UTF-8')]
> [e.name /]
> [/file]
> [/for]
>
> I know that I should use "uml::Element", because this is returned by
> "allOwnedElements()". BUT, the first example WORKS. The second does
> not! And such things are confusing me.
>
> The first example creates a file with
>
> NameClassEx
>
> The second example creates a file with
>
> org.eclipse.emf.ecore.impl.DynamicEObjectImpl@1884a40 (eClass:
> org.eclipse.emf.ecore.impl.EClassImpl@c2ee15 (name: OclInvalid_Class)
> (instanceClassName: null) (abstract: false, interface: false))
>
> Something, I have learned now and is very interesting:
> BOTH examples work, if I don't deploy my model plug-in. If I "start"
> my editor plug-in as "Eclipse application" and the Acceleo
> transformation there, I don't have problems!?!?
>
> I am really very confused :(
>
> BTW: I cannot use Acceleo 3.1.0 with my example at all (don't know
> what's going wrong!). Therefore, I am still using 3.0.1.

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #646868 is a reply to message #646851] Sat, 01 January 2011 19:39 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
Hello Ed,

you say that "my::ClassEx" does not conform to "uml::NamedElement". Why?

In my initial post and reproducable example, you can see that this is not true, because "my::ClassEx" is a "uml::Class" (which is a "uml::NamedElement", of course).

So, do we talk about a bug? Or is there a restriction? Do I really have to cast to a supertype, if it is part of another (super) meta model?

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #646876 is a reply to message #646868] Sat, 01 January 2011 22:11 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi vultur

Sorry; joined the thread late.

My comment is still probably correct but more subtly so.

my::ClassEx conforms to a uml::Class, but probably a different one. Yes
there are restrictions; the spelling of the URI for 'uml' must be
exactly the same otherwise you may have meta-model schizophrenia; one
variant from the genmodeled Java from the plugin registration and
another from a dynamic model and ...

EMF blindly does what it's told, because it might be sensible. It is for
applications to assist the user by diagnosing that EMF's meta-model miss
could be hit on an alternate meta-model.

Regards

Ed Willink


On 01/01/2011 19:39, vultur wrote:
> Hello Ed,
>
> you say that "my::ClassEx" does not conform to "uml::NamedElement". Why?
>
> In my initial post and reproducable example, you can see that this is
> not true, because "my::ClassEx" is a "uml::Class" (which is a
> "uml::NamedElement", of course).
>
> So, do we talk about a bug? Or is there a restriction? Do I really
> have to cast to a supertype, if it is part of another (super) meta model?

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #646915 is a reply to message #646876] Mon, 03 January 2011 06:24 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
 
my::ClassEx conforms to a uml::Class, but probably a different one.


Yes, this might be possible. However, I cannot track that.

In the beginning of this thread, I have posted reproducable steps which lead to this problem (starting from a completely "fresh" Eclipse). Could anyone comment, if there is an error in one of my files/model? If there is no error, we have an issue here.

As a reminder: The problem (that I have to cast to a supertype) occurs only with Acceleo 3.0.1 and if I "deploy" my meta model (editor).
With Acceleo 3.1.0M4 I don't even get a file with this loop

	[for (e : my::ClassEx | m.allOwnedElements()->select( oclIsKindOf(my::ClassEx) ).oclAsType(my::ClassEx) )]
	  [file (e.oclAsType(uml::NamedElement).name.concat('.java'), false, 'UTF-8')]
	    ...
	  [/file]
	[/for]

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #646931 is a reply to message #646490] Mon, 03 January 2011 09:11 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
Hi Vultur, Ed,

I believe that Ed's right : there are two instances of the UML metamodel loaded here. I can't think of any other way for your example to fail.

Namely, in your "my" metamodel, you reference the UML metamodel through a "platform" scheme URI :
Quote:

eSuperTypes=" platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Clas s "



While everywhere else you use its NsURI to reference it :

Quote:

xmlns:uml="http://www.eclipse.org/uml2/3.0.0/UML"



With these, I think that EMF ends up loading the metamodel twice, with two different URIs... And OCL cannot match the two EClasses since they come from "different" metamodels.

Laurent Goubet
Obeo

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #646980 is a reply to message #646931] Mon, 03 January 2011 19:22 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
Hi Laurent,

sounds that we get closer to my issue... thanks.

However, I have no idea what to do now. First of all, I have not expected that namespace URI and "ecore source file URI" are kind of the same thing, as the URI can be set within the ecore source file. I also have to note that the "discrepancy" in my example (first post) is created "automatically" by using Eclipse's/EMF's "non-source-code editors". After testing the following things, I also have doubts that the difference of " platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Clas s " and "http://www.eclipse.org/uml2/3.0.0/UML" causes the problem.

I tested to change all "super types" in my Ecore file (manually in the text editor), e.g. " platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#//Clas s " => "http://www.eclipse.org/uml2/3.0.0/UML#//Class". To my surprise, everything worked fine. A bit different (no display of the UML.ecore file in the My.ecore editor), but fine. The problems I got then is the genmodel file... using the old one causes (if I open the genmodel file):

The package 'http://www.eclipse.org/uml2/3.0.0/UML#/' has the same namespace URI 'http://www.eclipse.org/uml2/3.0.0/UML' as package 'platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore#'


I am also not able to create a new (correct) genmodel file, because I cannot reference to the UML genmodel file (this option is not offered, somehow).

What I tried then is changing "http://www.eclipse.org/uml2/3.0.0/UML" to "platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore", e.g. in my model file. Then, Acceleo/EMF reports this error:

Exception in thread "main" org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: org.eclipse.emf.ecore.xmi.PackageNotFoundException: 
Package with uri 'platform:/plugin/org.eclipse.uml2.uml/model/UML.ecore' not found. (file:/T:/test/org.eclipse.acceleo.module.sample/My.mymodel, 2, 204)


You see, that I am stranded without deep EMF/Acceleo knowledge. I know that all of you have different things to do... but if an EMF/Acceleo professional from this community would check my simple example (takes ~5 minutes), maybe he could tell exactly what's going wrong here, and why I should stop stealing your time Wink On the other hand, if we could detect an issue or enhance usability in future, this would be nice, right?

[Updated on: Mon, 03 January 2011 19:23]

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #647236 is a reply to message #646980] Wed, 05 January 2011 09:33 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
Vultur,

I just tried your example ... and it works.

1 - copy/paste your metamodel
2 - create a File > New > EMF Generator Model for this metamodel (tick MyModel in the "Root Packages" and tick "Ecore" and "UML" in the "Referenced Generator models" when promted)
3 - right click > generate model code in the genmodel editor
4 - launch a new runtime Eclipse (Run > Run Configurations... > Eclipse Application)
5 - copy paste your uml model
6 - copy/paste your generate.mtl
7 - launch generation

I had not compilation error in the mtl editor, and no runtime error when generating. A file "NameClassEx.java" has been generated with content

Quote:

NameClassEx
3




Which is what's expected here.

I'll try this under Eclipse 3.5 and 3.4 as well to check whether it could be an OCL issue.

Laurent Goubet
Obeo

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #647292 is a reply to message #647236] Wed, 05 January 2011 15:23 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
Hi Laurent,

thanks for checking, but here the difference:

As stated above:
BOTH examples work, if I don't deploy my model plug-in. If I "start" my editor plug-in as "Eclipse application" and the Acceleo transformation there, I don't have problems!?!?

I am really very confused


So, you are right. It works, if I run as "Eclipse application" as you did.
However, I deploy my meta-model editor. To describe my steps precisely here.

1 - "Export -> Deployable plug-ins and fragments"
2 - select "mymodel (1.0.0)", "mymodel.edit (1.0.0)" and "mymodel.editor (1.0.0)"
3 - select "install into host. repository"
4 - finish everything and restart Eclipse

Then you can experience my issues:

Acceleo 3.0.1:
org.eclipse.emf.ecore.impl.DynamicEObjectImpl@1884a40 (eClass: org.eclipse.emf.ecore.impl.EClassImpl@c2ee15 (name: OclInvalid_Class) (instanceClassName: null) (abstract: false, interface: false))
3


Acceleo 3.1.0M4:
No file is created at all (maybe, the loop is not entered at all)

If running as "Eclipse application" no problem.
I am using Eclipse 3.6 Helios SR1.

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #647735 is a reply to message #647292] Sat, 08 January 2011 11:35 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
I am still lost. I really need Acceleo to work properly. I have spent months working on my project now. Please comment, if I am doing something wrong. Please tell me, if it SHOULD or SHOULD NOT work the way I am doing it. If it must work, shouldn't we open an issue in the bug tracker?

Once again: my issue is reproducible. Laurent's way worked, but he was using "running as Eclipse application" and not installing the plug-in.

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #647871 is a reply to message #647735] Mon, 10 January 2011 08:44 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050207000802000004080805
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Vultur,

Installing plugins in the current Eclipse instance is not a good idea in
general. Some (most) plugins will simply not take new extension point
contributions into account when doing so, you lose the ability to debug
what's going on (as the code in your workspace won't stay in sync with
what's installed), and, in the case of Acceleo at least, you can't even
be sure that the installed code doesn't conflict with the code in the
workspace.

There are too many potential failures with "hot install" of plugins for
me to even know whether your problem comes from Acceleo or from another
of the other plugins.

In short, no, what you do is not how Acceleo should be used. Either you
build and install the plugin in your Eclipse or you use a Runtime Instance.

Laurent Goubet
Obeo

On 08/01/2011 12:35, vultur wrote:
> I am still lost. I really need Acceleo to work properly. I have spent
> months working on my project now. Please comment, if I am doing
> something wrong. Please tell me, if it SHOULD or SHOULD NOT work the way
> I am doing it. If it must work, shouldn't we open an issue in the bug
> tracker?
>
> Once again: my issue is reproducible. Laurent's way worked, but he was
> using "running as Eclipse application" and not installing the plug-in.


--------------050207000802000004080805
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyIj5PYmVvPC9hPg0KZW1haWw7 aW50ZXJuZXQ6
bGF1cmVudC5nb3ViZXRAb2Jlby5mcg0KdXJsOmh0dHA6Ly93d3cub2Jlby5m cg0KdmVyc2lv
bjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------050207000802000004080805--

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #648230 is a reply to message #647871] Tue, 11 January 2011 22:00 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.Friend
Messages: 132
Registered: July 2010
Senior Member
> Installing plugins in the current Eclipse instance is not a good idea in general.
> There are too many potential failures with "hot install" of plugins for
me to even know whether your problem comes from Acceleo or from another
of the other plugins.

This is what people tell me again and again. However, this is not the complete truth. Developer HAVE to know what's going wrong. And before I continue my development, I have to know all mechanisms, because problems will always return at a later point of development.

I have identified the problem. All background information is already described here:
http://www.eclipse.org/forums/index.php?t=msg&goto=62869 6

I can only subscribe what Edward Wilink said in the thread and hope that Acceleo stops doing "magic" things in the current workspace which lead to problems in some cases. Controlling mappings within some property sheets and an additional manual section which explains that some reference resolution is already done within the IDE (compilation) would lead to many aha experiences. Some additional logs which explain ref resolutions would help as well, I think. People who start with Acceleo who have no internal knowledge are lost. I could only solve my problem, because I had some really intense weeks with Acceleo now.

[Updated on: Tue, 11 January 2011 22:01]

Report message to a moderator

Re: [Acceleo 3] Casting to supertype necessary! [message #649193 is a reply to message #648230] Tue, 18 January 2011 06:08 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi vultur

Eclipse is an Open Source Community.

Not everyone in the community has unlimited amounts of time to help
everyone else.

Sometimes one has to help oneself and then help others by publishing
results or submitting a patch via Bugzilla.

If you have a reproducible problem in 2 different environments, it
should be possible to debug both and gradually narrow down the divergence.

I have done this many times. Usually, I identify my own stupidity,
sometimes a bug. Even when I'm stupid, I can sometimes identify where
better tool diagnosis would have helped me.

Regards

Ed Willink

On 11/01/2011 22:00, vultur wrote:
>> Installing plugins in the current Eclipse instance is not a good idea
>> in general.
>> There are too many potential failures with "hot install" of plugins for
> me to even know whether your problem comes from Acceleo or from
> another of the other plugins.
>
> This is what people tell me again and again. Howeverm this is not the
> complete truth. However, I want to know what's wrong first. And before
> I continue my development, I have to know all mechanisms, because
> problems will always return at a later point of development.
>
> I have identified the problem. All background information is already
> described here:
> http://www.eclipse.org/forums/index.php?t=msg&goto=62869 6
>
> I can only subscribe what Edward Wilink said in the thread and hope
> that Acceleo stops doing "magic" things in the current workspace which
> lead to problems in some cases. Controlling mappings within some
> property sheets and an additional manual section which explains that
> some reference resolution is already done within the IDE (compilation)
> would lead to many aha experiences. Some additional logs which explain
> ref resolutions would help as well, I think. People who start with
> Acceleo who have no internal knowledge are lost. I could only solve my
> problem, because I had some really intense weeks with Acceleo now.

Report message to a moderator

Previous Topic:Install a Debugger in eclipse
Next Topic:[Acceleo 3] recursive import not supported
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Tue Apr 23 11:02:10 GMT 2024

Powered by FUDForum. Page generated in 0.05363 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly