You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Jan Larres (JIRA)" <ji...@apache.org> on 2015/06/22 07:55:00 UTC

[jira] [Created] (IVYDE-380) Cyclic property definitions cause resolve to fail

Jan Larres created IVYDE-380:
--------------------------------

             Summary: Cyclic property definitions cause resolve to fail
                 Key: IVYDE-380
                 URL: https://issues.apache.org/jira/browse/IVYDE-380
             Project: IvyDE
          Issue Type: Bug
    Affects Versions: 2.2.0.final
            Reporter: Jan Larres


Our properties files that get read by Ivy contain a few cyclic definitions. This is caused by the way our build infrastructure is set up and is unfortunately beyond my control. The problem is that this causes resolves that do not even make use of this property to fail:

{noformat}
problem occurred while resolving dependency: opencloud#cassandra-cql-events#cassandra-cql/trunk;1.0.1-TRUNK.0-SNAPSHOT.r9-602fba5 {api=[api], slee-component=[slee-component]} with volte-trunk_volte-imsid-lookup-cassandra-ivyde-workspace-resolver (java.lang.IllegalArgumentException: cyclic variable definition: cycle = [sentinel-sip.component.version, sentinel-sip.component.version])
java.lang.IllegalArgumentException: cyclic variable definition: cycle = [sentinel-sip.component.version, sentinel-sip.component.version]
	at org.apache.ivy.core.IvyPatternHelper.substituteVariables(IvyPatternHelper.java:207)
	at org.apache.ivy.core.IvyPatternHelper.substituteVariables(IvyPatternHelper.java:211)
	at org.apache.ivy.core.IvyPatternHelper.substituteVariables(IvyPatternHelper.java:181)
	at org.apache.ivy.core.settings.IvyVariableContainerImpl.substitute(IvyVariableContainerImpl.java:64)
	at org.apache.ivy.core.settings.IvyVariableContainerImpl.setVariable(IvyVariableContainerImpl.java:49)
	at org.apache.ivy.core.settings.IvySettings.setVariable(IvySettings.java:600)
	at org.apache.ivy.core.settings.IvySettings.setVariable(IvySettings.java:585)
	at org.apache.ivy.core.settings.IvySettings.setVariable(IvySettings.java:581)
	at org.apache.ivyde.internal.eclipse.CachedIvy.createIvySettings(CachedIvy.java:295)
	at org.apache.ivyde.internal.eclipse.CachedIvy.getIvyFromFile(CachedIvy.java:200)
	at org.apache.ivyde.internal.eclipse.CachedIvy.doGetIvy(CachedIvy.java:163)
	at org.apache.ivyde.internal.eclipse.CachedIvy.getIvy(CachedIvy.java:124)
	at org.apache.ivyde.internal.eclipse.CachedIvy.getCachedModuleDescriptor(CachedIvy.java:328)
	at org.apache.ivyde.internal.eclipse.workspaceresolver.WorkspaceResolver.getDependency(WorkspaceResolver.java:200)
	at org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
	at org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:170)
	at org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:292)
	at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:718)
	at org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:803)
	at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:726)
	at org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:803)
	at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:726)
	at org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:599)
	at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:236)
	at org.apache.ivyde.internal.eclipse.resolve.IvyResolver.doResolve(IvyResolver.java:255)
	at org.apache.ivyde.internal.eclipse.resolve.IvyResolver.resolve(IvyResolver.java:147)
	at org.apache.ivyde.internal.eclipse.resolve.IvyResolveJob$1.run(IvyResolveJob.java:287)
	at java.lang.Thread.run(Thread.java:745)
{noformat}

IvyDE should not fail here unless it genuinely can't resolve something. Otherwise it essentially breaks dependency management under these conditions.

A similar bug in IvyIDEA was fixed in 2012:
https://code.google.com/p/ivyidea/issues/detail?id=95



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)