On 10/05/2013, at 3:05 AM, Steve Ebersole <steven.ebers...@gmail.com> wrote:
> 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 :( Oh the joys of nested closures. I'm surprised this worked in 1.5 actually. Can you please try adding the following line after: asNode().children().last() + { resolveStrategy = Closure.DELEGATE_FIRST And let me know. > > 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> 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>> 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 >> > -- Luke Daley Principal Engineer, Gradleware http://gradleware.com Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email