Hi, Gradle needs to improve here. And I will start to work on this immediately.
First of all I will add the relevant missing properties to the pom object. Furthermore there should be always a backdoor to add any property to a Maven pom (e.g. some Maven alpha version adds a new pom element which is not part of the Gradle pom object). We also will make it more intuitive to customize the Maven pom generation by using dynamic properties for the relevant domain objects (e.g. dependencies). - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz On Mon, Feb 22, 2010 at 10:53 AM, Nacho Coloma <[email protected]> wrote: > Just to make it clear: AFAIK, with the new way of uploading artifacts > to maven central (which goes through sonatype) any POM generated by > gradle will not be accepted. > > I am considering adding a task postprocessor that edits the generated > POM using the technique proposed by Paul here. I will give it a try > and post the conclusion if successful. > > Anyway, this is something that should be tacked by the maven plugin IMHO. > > On Mon, Feb 22, 2010 at 9:51 AM, Paul Speed > <[email protected]> wrote: > > I don't have much to offer but I'm also in this boat... though not as far > > along as you are, I have several projects on path to maven central when > all > > of the issues are sorted out. > > > > I'm interested enough that I've even looked into the source to see if > there > > is a way to somehow hack in a solution. I can see that there are various > > elements of a MavenPomWriter that have interfaces and implementations but > > I've found no way to inject a custom implementation. As a hack, it would > > seem that if one were to somehow override the DefaultPomModuleIdWriter > that > > it could be hacked to also output this other project information. It's > not > > it's job, but it's the only one placed at the right point in the chain to > do > > it easily. > > > > Obviously, it would be nice of the gradle project supported at least some > of > > these settings which might be more generally useful. > > > > In lieu of that, I wonder what it would take to add a sort of general > > "projectDetails" Map where any sort of string or nested Map could be set > > that would then be output in a generic way as XML to the generated POM. > > > > There wouldn't be any model checks, but at least then we could specify > > things like: > > projectDetails.description = "Foo" > > projectDetails.licenses = [ > > license = [ > > name: 'FooBar' > > url: 'http://..../' > > ] > > ] > > > > ...and so on, with minimal upfront changes required to gradle internals. > > > > Just my random $0.02, > > -Paul > > > > Nacho Coloma wrote: > >> > >> Hi, we are trying to make a final release with a gradle-generated POM. > >> SNAPSHOT releases were doing fine, but for a final release that would > >> make it to maven central the new oss.sonatype.org upload process fails > >> to validate the POM: > >> > >> Failed to validate '/org/extrema-sistemas/tldgen/1.0/tldgen-1.0.pom' > >> on repository 'orgextrema-sistemas-142'. > >> > >> No project name found in POM. > >> No project description found in POM. > >> No project URL found in POM. > >> No license found in POM. > >> No SCM URL found in POM. > >> No developers found in POM. > >> > >> I could not find any way to specify any of these in current Gradle > >> sources (even MavenPom.setLicenseHeader would not work, since it is > >> expecting a <license> XML entry). Is there anything I am missing? > >> > >> Best regards, > >> > >> Nacho. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe from this list, please visit: > >> > >> http://xircles.codehaus.org/manage_email > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
