Home » Modeling » M2T (model-to-text transformation) » [acceleo] The type of the first parameter of the main template named ... is a proxy.
| [acceleo] The type of the first parameter of the main template named ... is a proxy. [message #786788] |
Mon, 30 January 2012 20:23  |
 Rocky Dunlap
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
When executing Acceleo 3.2 on a custom metamodel (an ecore model) as a Java application OR with the Acceleo launcher I receive the following error. Similar questions have been asked previously, but for some reason I am not able to apply those solutions here successfully. I think this is probably a simple registration problem.
Exception in thread "main" org.eclipse.acceleo.engine.AcceleoEvaluationException: The type of the first parameter of the main template named 'genDeployment' is a proxy.
at org.eclipse.acceleo.engine.service.AcceleoService.doGenerate(AcceleoService.java:566)
at org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.generate(AbstractAcceleoGenerator.java:193)
at org.eclipse.acceleo.engine.service.AbstractAcceleoGenerator.doGenerate(AbstractAcceleoGenerator.java:158)
at org.earthsystemcurator.cplgen.gen.common.GenerateDeploymentUnit.doGenerate(GenerateDeploymentUnit.java:193)
at org.earthsystemcurator.cplgen.gen.common.GenerateDeploymentUnit.main(GenerateDeploymentUnit.java:156)
My module header looks like this:
[module generateDeploymentUnit('http://www.eclipse.org/emf/2002/Ecore', 'http://www.earthsystemcurator.org/cplgen/deployment', 'http://www.earthsystemcurator.org/cplgen/definition')]
Executing the debugger, the type of the first template parameter is indeed a proxy object. The Deployment/Deployment business is because the name of the EPackage is 'Deployment' and there is an EClass contained there also name 'Deployment'
org.eclipse.emf.ecore.impl.EClassImpl@72ebf3f0 (eProxyURI: http://www.earthsystemcurator.org/cplgen#//Deployment/Deployment)
The instance file looks like this:
<cge:Deployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:cge="http://www.earthsystemcurator.org/cplgen/deployment">
<schedule/>
<deploymentUnit name="DU1">
<sequenceUnit threads="10">
<definition href="ModelA.definition#/"/>
</sequenceUnit>
</deploymentUnit>
</cge:Deployment>
I have registered the package and factory inside my generator Java class:
public void registerPackages(ResourceSet resourceSet) {
//...
if (!isInWorkspace(DeploymentPackage.class)) {
//Ns URI = http://www.earthsystemcurator.org/cplgen/deployment
resourceSet.getPackageRegistry().put(DeploymentPackage.eNS_URI, DeploymentPackage.eINSTANCE);
} else {
resourceSet.getPackageRegistry().put("/cplgen/model/CplGen.ecore", DeploymentPackage.eINSTANCE);
}
if (!isInWorkspace(DefinitionPackage.class)) {
//Ns URI = http://www.earthsystemcurator.org/cplgen/definition
resourceSet.getPackageRegistry().put(DefinitionPackage.eNS_URI, DefinitionPackage.eINSTANCE);
} else {
resourceSet.getPackageRegistry().put("/cplgen/model/CplGen.ecore", DefinitionPackage.eINSTANCE);
}
//...
}
public void registerResourceFactories(ResourceSet resourceSet) {
//...
resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("deployment", new XMIResourceFactoryImpl());
resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("definition", new XMIResourceFactoryImpl());
// ...
}
Any help would be appreciated.
|
|
|
| Re: [acceleo] The type of the first parameter of the main template named ... is a proxy. [message #787184 is a reply to message #786788] |
Tue, 31 January 2012 08:54  |
|
Hi,
Your registrations seem fine, but you are following something that is known as a bad practice in EMF, namely, using nested EPackages. You'll probably see a lot in the EMF newsgroup that people are experiencing problems with them, and you seem to have stumbled on another.
If you look carefully, you are registering the NsURI of the "deployment" package : "http://www.earthsystemcurator.org/cplgen/deployment", but your metaclass is registered through the NsURI of the "cplgen" package : "http://www.earthsystemcurator.org/cplgen#//Deployment/Deployment". Even if you manage to fix this first issue, you will encounter others. You should be splitting your two metamodels -definition and deployment- in their own ecore files, and generate both of them separately.
Laurent Goubet
Obeo
|
|
|
| Re: [acceleo] The type of the first parameter of the main template named ... is a proxy. [message #787207 is a reply to message #787184] |
Tue, 31 January 2012 09:23 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Laurent
There should be no problem with nested EPackages; it's multi-rooted
Ecore models that are challenging since there is no single root element.
(From the perspective of UML/EMOF equivalence, there shouldn't really be
a problem with multi-rooted either; it's just that modeling
implementations typically start with the assumption of a single root and
only accommodate multiple roots after bug reports.)
Regards
Ed Willink
On 31/01/2012 08:54, Laurent Goubet wrote:
> Hi,
>
> Your registrations seem fine, but you are following something that is
> known as a bad practice in EMF, namely, using nested EPackages. You'll
> probably see a lot in the EMF newsgroup that people are experiencing
> problems with them, and you seem to have stumbled on another.
>
> If you look carefully, you are registering the NsURI of the
> "deployment" package :
> "http://www.earthsystemcurator.org/cplgen/deployment", but your
> metaclass is registered through the NsURI of the "cplgen" package :
> "http://www.earthsystemcurator.org/cplgen#//Deployment/Deployment".
> Even if you manage to fix this first issue, you will encounter others.
> You should be splitting your two metamodels -definition and
> deployment- in their own ecore files, and generate both of them
> separately.
>
> Laurent Goubet
> Obeo
|
|
|
| Re: [acceleo] The type of the first parameter of the main template named ... is a proxy. [message #787222 is a reply to message #787207] |
Tue, 31 January 2012 09:47 |
|
Ed,
I'm stating this as a bad practice as this is a recurring source of problems as far as I could see in either the framework (EMF itself), or tools that use it as far as I could see. Most forums see these kind of post arising, be it EMF, M2T, or M2M (I have not followed the OCL forum for long enough to know if this has also been seen there ... but I do believe it is the case).
To shamelessly quote Ed Merks (http://www.eclipse.org/forums/index.php?t=tree&goto=501102) ...
Quote:
It has no semantic significance to nest packages and I think
that's the definition of syntactic sugar. Given the choice, I would not
have provided this feature, especially given that's it's a recurring
source of problems...
If the original poster of this thread can restructure his metamodel, it will save him issues. We can discuss wether or not there "should" or "should not" be issues with nested packages; I for one believe that they do not really provide much semantic sens. In the meantime, I think more important to provide a solution.
Laurent Goubet
Obeo
|
|
| |
| Re: [acceleo] The type of the first parameter of the main template named ... is a proxy. [message #787989 is a reply to message #787629] |
Wed, 01 February 2012 07:59 |
|
Rocky Dunlap wrote on Tue, 31 January 2012 15:13
The bigger issue is that it is not obvious to new EMF developers that working with nested packages is a bad idea. Java developers in particular are used to the idea of setting up a nice hierarchy of packages. Since this is a bad practice for EMF, perhaps it should be made more obvious somewhere in the EMF developer documentation. Oh well, I guess that's what the forums are for!
This is not something that is that obvious even for someone who has worked extensively with EMF for some years... And I don't really think that any documentation tells anything about it : it is supported. It is a fact that they are a recurring source of issues, but for all I know that might lie only with the tools developped with EMF, not with EMF itself.
You may be able to use nested EPackages if you only set an NsURI for the "root"? Though I am not so sure. I usually found it sufficient to only change the prefix of my packages in the genmodel : my package is named "acceleo", but I generate it with the prefix "org.eclipse" prefix for example. Otherwise, splitting the metamodel in multiple ecore files seem like the best way to avoid trouble.
Laurent Goubet
Obeo
|
|
|
Goto Forum:
Current Time: Tue Apr 23 13:15:22 GMT 2024
Powered by FUDForum. Page generated in 0.03972 seconds |
] 
Search
Help
Register
Login
Home
