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