I was able to get this to work by modifying the configuration section by hand as seen below. However, I'd still like to know why this was (apparently) removed from Gradle's functionality in 1.5. If this was intentional, what is the proposed way to get just the artifact with no dependencies?

publishing {
publications {
ivy (IvyPublication) {
from components.java

descriptor {
withXml {
asNode().configurations*.appendNode("conf", [name: "archives", visibility: "public"])

Object o = asNode().publications.artifact.find

if(o != null)

}
}
}
}
repositories {
url "local-repo"
}
}

Hi Ryan
As you're no doubt aware, the new publishing support is a work in progress. One of the goals is to not carry over a lot of baggage from Gradle 1.0, and to focus on adding features on a use-case driven basis.

So in Gradle 1.5 we stripped our ivy/maven descriptor generation to a bare minimum, to avoid locking us into a model that we don't want to support long term. This was intentional, and for now you'll need to implement these sorts of 'old standards' yourself.

When and how do you use the 'archives' configuration? Knowing this will help us to add this feature to the design spec, and add this to the publishing model in the future.

Hi Daz,

This came up when trying to use legacy Ant+Ivy projects with Gradle. My Gradle build was publishing an artifact in the 'archives' configuration that the Ant+Ivy builds were depending on. When that disappeared in 1.5, it took some effort to make it work again. I think the frustrating thing was simply that upgrading Gradle in one build broke the others. (I do realize the plugin is incubating.)

However, you ask a really good question and as I've examined my legacy Ant+Ivy builds, I realized they probably shouldn't be asking for a single JAR in the first place (most of the time when I want a JAR, I also want it's dependencies). In other words, I should've changed those builds rather than Gradle.

I can think of some edge cases where this would have been useful, but they are pretty rare, and it's always possible to iterate through the runtime dependencies and just filter the original artifact, so there's already a workaround for them.

Lastly, I realized belatedly that I don't think Maven actually allows you to do this. The 'master' configuration is only an Ivy construct, so perhaps this really isn't needed in Gradle.

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!

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.