[GRADLE-1621] Gradle Tooling API fails to build Eclipse model if it can't find source jars for dependencies Created: 17/Jun/11  Updated: 04/Jan/13  Resolved: 11/Aug/11

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-3, 1.0-milestone-4
Fix Version/s: 1.0-milestone-5

Type: Bug
Reporter: Kris De Volder Assignee: Peter Niederwieser
Resolution: Fixed Votes: 1

Attachments: Zip Archive Testprojects_flatDirRepo.zip     Zip Archive bonkers.zip    

 Description   

I'm attaching two tests projects that were provided to me by an STS user who was actually reporting a differen bug.
(see issue https://issuetracker.springsource.com/browse/STS-1838).

To reproduce the bug take the following steps.

  • on TestProject1 run "gradle uploadArchives"
  • Try to obtain the "full" Eclipse project model for TestProject2. (In Eclipse/STS this happens when you run "Refresh Dependencies").

The following errors are reported (but trying to compile the project with gradle on the commandline "gradle package", will produce no errors.

These errors will disappear if we modify TestProject1's build script to publish a sources.jar. (And then we hit another Tooling API bug, which I will raise a separate Jira for).

Note: the Gradle build daemon is an experimental feature.
As such, you may experience unexpected build failures. You may need to occasionally stop the daemon.
:: problems summary ::
:::: WARNINGS
		module not found: org.myorg#Testproject1;0.1

	==== clientModule: tried

	==== internal-repository: tried

	==== fileRepo: tried

	  -- artifact org.myorg#Testproject1;0.1!Testproject1.jar(source):

	  /home/kdvolder/tmp/davide/Testproject2/../repo/Testproject1-0.1-sources.jar

	  /home/kdvolder/tmp/davide/Testproject2/../repo/Testproject1-sources.jar

		::::::::::::::::::::::::::::::::::::::::::::::

		::          UNRESOLVED DEPENDENCIES         ::

		::::::::::::::::::::::::::::::::::::::::::::::

		:: org.myorg#Testproject1;0.1: not found

		::::::::::::::::::::::::::::::::::::::::::::::



FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration 'detachedConfiguration1':
    - unresolved dependency: org.myorg#Testproject1;0.1: not found


* Try:
Run with --info or --debug option to get more log output.

* Exception is:
org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration 'detachedConfiguration1':
    - unresolved dependency: org.myorg#Testproject1;0.1: not found

	at org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver$ResolvedConfigurationImpl.rethrowFailure(DefaultIvyDependencyResolver.java:100)
	at org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyResolver$1.rethrowFailure(SelfResolvingDependencyResolver.java:78)
	at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService$ErrorHandlingResolvedConfiguration.rethrowFailure(ErrorHandlingIvyService.java:80)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:477)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:169)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.getFiles(ClasspathFactory.groovy:137)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.this$2$getFiles(ClasspathFactory.groovy)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory$this$2$getFiles.callCurrent(Unknown Source)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.getLibraries(ClasspathFactory.groovy:65)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.getDependencies(ClasspathFactory.groovy:50)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.this$2$getDependencies(ClasspathFactory.groovy)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory$this$2$getDependencies.callCurrent(Unknown Source)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.createEntries(ClasspathFactory.groovy:36)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory$createEntries.call(Unknown Source)
	at org.gradle.plugins.ide.eclipse.model.EclipseClasspath.resolveDependencies(EclipseClasspath.groovy:198)
	at org.gradle.tooling.internal.provider.ModelBuilder.populate(ModelBuilder.java:75)
	at org.gradle.tooling.internal.provider.ModelBuilder.buildAll(ModelBuilder.java:59)
	at org.gradle.tooling.internal.provider.ModelBuildingAdapter.projectsEvaluated(ModelBuildingAdapter.java:37)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.messaging.dispatch.BroadcastDispatch.dispatch(BroadcastDispatch.java:88)
	at org.gradle.messaging.dispatch.BroadcastDispatch.dispatch(BroadcastDispatch.java:32)
	at org.gradle.messaging.dispatch.BroadcastDispatch.dispatch(BroadcastDispatch.java:88)
	at org.gradle.messaging.dispatch.BroadcastDispatch.dispatch(BroadcastDispatch.java:32)
	at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:75)
	at $Proxy5.projectsEvaluated(Unknown Source)
	at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:142)
	at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:112)
	at org.gradle.initialization.DefaultGradleLauncher.getBuildAnalysis(DefaultGradleLauncher.java:91)
	at org.gradle.tooling.internal.provider.BuildModelAction.run(BuildModelAction.java:44)
	at org.gradle.tooling.internal.provider.DelegatingBuildModelAction.run(DelegatingBuildModelAction.java:42)
	at org.gradle.tooling.internal.provider.ConfiguringBuildAction.run(ConfiguringBuildAction.java:56)
	at org.gradle.launcher.DefaultGradleLauncherActionExecuter.execute(DefaultGradleLauncherActionExecuter.java:49)
	at org.gradle.launcher.DaemonMain.build(DaemonMain.java:151)
	at org.gradle.launcher.DaemonMain.doRunWithExceptionHandling(DaemonMain.java:140)
	at org.gradle.launcher.DaemonMain.doRunWithLogging(DaemonMain.java:122)
	at org.gradle.launcher.DaemonMain.doRun(DaemonMain.java:102)
	at org.gradle.launcher.DaemonMain.access$000(DaemonMain.java:44)
	at org.gradle.launcher.DaemonMain$1.handle(DaemonMain.java:83)
	at org.gradle.launcher.DaemonConnector$1.execute(DaemonConnector.java:155)
	at org.gradle.launcher.DaemonConnector$1.execute(DaemonConnector.java:151)
	at org.gradle.messaging.remote.internal.inet.TcpIncomingConnector$Receiver.run(TcpIncomingConnector.java:118)
	at org.gradle.messaging.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)


BUILD FAILED

Total time: 0.238 secs


 Comments   
Comment by Kris De Volder [ 17/Jun/11 ]

BTW: I tried this with M3 and also with a locally build gradle from the git master branch... with the same result.

Comment by Kris De Volder [ 03/Oct/11 ]

I'v tried something similar to what is described in this bug report and am still getting the buggy behavior this is using
latest snapshot of Gradle as well as the latest snapshot of the Tooling API (enclosed in the nightly STS integration test build).

This was after a user (Davide Cavestro) reported still having problems with this particular issue on the STS forum:
http://forum.springsource.org/showthread.php?115395-STS-Gradle-refresh-gradle-deps-fails-on-flatDir-deps-repo-without-source-jars

I've retraced the steps described by Davide and it seems this bug is not fixed after all?

I'll attach my current test project shortly, just in case it triggers the bug where my other test project perhaps does not (I have not retried the previous test project, it may or may not still triggere buggy behavior, I can't say).

Comment by Kris De Volder [ 03/Oct/11 ]

Attached a second test project in 'bonkers.zip'.

IMPORTANT: The project as is does not trigger the bug. To trigger the bug, one has to remove the "jdom-sources.jar" from the lib folder.
Then try to refresh the project in STS:

Note: the Gradle build daemon is an experimental feature.
As such, you may experience unexpected build failures. You may need to occasionally stop the daemon.
:: problems summary ::
:::: WARNINGS
		module not found: #jdom;

	==== clientModule: tried

	==== internal-repository: tried

	==== 251f0lbl29i8s92ig6823ggecq: tried

	  -- artifact #jdom;!jdom.jar(source):

	  /tmp/workspace-sts-2.8.0.RC1/bonkers/lib/jdom--sources.jar

	  /tmp/workspace-sts-2.8.0.RC1/bonkers/lib/jdom-sources.jar

	==== MavenRepo: tried

	  http://repo1.maven.org/maven2//jdom//jdom-.pom

	  -- artifact #jdom;!jdom.jar(source):

	  http://repo1.maven.org/maven2//jdom//jdom--sources.jar

		::::::::::::::::::::::::::::::::::::::::::::::

		::          UNRESOLVED DEPENDENCIES         ::

		::::::::::::::::::::::::::::::::::::::::::::::

		:: #jdom;: not found

		::::::::::::::::::::::::::::::::::::::::::::::



FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration 'detachedConfiguration1':
    - unresolved dependency: #jdom;: not found


* Try:
Run with --info or --debug option to get more log output.

* Exception is:
org.gradle.api.artifacts.ResolveException: Could not resolve all dependencies for configuration 'detachedConfiguration1':
    - unresolved dependency: #jdom;: not found

	at org.gradle.api.internal.artifacts.ivyservice.DefaultIvyDependencyResolver$ResolvedConfigurationImpl.rethrowFailure(DefaultIvyDependencyResolver.java:100)
	at org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyResolver$1.rethrowFailure(SelfResolvingDependencyResolver.java:78)
	at org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingIvyService$ErrorHandlingResolvedConfiguration.rethrowFailure(ErrorHandlingIvyService.java:80)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:477)
	at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:169)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.getFiles(ClasspathFactory.groovy:155)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.this$2$getFiles(ClasspathFactory.groovy)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory$this$2$getFiles.callCurrent(Unknown Source)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.getLibraries(ClasspathFactory.groovy:83)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.getEntriesFromConfigurations(ClasspathFactory.groovy:69)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.this$2$getEntriesFromConfigurations(ClasspathFactory.groovy)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory$this$2$getEntriesFromConfigurations.callCurrent(Unknown Source)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory.createEntries(ClasspathFactory.groovy:35)
	at org.gradle.plugins.ide.eclipse.model.internal.ClasspathFactory$createEntries.call(Unknown Source)
	at org.gradle.plugins.ide.eclipse.model.EclipseClasspath.resolveDependencies(EclipseClasspath.groovy:136)
	at org.gradle.tooling.internal.provider.ModelBuilder.populate(ModelBuilder.java:76)
	at org.gradle.tooling.internal.provider.ModelBuilder.buildAll(ModelBuilder.java:57)
	at org.gradle.tooling.internal.provider.ModelBuildingAdapter.projectsEvaluated(ModelBuildingAdapter.java:39)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
	at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.messaging.dispatch.BroadcastDispatch.dispatch(BroadcastDispatch.java:88)
	at org.gradle.messaging.dispatch.BroadcastDispatch.dispatch(BroadcastDispatch.java:32)
	at org.gradle.messaging.dispatch.BroadcastDispatch.dispatch(BroadcastDispatch.java:88)
	at org.gradle.messaging.dispatch.BroadcastDispatch.dispatch(BroadcastDispatch.java:32)
	at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:75)
	at $Proxy6.projectsEvaluated(Unknown Source)
	at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:142)
	at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:112)
	at org.gradle.initialization.DefaultGradleLauncher.getBuildAnalysis(DefaultGradleLauncher.java:91)
	at org.gradle.tooling.internal.provider.BuildModelAction.run(BuildModelAction.java:42)
	at org.gradle.tooling.internal.provider.DelegatingBuildModelAction.run(DelegatingBuildModelAction.java:42)
	at org.gradle.tooling.internal.provider.ConfiguringBuildAction.run(ConfiguringBuildAction.java:56)
	at org.gradle.launcher.DefaultGradleLauncherActionExecuter.execute(DefaultGradleLauncherActionExecuter.java:49)
	at org.gradle.launcher.DaemonMain.build(DaemonMain.java:143)
	at org.gradle.launcher.DaemonMain.doRunWithExceptionHandling(DaemonMain.java:132)
	at org.gradle.launcher.DaemonMain.doRunWithLogging(DaemonMain.java:114)
	at org.gradle.launcher.DaemonMain.doRun(DaemonMain.java:94)
	at org.gradle.launcher.DaemonMain.access$000(DaemonMain.java:45)
	at org.gradle.launcher.DaemonMain$1.handle(DaemonMain.java:75)
	at org.gradle.launcher.DaemonConnector$1.execute(DaemonConnector.java:165)
	at org.gradle.launcher.DaemonConnector$1.execute(DaemonConnector.java:161)
	at org.gradle.messaging.remote.internal.TcpIncomingConnector$Receiver.run(TcpIncomingConnector.java:102)
	at org.gradle.messaging.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:63)


BUILD FAILED

Total time: 0.894 secs

Put the sources.jar file back and the problem goes away again.

Commandline tools don't seem to care whether or not the sources jar is there and work either way. I've tried both "./gradlew assemble" and "./gradlew test".

Comment by Szczepan Faber [ 03/Oct/11 ]

Hey Kris!

I cannot reproduce it either in STS or command line. E.g. if you apply the eclipse plugin to the project you must be able to reproduce this behavior outside STS using 'gradlew eclipse'. Tooling-api is using the eclipse plugin behind the scenes.

I must admit I didn't get latest STS, I've just used whatever I had installed previously.

Can you tell me on what environment you have reproduced it?

Comment by Davide Cavestro [ 04/Oct/11 ]

@Szczepan
on the bonkers project provided by kris, I was able to reproduce the problem only for gradle-1.0-milestone-4 after:

  • removing the jdom-sources.jar file from the lib folder
  • adding apply plugin: 'eclipse' into the build.gradle script
  • call gradle eclipse

UPDATE: Initially I thought the problem affected even the milestone-5 branch, but then I noticed that it works properly... only showing a warning for the missing sources. It works both for gradle-1.0-milestone-5-20110922000019+0200 and gradle-1.0-milestone-5-20110927091445+0200.
So maybe, as Kris said on the forum, we should try an M5 branch based STS build.

This is the output of successful execution

davide@ws-davide:~/devel/sts/bonkers$ ~/opt/gradle-1.0-milestone-5-20110927091445+0200/bin/gradle eclipse
:eclipseClasspath
:: problems summary ::
:::: WARNINGS
		module not found: #jdom;

	==== flatDir: tried

	  -- artifact #jdom;!jdom.jar(source):

	  /home/davide/devel/sts/bonkers/lib/jdom--sources.jar

	  /home/davide/devel/sts/bonkers/lib/jdom-sources.jar

	==== MavenRepo: tried

	  http://repo1.maven.org/maven2//jdom//jdom-.pom

	  -- artifact #jdom;!jdom.jar(source):

	  http://repo1.maven.org/maven2//jdom//jdom--sources.jar

		::::::::::::::::::::::::::::::::::::::::::::::

		::          UNRESOLVED DEPENDENCIES         ::

		::::::::::::::::::::::::::::::::::::::::::::::

		:: #jdom;: not found

		::::::::::::::::::::::::::::::::::::::::::::::


:eclipseJdt
:eclipseProject
:eclipse

BUILD SUCCESSFUL

Cheers
Davide

Comment by Kris De Volder [ 04/Oct/11 ]

I've tried just using commandline with the 'bonkers' project as follows.

1) unzip bonker project
2) add "apply plugin: 'eclipse'" to build.gradle
3) cd lib ; mv jdom-sources.jar jdom-sources-DELETED.jar
4) ./gradlew cleanEclipse eclipse

I get a 'build succesfull' but also get resolving error messages related to the JDom jar.

Nevertheless the jdom dependency is present in the .classpath that was generated.

So indeed, using the commandline tooling the problem seems fixed. But this is a bug filed against the tooling API not against the gradle eclipse plugin. So I'm not entirely sure if this is the right 'test' to verify that the bug is fixed.

I'm going to go once more trying to retrace my steps and repeat the process inside a version of STS built with latest Gradle M5 snapshot tooling API jars. (Just in case I screwed up somehow

I'll report back in a few minutes.

Comment by Kris De Volder [ 04/Oct/11 ]

OK, with a version of STS tooling built on the tooling API jars of
1.0-milestone-5-20111004164322+0200
and the 'bonkers' test project...

Things seem fine. I get the warning error messages that jdom can't be resolved, but the model build does complete and also the jdom.jar does end up in the classpath container. So that seems pretty ok.

Comment by Kris De Volder [ 04/Oct/11 ]

I tried also with a version of STS tooling built on M4 tooling API jars (but still using Gradle M5 snapshot for the model build) and that works fine as well.

So sorry, I think this may be another false alarm. Latest M5 snapshot does indeed seem to have fixed the problem.

Perhaps I was just confused because the 'Warning' messages look much like the error messages from before and the 'BUILD-SUCCESFULL' dangling at the end isn't nearly as prominent to the eye as those warnings.

So it was probably working well all along.

If it were at all possible or easy to do, it may be a good idea to reduce those messages to one liners. "Warning: source for jdom not found". It may avoid confusing other unsuspecting users.

Comment by Peter Niederwieser [ 04/Oct/11 ]

The warning message is expected (though undesirable). It's coming from Ivy, and unfortunately I don't know of a way to get rid of it.

Generated at Wed Jun 30 12:00:14 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.