I had this working in 1.5. Trying to update to 1.6 because I need mustRunAfter support for other reasons. My publishing is no longer working :(

The Gradle error says:

* Where:
Build file '/home/steve/projects/hibernate/hibernate-orm/build.gradle' line: 418

* What went wrong:
Execution failed for task ':hibernate-core:generatePomFileForMavenJavaPublication'.
> Failed to notify action.
   > Could not apply withXml() to generated POM
> Cannot create a Publication named 'organization' because this container does not support creating elements by name alone. Please specify which subtype of Publication to create. Known subtypes are: MavenPublication


The publishing snippet (line 418 is the one that reads `organization {`):

        publishing {
            publications {
                mavenJava(MavenPublication) {
                    from components.java

                    artifact sourcesJar {
                        classifier "sources"
                    }

                    pom.withXml {
// sadly for some reason it is not working within the closure above to define the descritpion... asNode().appendNode( 'description', subProject.pomDescription() )

                        // append additional metadata
                        asNode().children().last() + {
                            name subProject.pomName()
// ugh, see above
//                            description subProject.pomDescription()
                            url 'http://hibernate.org'
                            organization {
                                name 'Hibernate.org'
                                url 'http://hibernate.org'
                            }
                            issueManagement {
                                system 'jira'
url 'https://hibernate.atlassian.net/browse/HHH'
                            }
                            scm {
url 'http://github.com/hibernate/hibernate-orm' connection 'scm:git:http://github.com/hibernate/hibernate-orm.git' developerConnection 'scm:git:g...@github.com:hibernate/hibernate-orm.git'
                            }
                            licenses {
                                license {
name 'GNU Lesser General Public License' url 'http://www.gnu.org/licenses/lgpl-2.1.html' comments 'See discussion at http://hibernate.org/license for more details.'
                                    distribution 'repo'
                                }
                            }
                            developers {
                                developer {
                                    id 'hibernate-team'
                                    name 'The Hibernate Development Team'
                                    organization 'Hibernate.org'
                                    organizationUrl 'http://hibernate.org'
                                }
                            }
                        }

// TEMPORARY : currently Gradle Publishing feature is exporting dependencies as 'runtime' scope,
                        //      rather than 'compile'; fix that.
                        asNode().dependencies[0].dependency.each {
                            it.scope[0].value = 'compile'
                        }
                    }
                }
            }

            repositories {
                maven {
                    if ( subProject.version.endsWith( 'SNAPSHOT' ) ) {
                        name 'jboss-snapshots-repository'
url 'https://repository.jboss.org/nexus/content/repositories/snapshots'
                    }
                    else {
                        name 'jboss-releases-repository'
url 'https://repository.jboss.org/nexus/service/local/staging/deploy/maven2/'
                    }
                }
            }

            generatePomFileForMavenJavaPublication {
                destination = file("$buildDir/generated-pom.xml")
            }
        }



On 05/08/2013 06:08 PM, Adam Murdoch wrote:

On 08/05/2013, at 11:35 AM, Steve Ebersole <steven.ebers...@gmail.com <mailto:steven.ebers...@gmail.com>> wrote:

Like I said, I think its a great improvement. Y'all did great with this so far. Yes there are some things missing, but only 2 are really hitting me so far and both are on the "design plan" for publications (https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md) already:

1) this runtime versus compile scope in the generated POM issue.
2) not being able to define multiple artifacts/publications for a project.

I am not sure how common the second requirement is across projects, but wanted to explain it. Its sort of a cross between the points in https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#i-want-to-publish-multiple-ivy-or-maven-modules-from-my-project and https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#i-want-to-customise-the-ivy-or-maven-meta-data-for-a-publication. Basically I have a set of "test support" classes that I currently split out into a separate project (hibernate-testing) in order to share it between modules in the project and to let others use it easily for testing Hibernate. Ideally, I'd move these classes into another module (hibernate-core) in the project and then (a) be able to refer to it from other modules and (b) be able to publish it using the same artifactId (hibernate-testing). (a) used to be doable by using a special configuration, but not sure how I can tie that in with the new publication feature.

Something we want to do is add support for test fixtures as a first-class concept. It's a common pattern for a library component to produce some code that is to be used at test time to exercise or mock (or whatever) the production code, and we want to model this.

There would be some convention regarding where to find the test fixtures for a project, plus some convention for how to share these between projects (including publishing them), and some convention about where to make the test fixtures visible in the consumer (eg if module `a` is required at compile time, then make its test fixtures, if any, visible at test compile and runtime).

In the shorter-term (and as a step towards this), there will be some way to define additional 'usages' for a module, which you could use to manually wire this together. In practical terms, it's more or less equivalent to defining a special configuration. The test fixture jar(s) and meta-data would travel with the production jar(s) and meta-data.

The other approach for sharing test fixtures would be to map the test fixtures for the project to a second module. Possibly at some point we'll support both patterns for publishing them.

One use case where it makes some sense to publish multiple modules for a project is where the project produces multiple mutually-incompatible variants of the same thing. For example, a Groovy library that is built against both Groovy 1.8 and Groovy 2.0. Or a native shared library build for windows and linux.




On Tue 07 May 2013 06:09:25 PM CDT, Adam Murdoch wrote:

On 07/05/2013, at 10:50 PM, Steve Ebersole <steven.ebers...@gmail.com <mailto:steven.ebers...@gmail.com>
<mailto:steven.ebers...@gmail.com>> wrote:

I agree that neither is correct and that this is yet another
manifestation of bad Maven design.

But...

This is a POM.  It is specifically a Maven artifact.  In my opinion
this needs to follow Maven conventions.  That seems to be the way you
are leaning as well given the plan you are describing below.

I'd really like to stick with the Publication DSL.  It is much
simpler/better.  I updated my plugins to work with it.  And I'd like
to keep testing it for y'all.

Thanks for doing this. This new DSL is so long overdue (you know this
as much as anyone) and it's nice to make a start on it, but we
certainly don't think it's 'finished' yet. Your feedback is really
useful for driving what we tackle next with the DSL: what's missing,
what's confusing, and so on.


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara,
CA: http://www.gradlesummit.com



--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com

Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com


Reply via email to