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]
<mailto:[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
<http://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]
<mailto:[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]
<mailto:[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] <mailto:[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]
<mailto:[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] <mailto:[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]
<mailto:[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
<http://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.
