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
>>> 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 <[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
>>
>
--
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
