[GRADLE-1072] gradle repeatedly attempts to download pom files for "@war" dependency Created: 28/Jul/10  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Luke Taylor Assignee: Unassigned
Resolution: Won't Fix Votes: 0

Attachments: File cas.gradle    

 Description   

In the Spring Security CAS sample build file (attached), I define a separate task of type JettyRunWar, with a separate configuration called "casServer":

configurations {
casServer
}

dependencies {
casServer "org.jasig.cas:cas-server-webapp:3.4.2.1@war"
...
}

Then in the task body I use:

webApp = configurations.casServer.resolve().toArray()[0]

to set the WAR.

The build always downloads the pom files (and related ones) from Maven Central (where they are present):

Evaluating project ':spring-security-samples-cas' using build file '/Users/luke/Work/spring-security/samples/cas/cas.gradle'.
:: resolving dependencies :: org.springframework.security#spring-security-samples-cas;3.1.0.CI-SNAPSHOT
confs: [casServer]
Download http://repo1.maven.org/maven2/org/jasig/cas/cas-server-webapp/3.4.2.1/cas-server-webapp-3.4.2.1.pom
Download http://repo1.maven.org/maven2/org/jasig/cas/cas-server/3.4.2.1/cas-server-3.4.2.1.pom
Download http://repo1.maven.org/maven2/org/jasig/jasig-parent/7/jasig-parent-7.pom
found org.jasig.cas#cas-server-webapp;3.4.2.1 in MavenRepo

According to Adam on IRC, it shouldn't attempt to access the pom file at all if the "@war" syntax is being used.

 Comments   
Comment by Hans Dockter [ 28/Jul/10 ]

Did this happen before you upgraded as well? I think you can't prevent Ivy's default resolver from doing this. If the pom is there it will be downloaded, even if it is not used. We would need to modify the IBiblio resolver to improve (which we do anyhow for other stuff).

Comment by Hans Dockter [ 28/Jul/10 ]

Is this with preview-3?

Comment by Luke Taylor [ 28/Jul/10 ]

This is with a trunk build. The issue is that it always tries to download the poms and doesn't cache them. As discussed with Hans, a workaround is to use

dependencies { casServer("org.jasig.cas:cas-server-webapp:3.4.2.1")

{ transitive = false }

}

Comment by Luke Taylor [ 02/Aug/10 ]

My mistake. This isn't actually working. After (another) discussion with Hans , it seems that ivy is having a problem specifically with these poms:

17:00:45.123 [main] DEBUG org.gradle.logging.IvyLoggingAdaper - No entry is found in the ModuleDescriptorCache : /Users/luke/.gradle/cache/org.jasig.cas/cas-server-webapp/ivy-3.4.2.1.xml
17:00:45.127 [main] DEBUG org.gradle.logging.IvyLoggingAdaper - problem while parsing cached ivy file for: org.jasig.cas#cas-server-webapp;3.4.2.1: AElfred parser is non-validating in file:/Users/luke/.gradle/cache/org.jasig.cas/cas-server-webapp/ivy-3.4.2.1.xml

Comment by Luke Taylor [ 22/Aug/10 ]

I'm seeing the same thing with the ant-jsch dependency. If I have

project.configurations.add('antjsch')
project.dependencies

{ antjsch 'org.apache.ant:ant-jsch:1.8.1' }

def classpath = project.configurations.antjsch.asPath
project.ant

{ taskdef(name: 'scp', classname: 'org.apache.tools.ant.taskdefs.optional.ssh.Scp', classpath: classpath) taskdef(name: 'sshexec', classname: 'org.apache.tools.ant.taskdefs.optional.ssh.SSHExec', classpath: classpath) }

in a task class which uses Ant's SCP task, I get:

16:00:06.137 [main] DEBUG org.gradle.logging.IvyLoggingAdaper - No entry is found in the ModuleDescriptorCache : /Users/luke/.gradle/cache/org.apache.ant/ant-jsch/ivy-1.8.1.xml
16:00:06.139 [main] DEBUG org.gradle.logging.IvyLoggingAdaper - problem while parsing cached ivy file for: org.apache.ant#ant-jsch;1.8.1: AElfred parser is non-validating in file:/Users/luke/.gradle/cache/org.apache.ant/ant-jsch/ivy-1.8.1.xml

Comment by Luke Taylor [ 22/Aug/10 ]

This seems to be because I'm using Saxon 6.5.3 for XSL support in my docbook plugin (which resides in the buildSrc directory). This unfortunately contains its own parser, which is picked up by Java's "services" mechanism. If I reorder the dependencies in my buildSrc/build.gradle to place xerces above it, xerces takes precedence and the problem goes away.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:46:11 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.