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]

:+1:

[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 [email protected] 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 https://github.com/tcurdt/jdeb/issues/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 ;-)

[tcurdt]

@gesellix if you have some minutes to spare I would appreciate contributions/feedback for #228