While only for two days now, I am definitely sold on using gradle for all of my Java projects, and drop pom.xml from the root of all my projects.
However, I would like to remain maven-compatible, in the sense that I would like for a gradle task to be able to generate a suitable pom.xml at the root of the project should the user want it.
At this moment, the only reference to a pom.xml I have is in this section of the build.gradle file (this is, with very few modifications, what is found here):
uploadArchives {
repositories {
mavenDeployer {
beforeDeployment {
MavenDeployment deployment -> signing.signPom(deployment);
}
repository(url: sonatypeRepoURI) {
authentication(userName: sonatypeUsername,
password: sonatypePassword);
}
pom.project {
name "${name}";
packaging "bundle";
description "${description}";
url "${projectURL}";
scm {
url "${gitroscm}";
connection "${gitroscm}";
developerConnection "${gitrwscm}";
}
licenses {
license {
name "Lesser General Public License, version 3 or greater";
url "http://www.gnu.org/licenses/lgpl.html";
distribution "repo";
}
}
developers {
developer {
id "whocares";
name "whocares";
email "whocares";
}
}
}
}
}
}
How would I extract the pom.project
out of this very deeply nested construct into a task which could generate a pom.xml (by default, the generated pom.xml is in build/poms/pom-default.xml
and looks quite good)?
More importantly, is it possible to extract that pom.project
out of uploadArchives
while still being able to refer to it?
Full link to the build.gradle file: here.
You can use the gradle maven plugin. This adds the pom
convention method to your project, which you can use in a task to generate a pom.xml
file, like
task writeNewPom {
doLast {
pom {
project {
groupId 'org.example'
artifactId 'test'
version '1.0.0'
inceptionYear '2008'
licenses {
license {
name 'The Apache Software License, Version 2.0'
url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
distribution 'repo'
}
}
}
}.writeTo("pom.xml")
}
}
Then you call gradle createPom
to generate the pom.xml in the project root. Of all the things in the pom definition, you should really provide groupId
, artifactId
and version
, other thins like licenses
are not that important.
You can also look at this example for a project definition with some dependencies, and try running it to see what it produces.
Some of the new keywords were added and some techniques were deprecated. Please check