SBT Native Packager - Auto Plugins

AutoPlugins.scala

// API proposal # 1
lazy val root = project(file(".")
  .enablePlugins(SbtNativePackager, JavaServerArchetype)
  .settings(
    "maintainer" in Debian := "Your Name <your.name@your-company.com"
  )
)

// Implementation may look like
object SbtNativePackager extends AutoPlugin
 with linux.LinuxPlugin with ... {
  
  object autoimport extends linux.Keys.autoimport with ...
  
  // projectSettings or buildSettings ?
  override lazy val buildSettings = linuxSettings ++ ...
}

// API proposal # 2
lazy val root = project(file(".")
  .enablePlugins(UniversalPackagingPlugin, NativeDebianPackagingPlugin, JavaServerArchetype)
  .settings(
    "maintainer" in Debian := "Your Name <your.name@your-company.com"
  )
)

// Implementation may look like
object UniversalPackagingPlugin extends AutoPlugin {
  
  object autoimport {
    
  }
  
  // projectSettings or buildSettings ?
  override lazy val buildSettings = Seq(...)
}

object WindowsPlugin extends AutoPlugin {
  
  override def requires = UniversalPackagingPlugin
  
  object autoimport {
    
  }
  
  // projectSettings or buildSettings ?
  override lazy val buildSettings = Seq(...)
}

Close, but actually with AutoPlugins, you can have plugin dependencies And the autoImport works for ALL plugins on the classpath (not the ones enabled). For the most flexibility and least possible errors by users, I recommend the following:

// API proposal # 1

// In 0.13.6, you can do this directly in .sbt files
enablePlugins(JavaServerArchetype)   // Or JavaApplicationArchetype

"maintainer" in Debian := "Your Name <your.name@your-company.com"

And then a possible encoding

// Implementation may look like
object UniversalPackagingPlugin extends AutoPlugin {
  object autoImport extends UniversalKeys
  override lazy val projectSettings = Seq(...)
}

object WindowsPlugin extends AutoPlugin {
  override def requires = UniversalPackagingPlugin
  object autoimport extends WindowsPlugin
  // projectSettings get injected into any project this plugin is enabled by
  override lazy val projectSettings = Seq(...)
}

... (Linux, Debian, Rpm AutoPlugins)

object JavaApplicationArchetype extends AutoPlugin {
   override def requires = WindowsPlugin && DebianPlugin && DockerPlugin && RpmPlugin && UniversalPlugin
   override def projectSettings =  
      // Only those setting which adapt underlying module settings
      // TODO - what should we do about GenericToXYZ mappings, like Linux/windows
     // They can either be standalone autoplugins we depend on, or we encode them here
}

object JavaServerArchetype extends AutoPlugin {
   override def requires = JavaAppliationArchetype
   override def projectSettings =  // Only those setting which adapt JavaServerArchetype
}

IMHO the GenericToXYZ mappings should be handled by the respective plugin (Linux, Windows). If the archetypes require all these plugins, the mappings are always in place.