Yaay!
Interestingly that also fixed the issue I mentioned earlier with trying
to set the description element into the POM.
On Fri 10 May 2013 04:22:37 AM CDT, Luke Daley wrote:
On 10/05/2013, at 3:05 AM, Steve Ebersole <[email protected]> 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:[email protected]: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 <[email protected]> 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 featur
e.
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 <[email protected]
<mailto:[email protected]>> 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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
