Gradle attempts to access missing jar file for Maven module with packaging = 'pom'

Old Forum Archive
1

Hi Gradle support. I have a gradle script that has a dependency defined : repositories {

mavenCentral() } dependencies {

classpath group: ‘commons-io’, name: ‘commons-io’, version: ‘2.1’, ext: ‘jar’ }

And when I execute the script the following messages appear: Download http://repo1.maven.org/maven2/commons-io/commons-io/2.1/commons-io-2.1.pom Download http://repo1.maven.org/maven2/org/apache/commons/commons-parent/22/commons-parent-22.pom Download http://repo1.maven.org/maven2/org/apache/apache/9/apache-9.pom Resource missing. [HTTP HEAD: http://repo1.maven.org/maven2/org/apache/apache/9/apache-9.jar] Resource missing. [HTTP HEAD: http://repo1.maven.org/maven2/org/apache/commons/commons-parent/22/commons-parent-22.jar]

The POM of commons-io defines a parent and that defines another parent (apache-9) for which there is no jar file available.

Questions:

  • Does that need to worry me ?

  • Can I stop gradle to look into the parent POM files of a dependency ? I tried

dependencies {

classpath (group: ‘commons-io’, name: ‘commons-io’, version: ‘2.1’, ext: ‘jar’){

transitive=false }

with the same result: - The same message appear for me when I download a snapshot release from my plugin that I develop. I use the maven plugin for uploading it into a nexus. Resource missing. [HTTP GET: http:///nexus/content/repositories/public/com/csg/gcidPlugin/1.4.7-SNAPSHOT/gcidPlugin-1.4.7-SNAPSHOT.pom]

Thanks for you support.

Detlef

2

A maven pom file gives us no indication as to whether it has an associated jar file, so we need to check to see if one exists. The “Resource missing” log messages you see are for pom files that have no associated jar file.

Short story - this is nothing to worry about, and there’s not much we can do about it, except by decreasing our logging, which we’d rather not do. (I assume you’re executing your build with ‘–info’).

3

Can’t we infer this from the POM’s packaging type? For example, POMs without artifacts have ‘pom’ packaging, POMs with a Jar have ‘jar’ packaging, and so on. (Not saying the mapping is identity.)

4

Currently, we consider the ‘jar’ artifact optional for a POM with packaging of type ‘pom’. So we include it if it exists, but it’s fine if it doesn’t. This is the behaviour we inherited from Ivy, and it may not be correct.

I’m not familiar enough with Maven to know if pom packaging + jar file is a valid idiom, or if we could safely deprecated this behaviour and remove it for Gradle 2.0.

5

I wouldn’t expect ‘pom’ packaging + Jar file to work in Maven, as the whole purpose of ‘pom’ packaging is to have a POM without an artifact. We should verify this and act accordingly.

Common use cases for ‘pom’ packaging are 1. parent POM in a multi-module build 2. “aggregate” POM (a POM with multiple dependency declarations that are often used together; client builds can then reference the POM module instead of the individual modules).

6

If that’s the case, then we should certainly deprecate the current behaviour: we’ll do this by still checking if the jar exists, but emitting a deprecation warning if it is found. Then we can change this for 2.0.

7

I’ve created GRADLE-2443 to investigate / deprecate / remove this unnecessary HTTP HEAD request.

8

@Daz, don’t you remember fixing the issue where we stopped checking for the jar file when packaging == ‘pom’ and this broke a bunch of builds (GRADLE-1975 and others)?

9

@Detlef, what’s the actual problem that you’re concerned about here? Is something failing? Is the logging message a problem? Is resolution slow?

10

Hello Adam, for me it was unclear whether something is wrong due to the log message. So from my side its only a logging issue - nothing else.

11

I’ve got a very short memory!