I should add that when I add the correct dependency for xml-apis as gradle suggests then it makes no difference to the behaviour at all.
barrymac wrote: > > Hi folks, > > My problem does not appear with version 0.8. I've been having this trouble > for a while with version 0.9. I'm using 0.9 because I didn't have much > luck customising my artifacts with 0.8 so when I discovered the lovely new > syntax in 0.9 then I decided to try it out. > > I'm using the esapi java security framework in my project but it causes > all sorts of problems for gradle seeemingly due to the depencies that it > pulls in. I've tried putting transitive: 'false' into the esapi > declaration but that makes no difference. > > I've also had to customise the configurations to exclude ant which was > being pulled down by esapi, which completely messed up gradle's ability to > run Junit. I thought this strange as I would have expected the gradle > runtime to be a totally seperate thing to the test runner, and I actually > expected this to be run in a forked JVM. Is there a way to force the JVM > to be forked without writing or overriding the junit task yourself? > > So now I have the Junit running again, but it doesn't get through the > compilation of this project. I should mention that I have a multiproject > build. So another strange thing. When I added esapi to a project which > appears second in the build list then the ant problem effected a project > higher up the chain, which is why I've ended up solving the Junit problem > before a compile task problem. > > I feel there's a bug or maybe more than one in here somewhere but I don't > have a good enough understanding of gradle to clearly document it in Jira. > > When I run the build with -s I get hundreds of repeats of the following: > at > org.gradle.api.internal.artifacts.ivyservice.DefaultIvyReportConverte > r.getResolvedDependenciesForNode(DefaultIvyReportConverter.java:135) > [gradle-cor > e-0.9-20091218060020+0300.jar:0.9-20091218060020+0300] > > If I delete all the scripts caches then the first run after that produces > a different result: > > :: problems summary :: > :::: WARNINGS > Resolution will only pick dependencies of the relocated element. > Artefa > ct and other metadata will be ignored. > > :::: ERRORS > Relocation to an other version number not supported in ivy : > xml-apis#xm > l-apis;2.0.2 relocated to xml-apis#xml-apis;1.0.b2. Please update your > dependenc > y to directly use the right version. > > This is a dependency of esapi. > > I also can't get dependency graph to be output with the "-n" option. When > I run with this option I get the same error about xmp-apis as above but > again only on the first run and followed by: > Execution failed for task ':reportTask'. > Cause: Could not resolve all dependencies for configuration 'default'. > Cause: java.lang.StackOverflowError (no error message) > > On consequent runs I get only: > > * What went wrong: > Execution failed for task ':reportTask'. > Cause: Could not resolve all dependencies for configuration 'default'. > Cause: java.lang.StackOverflowError (no error message) > > I'm surprised that adding one dependency can cause so many problems. Any > ideas? > > Barry. > > -- View this message in context: http://old.nabble.com/adding-esapi-dependency-breaks-many-many-gradle-tasks-tp26901108p26901284.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
