Hi Nacho,

thanks a lot for the overview.

As a start I have changed the way we generate the pom.xml.

There is still the Gradle MavenPom object. But under the hood it configures
a native Maven MavenProject object which we now also use to generate the
pom.xml. This MavenProject object is exposed. You can access it by:
pom.mavenProject

Those changes are committed and will allow you to add all the pieces to your
pom that you need.

The MavenPom object has a couple of responsibilities. For one it provides
convenient methods to configure the underlying native Maven object. It
doesn't offer much in this respect yet but that will grow. One typical
example would be an addDependency method as the MavenProject object only
offers setDependencies(List ...).

Another responsibility is to provide hooks. The hooks are not committed yet
but should be done soon (today). They will allow you to hook in a listener
that gets an instance of the MavenPom object after the autogeneration has
happened. Another hook will provide access to the XML before it is written
to disk.

On Tue, Feb 23, 2010 at 5:22 PM, Nacho Coloma <[email protected]> wrote:

> Good. Feel free to move this conversation to the dev list.
>
> I will be glad to test any advance here. Let me summarize my current
> situation:
>
> * Right now only apache, codehaus and sonatype are being actively
> synchronized with maven central. Of them, only sonatype is  open to
> any OSS project (older synchronizations such as sf.net are working
> fine, but any change in their current config will be moved to
> sonatype).
> * Sonatype does not have any special requirements for your artifacts
> as long as you do not want to synchronize (e.g. snapshot releases
> etc). These extra requirements (project name, license, etc) are only
> required to send your jars to maven central.
> * I was still missing an extra step. Your jars must be PGP signed,
> which can be done by hand or, most frequently, using the maven-gpg
> plugin [1].
>

> This is to say that, to complete the process, we will need to include
> maven plugins (or hash the jars by hand, which is not that
> complicated).
>

We definitely need to cover this as well eventually.

Cheers,

- Hans

--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz


>
> Again Hans, thanks for your time.
>
> -- Nacho.
> [1]
> http://www.sonatype.com/people/2010/01/how-to-generate-pgp-signatures-with-maven/
>
> On Tue, Feb 23, 2010 at 2:55 PM, Hans Dockter <[email protected]> wrote:
> > Hi Nacho,
> >
> > unfortunately I can't see any hooks for this. But I have started to work
> on
> > that. What we will do is to use a MavenProject class under the hood. We
> will
> > provide a couple of convenient methods to configure it. But you can
> always
> > access the native Maven class for configuration that is not exposed by
> the
> > Gradle class. We should even add a third layer that provides a hook into
> the
> > generated XML. I should make progress on this pretty soon. I hope I can
> > commit something tomorrow.
> >
> > - 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 12:42 PM, Nacho Coloma <[email protected]>
> wrote:
> >>
> >> Thanks Hank. I was already working on my workaround, but I'm  stuck.
> >>
> >> The following code seems to work, but I don't know how to plug it
> >> after the POM generation (I thought it was a separate task, but it's
> >> not). Any help?
> >>
> >> ===
> >>
> >> def parsedPom = new XmlSlurper().parse(new
> >> File('~/workspace/tldgen/build/poms/pom-default.xml'))
> >> parsedPom.appendNode({
> >>    name('The TLDGen project')
> >>    description('Generate TLD and HTML files from Java annotations')
> >>    url('http://code.google.com/p/tldgen/')
> >>    scm {
> >>        url('http://code.google.com/p/tldgen/source/browse/')
> >>        connection('scm:svn:http://tldgen.googlecode.com/svn/trunk/')
> >>    }
> >>    licenses {
> >>        license {
> >>            name('The Apache Software License, Version 2.0')
> >>            url('http://www.apache.org/licenses/LICENSE-2.0.txt')
> >>        }
> >>    }
> >>    developers {
> >>        developer {
> >>            id('icoloma')
> >>            name('Ignacio Coloma')
> >>            email('[email protected]')
> >>        }
> >>    }
> >>
> >> }
> >> )
> >>
> >> def output = new groovy.xml.StreamingMarkupBuilder().bind {
> >>    mkp.xmlDeclaration()
> >>    mkp.declareNamespace("":"http://maven.apache.org/POM/4.0.0";)
> >>    mkp.yield parsedPom
> >> }
> >> println groovy.xml.XmlUtil.serialize(output)
> >>
> >>
> >>
> >> On Mon, Feb 22, 2010 at 12:41 PM, Hans Dockter <[email protected]> wrote:
> >> > 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
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
>

Reply via email to