|
| Re: [Xcore/2] circular dependencies [message #1102299 is a reply to message #1102266] |
Thu, 05 September 2013 12:03   |
Eclipse User |
|
|
|
Meinte,
I couldn't reproduce such a problem. I have A.xcore
@GenModel(testsDirectory="/abc.tests/src")
package a
import b.B
class A
{
refers B b
}
class C extends B
{
}
and B.xcore
package b
import a.A
class B extends A
{
refers A a
}
In the generated example I write this code:
APackage.eINSTANCE.eResource().save(System.err, null);
BPackage.eINSTANCE.eResource().save(System.err, null);
And it writes out the following, so all seems to be there.
<?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="a"
nsURI="a" nsPrefix="a">
<eClassifiers xsi:type="ecore:EClass" name="A">
<eStructuralFeatures xsi:type="ecore:EReference" name="b"
eType="ecore:EClass b#//B"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="C" eSuperTypes="b#//B"/>
</ecore:EPackage>
<?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="b"
nsURI="b" nsPrefix="b">
<eClassifiers xsi:type="ecore:EClass" name="B" eSuperTypes="a#//A">
<eStructuralFeatures xsi:type="ecore:EReference" name="a"
eType="ecore:EClass a#//A"/>
</eClassifiers>
</ecore:EPackage>
Of course such mutually dependent models need to be hosted in the same
bundle, otherwise the bundles would need to be mutually dependent, which
isn't allowed.
Are you using the Kepler version of Xcore? Is there some scenario I
missed in my example?
On 05/09/2013 5:24 PM, Meinte Boersma wrote:
> I know this topic has been discussed here earlier, but Xcore breathes
> a little bit of new life into it ;)
> (After all, Xcore makes creating models productive enough to encounter
> this kind of stuff again.)
>
> The problem is not really with Xcore, apart from the fact that Xcore
> doesn't flag the problem.
> The actual problem lies with the way the <packageName>PackageImpl are
> generated: their init() implementations only register the package
> under the nsURI after full creation, which entails calling
> initializePackageContents() which may need package instances that
> haven't been registered at that point in time yet. There are no
> infinite loops, but the required packages variables may simply be null.
>
> To fix this completely, I think it could be enough that all package
> instances are registered and their createPackageContents() called
> before initializePackageContents is called on any of them.
>
|
|
|
|
|
|
|
|
| Re: [Xcore/2] circular dependencies [message #1741563 is a reply to message #1103008] |
Thu, 25 August 2016 16:37 |
| Eclipse User |
|
|
|
Has this been fixed? I am running into this issue with cycle dependency in Xcore (I am using the Neon release):
I have the following packages:
package a
import b.B
class A {
refers B b
}
package b
import a.A
import c.C
class B {
refers A a
refers C c
}
package c
import b.B
class C {
refers B b
}
I get the following code generated when I clean the project that contains the three packages forcing code generation for the three packages.
public static APackage init() {
...
// Obtain or create and register interdependencies
BPackageImpl theBPackage = ...
// Create package meta-data objects
theAPackage.createPackageContents();
theBPackage.createPackageContents();
// Initialize created meta-data
theAPackage.initializePackageContents();
theBPackage.initializePackageContents();
...
}
public static BPackage init() {
...
// Obtain or create and register interdependencies
APackageImpl theAPackage = ...
CPackageImpl theCPackage = ...
// Create package meta-data objects
theBPackage.createPackageContents();
theAPackage.createPackageContents();
theCPackage.createPackageContents();
// Initialize created meta-data
theBPackage.initializePackageContents();
theAPackage.initializePackageContents();
theCPackage.initializePackageContents();
...
}
public static CPackage init() {
...
// Obtain or create and register interdependencies
BPackageImpl theBPackage = ...
// Create package meta-data objects
theCPackage.createPackageContents();
theBPackage.createPackageContents();
// Initialize created meta-data
theCPackage.initializePackageContents();
theBPackage.initializePackageContents();
...
}
However, if I then do a dummy change to package A and save it, I get package A looking like this (which is more correct):
public static APackage init() {
...
// Obtain or create and register interdependencies
BPackageImpl theBPackage = ...
CPackageImpl theCPackage = ...
// Create package meta-data objects
theAPackage.createPackageContents();
theBPackage.createPackageContents();
theCPackage.createPackageContents();
// Initialize created meta-data
theAPackage.initializePackageContents();
theBPackage.initializePackageContents();
theCPackage.initializePackageContents();
...
}
However, doing the same to package C does not result in a similar change. What is interesting is that switching the order of properties (a and c) in class B would switch the package that would generate correctly after a resave.
[Updated on: Fri, 26 August 2016 15:29] by Moderator |
|
|
Powered by
FUDForum. Page generated in 0.24969 seconds
Home
