Skip to content

Instantly share code, notes, and snippets.

@muuki88
Last active Aug 29, 2015
Embed
What would you like to do?
SBT Native Packager - Auto Plugins
// 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(...)
}
@jsuereth

This comment has been minimized.

Copy link

@jsuereth jsuereth commented Sep 28, 2014

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
}
@muuki88

This comment has been minimized.

Copy link
Owner Author

@muuki88 muuki88 commented Sep 28, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment