|
|
| Re: [Acceleo 3.1] Problem with identifiers of protected [message #724364 is a reply to message #723298] |
Mon, 12 September 2011 07:53   |
|
Hi Norman,
Norman wrote on Thu, 08 September 2011 11:22
I know that changing the name worked in the past.
I don't see how it could have worked, we are matching the previously generated protected marker with the newly generated ones.
Anyway, you can change the protected area marker manually or you can ignore protected areas and have your users override the method of the generated classes instead of modifying the generated classes. It may break after some changes (if the method changes it may not compile anymore) but the user code will not be put into a ."lost" file. Finally if you are generating Java source code, you can use JMerge insttead. With JMerge, you can put a "@generated NOT" tag in the documentation of the method and Acceleo will consider the whole method as being protected. You can see an example of JMerge in the generated Java launcher class created by Acceleo. If you want to see JMerge in action, you can have a look at this video.
Regards,
Stephane Begaudeau, Obeo
--
Twitter: @sbegaudeau
Google+: stephane.begaudeau
Blog: http://stephanebegaudeau.tumblr.com
Acceleo Documentation: http://docs.obeonetwork.com/acceleo
|
|
|
|
|
| Re: [Acceleo 3.1] Problem with identifiers of protected [message #729431 is a reply to message #727015] |
Mon, 26 September 2011 07:48 |
|
Hi Norman,
Changing the identifier of a protected area, whatever the change, will result in a .lost file. That has always stood true for all versions of Acceleo. Changing the name of your operation, which incidentally is part of the identifier, is thus a change that never "worked".
What you should use here is not the name of the operation, but its ID. The ID cannot be obtained through Acceleo code alone, you'll have to resort to a Java service of this sort :
Quote:
public String getXMIID(EObject eObject) {
if (eObject.eResource() instanceof XMIResource) {
return ((XMIResource)eObject.eResource()).getID(eObject);
} else {
// This Object does not have an XMI ID. Resort on its name or throw exception
...
}
}
UML resources should all have XMI IDs... so you should never have to see the "else" in this code. It is a possibility though, and I'll let you code the logic that suits you there  .
Laurent Goubet
Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.01926 seconds
] 
Search
Help
Register
Login
Home
