Home » Modeling » EMF » [Xcore][gradle] Two mysterious problems.
| [Xcore][gradle] Two mysterious problems. [message #1754613] |
Tue, 21 February 2017 04:55  |
 Nicolas Rouquette
Messages: 40
Registered: December 2014 |
Member |
|
|
I am using gradle to build a DSL from an Xcore metamodel here:
https://github.com/jpl-imce/oml.core
This project is organized in a similar way than the itemis example here:
https://github.com/itemis/itemis-blog/tree/xcore_gradle
There are two differences though:
1) The behavior of the XcoreGenerator is different
In the itemis example, the XcoreGenerator does not produce any *.ecore metamodel per se. You can see this in the generated code for the metamodel package initialization:
/org.xtext.example.mydsl.model/build/xcore/main/org/xtext/example/mydsl/impl/MydslPackageImpl.java
public class MydslPackageImpl extends EPackageImpl implements MydslPackage {
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
private EClass modelEClass = null;
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
private EClass greetingEClass = null;
/**
* Creates an instance of the model <b>Package</b>, registered with
* {@link org.eclipse.emf.ecore.EPackage.Registry EPackage.Registry} by the package
* package URI value.
* <p>Note: the correct way to create the package is via the static
* factory method {@link #init init()}, which also performs
* initialization of the package, or returns the registered package,
* if one already exists.
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @see org.eclipse.emf.ecore.EPackage.Registry
* @see org.xtext.example.mydsl.MydslPackage#eNS_URI
* @see #init()
* @generated
*/
private MydslPackageImpl() {
super(eNS_URI, MydslFactory.eINSTANCE);
}
...
public void initializePackageContents() {
if (isInitialized) return;
isInitialized = true;
// Initialize package
setName(eNAME);
setNsPrefix(eNS_PREFIX);
setNsURI(eNS_URI);
// Obtain other dependent packages
EcorePackage theEcorePackage = (EcorePackage)EPackage.Registry.INSTANCE.getEPackage(EcorePackage.eNS_URI);
// Create type parameters
// Set bounds for type parameters
// Add supertypes to classes
// Initialize classes, features, and operations; add parameters
initEClass(modelEClass, Model.class, "Model", !IS_ABSTRACT, !IS_INTERFACE, IS_GENERATED_INSTANCE_CLASS);
initEReference(getModel_Greetings(), this.getGreeting(), null, "greetings", null, 0, -1, Model.class, !IS_TRANSIENT, !IS_VOLATILE, IS_CHANGEABLE, IS_COMPOSITE, !IS_RESOLVE_PROXIES, !IS_UNSETTABLE, IS_UNIQUE, !IS_DERIVED, IS_ORDERED);
initEClass(greetingEClass, Greeting.class, "Greeting", !IS_ABSTRACT, !IS_INTERFACE, IS_GENERATED_INSTANCE_CLASS);
initEAttribute(getGreeting_Name(), theEcorePackage.getEString(), "name", null, 0, 1, Greeting.class, !IS_TRANSIENT, !IS_VOLATILE, IS_CHANGEABLE, !IS_UNSETTABLE, !IS_ID, !IS_UNIQUE, !IS_DERIVED, IS_ORDERED);
// Create resource
createResource(eNS_URI);
}
...
In my case, the XcoreGenerator produces an *.ecore file;
however, it fails to save it because it is running outside of Eclipse
(i.e., there is no EMF ResourceSet pathmap nor any workspaceRoot
to map the generated resource to an external file location).
It's clear from the generated package impl code that there *should*
be an *.ecore file saved though:
public class OmlPackageImpl extends EPackageImpl implements OmlPackage {
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
protected String packageFilename = "oml.ecore";
...
public static OmlPackage init() {
if (isInited) return (OmlPackage)EPackage.Registry.INSTANCE.getEPackage(OmlPackage.eNS_URI);
// Obtain or create and register package
OmlPackageImpl theOmlPackage = (OmlPackageImpl)(EPackage.Registry.INSTANCE.get(eNS_URI) instanceof OmlPackageImpl ? EPackage.Registry.INSTANCE.get(eNS_URI) : new OmlPackageImpl());
isInited = true;
// Initialize simple dependencies
EcorePackage.eINSTANCE.eClass();
// Load packages
theOmlPackage.loadPackage();
// Fix loaded packages
theOmlPackage.fixPackageContents();
// Mark meta-data to indicate it can't be changed
theOmlPackage.freeze();
// Update the registry and return the package
EPackage.Registry.INSTANCE.put(OmlPackage.eNS_URI, theOmlPackage);
return theOmlPackage;
}
...
Questions:
1) What determines whether the XcoreGenerator produces code that requires an *.ecore metamodel for initializing the metamodel package or not?
I'm not sure if this difference is attributable to the XcoreGenerator per se or to behavior it inherits from the EMF code generator.
I tried to comment out some parts of my DSL hoping to get a smaller reproducible example; well, it's not obvious.
2) Assuming that I won't be so lucky to define a DSL without needing an *.ecore file,
how could I configure the gradle script such that the EMF ResourceSet used by the XcoreGenerator would have a pathmap like:
"oml.model" = file("${rootDir}/oml.model")
Is there some configuration that could be set in the xtext section?
xtext {
version = "${xtextVersion}"
languages {
ecore {
setup = 'org.eclipse.xtext.ecore.EcoreSupport'
}
codegen {
setup = 'org.eclipse.emf.codegen.ecore.xtext.GenModelSupport'
}
xcore {
setup = 'org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup'
generator {
javaSourceLevel = '1.8'
outlet {
producesJava = true
}
}
}
}
}
If not, I wonder if it would be possible to define locally in the project a custom
XcoreStandaloneSetup to configure the ResourceSet's pathmap.
I'm not an expert in gradle so I would appreciate very much some guidance on this.
|
|
| | | | |
Goto Forum:
Current Time: Thu Jan 02 17:29:26 GMT 2025
Powered by FUDForum. Page generated in 0.05024 seconds |
] 
Search
Help
Register
Login
Home
