Detecting project class type in plugin to fix Play 2 bug

18 views
Skip to first unread message

benmccann

unread,
Jul 21, 2012, 5:22:29 PM7/21/12
to simple-b...@googlegroups.com
Hi,

There is a bug in Play 2's sbtgoodies plugin.  The plugin adds a "dist-unzip" task to all projects.  However, since it depends on Play's "dist" task, it fails if you have any non-Play projects in your build file since it tries to apply it to those projects and cannot.  I believe SbtGoodiesPlugin.scala is where this is happening:

object SbtGoodiesPlugin extends Plugin with SbtGoodiesTasks {
  override def settings: Seq[Setting[_]] = super.settings ++ Seq(
     distUnzip <<= distUnzipTask,
     distUnzip <<= distUnzip.dependsOn(PlayProject.dist)
  )
}

I'd like to fix this, but I'm totally stumped.  Are there any tips you can give me to get me pointed in the right direction?  Can I detect whether the current project is a PlayProject somehow before extending the settings?

Thanks,
Ben

Josh Suereth

unread,
Jul 22, 2012, 10:55:35 AM7/22/12
to simple-b...@googlegroups.com
You can actually detect whether or not the current project *has* a PlayProject.dist setting defined.   That's a bit spiffier.

So, you'll have to deconstruct the distUnzipTask.

(PlayProject.dist.?? zip (foo, bar, baz)) apply { 
  case (None, _) => // Not a play project, return an empty task.
  case (Some(dist), (foo, bar, baz)) =>  
     // Here's where it gets funky, maybe mark can help here?  I'm writing this off the cuff, and I can dig in to give you exact syntax if needed.
     Task(myImplementation(foo,bar,baz)) dependOn dist
}

Note: I highly recommend, when defining tasks, to have a pure function which implements them in addition to/rather than a single member which initializes them.   This way, you have more flexibility in how you wire things together, as do your users.

- Josh


--
You received this message because you are subscribed to the Google Groups "simple-build-tool" group.
To view this discussion on the web visit https://groups.google.com/d/msg/simple-build-tool/-/kMkudUBCSOwJ.
To post to this group, send email to simple-b...@googlegroups.com.
To unsubscribe from this group, send email to simple-build-t...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/simple-build-tool?hl=en.

Ben McCann

unread,
Jul 22, 2012, 4:52:59 PM7/22/12
to simple-b...@googlegroups.com
Thanks for the tip Josh.  I found in the SBT Plugins Best Practices doc that "Overriding val settings should only be done by plugins intending to provide commands. Regular plugins defining tasks and settings should provide a sequence named after the plugin.", so I've gone ahead and made a pull request that makes that change, which solves the problem just fine for me.

Your solution seems pretty interesting, but I'm afraid given my lack of SBT knowledge it's a bit tough for me to comprehend.  Which file would that code go in?  Is there some variable that is assigned the value of that construct or is it a stand-alone construct?

Thanks,
Ben
Reply all
Reply to author
Forward
0 new messages