Cyclic linking detected when building in maven [message #1736601] |
Thu, 30 June 2016 14:20  |
Eclipse User |
|
|
|
Hello,
I am stuck. My DSL provides a scoping which works nice in Eclipse, but when I try to build the project with maven it fails with:
DefaultComponentFeatureDotRef.right->DefaultComponentFeatureDotRef.right
What is the difference between the maven build and the Eclipse build?
Why does it fails with maven?
Any help, hint welcome.
Thanks
|
|
|
|
|
|
|
Re: Cyclic linking detected when building in maven [message #1736926 is a reply to message #1736909] |
Mon, 04 July 2016 12:02   |
Eclipse User |
|
|
|
acceptor.accept(comp.toClass(className))[
val start = System.currentTimeMillis
lateInitializationSetupComponent(it, comp.name, comp.toJvmType, comp.content)
static = false
printDuration("create Component "+comp.name+": ", start)
]
to
acceptor.accept(comp.toClass(className, [
val start = System.currentTimeMillis
lateInitializationSetupComponent(it, comp.name, comp.toJvmType, comp.content)
static = false
printDuration("create Component "+comp.name+": ", start)
]))
But this raises other issues, but I hope I can cope with them.
|
|
|
|
Re: Cyclic linking detected when building in maven [message #1736963 is a reply to message #1736934] |
Mon, 04 July 2016 16:47   |
Eclipse User |
|
|
|
here is the cycle and a potential workaround
at om.lutte.cyclicLinking.Util.getDefaultTypeByRef(Util.java:301)
at om.lutte.cyclicLinking.Util.toJvmType(Util.java:230)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$6(LinkJvmModelInferrer.java:331)
at org.eclipse.xtext.xbase.lib.ObjectExtensions.operator_doubleArrow(ObjectExtensions.java:139)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.createSetupTriggerPoint(LinkJvmModelInferrer.java:375)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$5(LinkJvmModelInferrer.java:320)
at java.lang.Iterable.forEach(Iterable.java:75)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lateInitializationSetupComponent(LinkJvmModelInferrer.java:323)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$3(LinkJvmModelInferrer.java:291)
at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator$1.run(JvmModelAssociator.java:397)
at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.installDerivedState(JvmModelAssociator.java:407)
at org.eclipse.xtext.resource.DerivedStateAwareResource.installDerivedState(DerivedStateAwareResource.java:242)
at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getContents(BatchLinkableResource.java:148)
at org.eclipse.emf.ecore.util.EcoreUtil.getAllContents(EcoreUtil.java:1176)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider$3.iterator(XImportSectionNamespaceScopeProvider.java:283)
at com.google.common.collect.Iterables$8.iterator(Iterables.java:713)
at com.google.common.collect.Iterables$6.iterator(Iterables.java:589)
at org.eclipse.xtext.scoping.impl.MultimapBasedSelectable.setExportedObjects(MultimapBasedSelectable.java:106)
at org.eclipse.xtext.scoping.impl.MultimapBasedSelectable.<init>(MultimapBasedSelectable.java:36)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider.internalGetAllDescriptions(XImportSectionNamespaceScopeProvider.java:287)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider$2.get(XImportSectionNamespaceScopeProvider.java:274)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider$2.get(XImportSectionNamespaceScopeProvider.java:1)
at org.eclipse.xtext.util.OnChangeEvictingCache.get(OnChangeEvictingCache.java:77)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider.getAllDescriptions(XImportSectionNamespaceScopeProvider.java:271)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider.getGlobalScope(XImportSectionNamespaceScopeProvider.java:89)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider.getScope(XImportSectionNamespaceScopeProvider.java:82)
at om.lutte.cyclicLinking.scoping.LinkScopeProviderDelegate.getScope(LinkScopeProviderDelegate.java:107)
at org.eclipse.xtext.xbase.scoping.batch.XbaseBatchScopeProvider.delegateGetScope(XbaseBatchScopeProvider.java:63)
at org.eclipse.xtext.xbase.scoping.batch.XbaseBatchScopeProvider.getScope(XbaseBatchScopeProvider.java:107)
at org.eclipse.xtext.linking.impl.DefaultLinkingService.getScope(DefaultLinkingService.java:59)
at org.eclipse.xtext.linking.impl.DefaultLinkingService.getLinkedObjects(DefaultLinkingService.java:119)
at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:247)
at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getEObject(BatchLinkableResource.java:119)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:223)
at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:199)
at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:259)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1477)
at om.lutte.cyclicLinking.link.impl.DefaultComponentFeatureRefImpl.getFeature(DefaultComponentFeatureRefImpl.java:73)
at om.lutte.cyclicLinking.Util.getDefaultTypeByRef(Util.java:303)
at om.lutte.cyclicLinking.Util.toJvmType(Util.java:230)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$8(LinkJvmModelInferrer.java:501)
at org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder.initializeSafely(JvmTypesBuilder.java:207)
at org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder.toClass(JvmTypesBuilder.java:385)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.createTpPiece(LinkJvmModelInferrer.java:523)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$15(LinkJvmModelInferrer.java:460)
at java.lang.Iterable.forEach(Iterable.java:75)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$7(LinkJvmModelInferrer.java:463)
at org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder.initializeSafely(JvmTypesBuilder.java:207)
at org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder.toClass(JvmTypesBuilder.java:385)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.createSetupPiece(LinkJvmModelInferrer.java:490)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$11(LinkJvmModelInferrer.java:119)
at java.lang.Iterable.forEach(Iterable.java:75)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$0(LinkJvmModelInferrer.java:122)
at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator$1.run(JvmModelAssociator.java:397)
at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.installDerivedState(JvmModelAssociator.java:407)
at org.eclipse.xtext.resource.DerivedStateAwareResource.installDerivedState(DerivedStateAwareResource.java:242)
at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getContents(BatchLinkableResource.java:148)
at org.eclipse.xtext.builder.standalone.StandaloneBuilder.launch(StandaloneBuilder.java:292)
at org.eclipse.xtext.maven.XtextGenerator.internalExecute(XtextGenerator.java:165)
override getScope(EObject context, EReference reference) {
var IScope retval = null
// println("<getScope> context: "+context)
// println("<getScope> reference: "+reference.name+" / "+reference)
val superScope = if (reference == LinkPackage.Literals.DEFAULT_COMPONENT_FEATURE_REF__FEATURE) IScope.NULLSCOPE else super.getScope(context, reference)
if (retval == null)
{
retval = linkScopeDefaultTypes.getScope(context, reference, superScope)
}
if (retval == null)
{
retval = linkScopeTopologyFeature.getScope(context, reference, superScope)
}
if (retval == null)
{
superScope
} else
{
retval
}
}
|
|
|
Re: Cyclic linking detected when building in maven [message #1737441 is a reply to message #1736963] |
Fri, 08 July 2016 09:46   |
Eclipse User |
|
|
|
Thank you for the replay, I found an other solution. It looks different, but my real dsl is much more complex.
I had to override org.eclipse.xtext.xbase.resource.BatchLinkableResource as in my case the cycle seems to be the normal behavior.
I am doing something like this
File one contains:
defaultObject = new XYZObject (xyzAttribute1 = "x", xyzAttribute2="x2", ...)
File two contains:
aNewObject = extends defaultObject (xyzA1 = "x", xyzAttribute2="x2", ...)
To create the sope for xyzA1 I need to find the JvmType of XYZObject. When I try to resolve the type of XYZObject the whole model of "File one" seems to be parsed, and this causes the cycle. At the second call the model of "File one" has been parsed, so the cycle is broken.(At least this is my guess)
val counter = new HashMap<Triple<EObject, EReference, INode>, AtomicInteger>()
override protected handleCyclicResolution(Triple<EObject, EReference, INode> triple) throws AssertionError {
try{
val calls = incrementAndGetCounter(triple)
if (calls > 3)
{
super.handleCyclicResolution(triple)
} else
{
val node = triple.third
val message = "Cyclic linking detected " +calls+": "+ getReferences(triple, resolving)+"\n"
+" "+getReferencesNode(triple, resolving)
println(message)
// new Exception(message).printStackTrace
val linkedObjects = getLinkingService().getLinkedObjects(
triple.first,
triple.second,
node);
linkedObjects.head
}
} finally
{
decrepementAndGetCounter(triple)
}
}
def int incrementAndGetCounter (Triple<EObject, EReference, INode> triple)
{
val c = counter.get(triple)
if (c == null)
{
counter.put(triple, new AtomicInteger(1))
1
} else
{
c.incrementAndGet
}
}
def int decrepementAndGetCounter (Triple<EObject, EReference, INode> triple)
{
val c = counter.get(triple)
if (c == null)
{
counter.put(triple, new AtomicInteger(-1))
(-1)
} else
{
c.decrementAndGet
}
}
def protected String getReferencesNode(Triple<EObject, EReference, INode> triple,
LinkedHashSet<Triple<EObject, EReference, INode>> resolving2) {
val buffer = new StringBuffer();
var found = false;
for (Triple<EObject, EReference, INode> triple2 : resolving2) {
found = found || triple2.equals(triple);
if (found)
buffer.append(getQualifiedNodeName(triple2.third)).append("->");
}
buffer.append(getQualifiedNodeName(triple.third));
return buffer.toString();
}
def private String getQualifiedNodeName(INode node) {
return node.text;
}
In my case the cycle only occurred once.
Cyclic linking detected 1: EmuContentRef.emuContent->Parameter.parameterFeature->EmuContentRef.emuContent
chuteTp->unitId->chuteTp
Cyclic linking detected 1: JvmParameterizedTypeReference.type->Parameter.parameterFeature->JvmParameterizedTypeReference.type
VarioscNodeComponent->nodeIdVariosc-> VarioscNodeComponent
Cyclic linking detected 1: EmuContentRef.emuContent->Parameter.parameterFeature->EmuContentRef.emuContent
defaultTp->name->defaultTp
I am fine with this solution. And for now it works.
But it does not answers the question, why it is behaving different in Eclipse, than in Maven. (But for now I am happy )
|
|
|
|
Powered by
FUDForum. Page generated in 0.04686 seconds