Provide Gradle plugin

[jacek99]

Most of our dev teams have left Maven behind and moved on to Gradle.

Would it be possible to provide a native Gradle plugin?

Thank you

[ebourg]

Hi Jacek, did you consider using the jdeb Ant task with Gradle? It should integrate nicely.

http://www.gradle.org/docs/current/userguide/ant.html

[mgarmash]

I have some working code for jdeb and Gradle integration, but now it's just a few tasks using jdeb-ant. I plan to rewrite it and release as gradle plugin.

[tbroyer]

👍

[bedge]

Ditto on the up-vote.

[rspieldenner]

We wrote one over at nebula-plugins on github https://github.com/nebula-plugins/gradle-ospackage-plugin

[bedge]

@rspieldenner - gradle-ospackage-plugin is friggin cool. Worked right out of the proverbial box.

[tbroyer]

gradle-ospackage-plugin has a few show-stopper limitations, so I used the JDeb API right from my Gradle build file:

  def resolver = new MapVariableResolver([
      name:        ext.packageName.toString(),
      version:     ext.getVersion().toString(),
      description: '',
      homeDir:     ext.homeDir.toString(),
      userName:    ext.userName.toString(),
      groupName:   ext.groupName.toString(),
  ])
  def dataProducers = [
      new DataProducerFiles(configurations.distLib.asList() as String[], "${ext.homeDir}/lib", [
          new PermMapper(-1, -1, userName, groupName, -1, -1, 0, null)
      ] as Mapper[]),
      new DataProducerFile(file('src/main/resources/bin/launcher.sh'), "${ext.homeDir}/bin/${ext.packageName}", null, null, [
          new PermMapper(-1, -1, userName, groupName, 0775, -1, 0, null)
      ] as Mapper[]),
      new DataProducerFile(file("$buildDir/tmp/init.d/service.sh"), "/etc/init.d/${ext.packageName}", null, null, [
          new PermMapper(-1, -1, userName, groupName, 0755, -1, 0, null)
      ] as Mapper[]),
      new DataProducerPathTemplate(["/var/log/${ext.packageName}"] as String[], null, null, [
          new PermMapper(-1, -1, userName, groupName, -1, -1, 0, null)
      ] as Mapper[]),
  ]
  def conffileProducers = [
      new DataProducerDirectory(file("$buildDir/tmp/etc/"), null, null, [
          new PermMapper(-1, -1, userName, groupName, -1, -1, 0, "/etc/${ext.packageName}")
      ] as Mapper[]),
  ]

  DebMaker maker = new DebMaker(new LoggerConsole(logger), dataProducers + conffileProducers, conffileProducers)

  maker.deb = file("${buildDir}/distributions/${ext.packageName}.deb")
  maker.control = file("${projectDir}/src/deb/control/")
  maker.resolver = resolver

  maker.validate()
  maker.makeDeb()

I had to make a LoggerConsole class for that to work:

class LoggerConsole implements Console {

  private logger

  LoggerConsole(logger) {
    this.logger = logger
  }

  @Override
  void debug(String message) {
    logger.debug(message)
  }

  @Override
  void info(String message) {
    logger.info(message)
  }

  @Override
  void warn(String message) {
    logger.warn(message)
  }
}

FWIW, I also created a DataProducerFilteredFile that copies a file (like DataProducerFile) while resolving variables (with Utils.resolveVariables()); so I don't actually use the $buildDir/tmp like shown above.

A few of those things are internal classes so it could break when I update JDeb.

The alternative was using the Ant task from Gradle, which I did in another project but it doesn't support "path templates" like in Maven (same project, before we moved to Gradle) so I had to hack something using a temporary folder, and do the filtering using a Gradle Copy/Sync task as an intermediate step. I find my "direct" approach above "cleaner".

One thing that really bothers me though: JDeb is only one JAR with dependencies on both Ant (needed anyway for various things) and Maven. It'd be so much cleaner if there was a "core" API separated from the build-tool integrations.

[rspieldenner]

Could you add the showstoppers as issues so we can address them on gradle-ospackage?

Sent from my iPhone

On Jun 12, 2015, at 9:18 AM, Thomas Broyer notifications@github.com wrote:

gradle-ospackage-plugin has a few show-stopper limitations, so I used the JDeb API right form my Gradle build file:

def resolver = new MapVariableResolver([
name: ext.packageName.toString(),
version: ext.getVersion().toString(),
description: '',
homeDir: ext.homeDir.toString(),
userName: ext.userName.toString(),
groupName: ext.groupName.toString(),
])
def dataProducers = [
new DataProducerFiles(configurations.distLib.asList() as String[], "${ext.homeDir}/lib", [
new PermMapper(-1, -1, userName, groupName, -1, -1, 0, null)
] as Mapper[]),
new DataProducerFile(file('src/main/resources/bin/launcher.sh'), "${ext.homeDir}/bin/${ext.packageName}", null, null, [
new PermMapper(-1, -1, userName, groupName, 0775, -1, 0, null)
] as Mapper[]),
new DataProducerFilteredFile(file("$buildDir/tmp/init.d/service.sh"), "/etc/init.d/${ext.packageName}", null, null, [
new PermMapper(-1, -1, userName, groupName, 0755, -1, 0, null)
] as Mapper[]),
new DataProducerPathTemplate(["/var/log/${ext.packageName}"] as String[], null, null, [
new PermMapper(-1, -1, userName, groupName, -1, -1, 0, null)
] as Mapper[]),
]
def conffileProducers = [
new DataProducerDirectory(file("$buildDir/tmp/etc/"), null, null, [
new PermMapper(-1, -1, userName, groupName, -1, -1, 0, "/etc/${ext.packageName}")
] as Mapper[]),
]

DebMaker maker = new DebMaker(new LoggerConsole(logger), dataProducers + conffileProducers, conffileProducers)

maker.deb = file("${buildDir}/distributions/${ext.packageName}.deb")
maker.control = file("${projectDir}/src/deb/control/")
maker.resolver = resolver

maker.validate()
maker.makeDeb()
I had to make a LoggerConsole class for that to work:

class LoggerConsole implements Console {

private logger

LoggerConsole(logger) {
this.logger = logger
}

@OverRide
void debug(String message) {
logger.debug(message)
}

@OverRide
void info(String message) {
logger.info(message)
}

@OverRide
void warn(String message) {
logger.warn(message)
}
}
FWIW, I also created a DataProducerFilteredFile that copies a file (like DataProducerFile) while resolving variables (with Utils.resolveVariables()); so I don't actually use the $buildDir/tmp like shown above.

A few of those things are internal classes so it could break when I update JDeb.

The alternative was using the Ant task from Gradle, which I did in another project but it doesn't support "path templates" like in Maven (same project, before we moved to Gradle) so I had to hack something using a temporary folder, and do the filtering using a Gradle Copy/Sync task as an intermediate step. I find my "direct" approach above "cleaner".

One thing that really bothers me though: JDeb is only one JAR with dependencies on both Ant (needed anyway for various things) and Maven. It'd be so much cleaner if there was a "core" API separated from the build-tool integrations.

—
Reply to this email directly or view it on GitHub.

[tbroyer]

Could you add the showstoppers as issues so we can address them on gradle-ospackage?

Done: nebula-plugins/gradle-ospackage-plugin#84, nebula-plugins/gradle-ospackage-plugin#114 and nebula-plugins/gradle-ospackage-plugin#115 (to be fair, only # 114 was a real showstopper actually)

[tcurdt]

also see #228

[gesellix]

Have you seen this: https://github.com/gesellix/gradle-debian-plugin as alternative to the nebula plugins?

Disclaimer: I'm the owner/maintainer of that plugin, but didn't invest much time recently in giving it some love.

I won't be able to tell you about pros and cons, because I didn't compare them, yet. Only one thing to note: "My" plugin acts as wrapper to JDeb, so that it's less opinionated. For some folks this might be good, others consider it to be bad ;-)