[GRADLE-2443] Gradle attempts to access missing jar file for Maven module with packaging = 'pom' Created: 22/Aug/12 Updated: 29/Jan/14 Resolved: 29/Jan/14 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Gradle Forums | Assignee: | Unassigned |
| Resolution: | Not A Bug | Votes: | 1 |
| Description |
|
Daz: 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. In order to check whether the jar artifact exists, we make an HTTP HEAD request for it. PeterN: 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. Daz: In this 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. Daz: Apparently, there are definitely some maven modules published with packaging = 'pom' and a default artifact ( |
| Comments |
| Comment by Gradle Forums [ 22/Aug/12 ] |
|
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`). |
| Comment by Gradle Forums [ 22/Aug/12 ] |
|
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.) |
| Comment by Gradle Forums [ 22/Aug/12 ] |
|
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. |
| Comment by Gradle Forums [ 22/Aug/12 ] |
|
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). |
| Comment by Gradle Forums [ 22/Aug/12 ] |
|
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. |
| Comment by François-Xavier Guillemette [ 03/Oct/12 ] |
|
Similar problem here but the build fails:
> Could not resolve group:asm, module:asm-tree, version:3.2.
Required by:
:myproject:unspecified > org.codehaus.groovy:groovy:1.8.6
> Could not resolve group:asm, module:asm-parent, version:3.2.
> Could not HEAD 'http://repo1.maven.org/maven2/asm/asm-parent/3.2/asm-parent-3.2.jar'.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
|
| Comment by Adam Murdoch [ 29/Jan/14 ] |
|
This is what maven does as well when you declare a dependency on something with package 'pom'. |