Added some sample Scala players + SBT build for them

[SteveDraper]

Sample players written in Scala (Random and MonteCarlo). The build is SBT and assumes the main ggp-base java has already been built (in order to add the necessary class dependency). Accordingly the .SBT file is sensitive to the relative placement of the scala code in the overall hierarchy - I have positioned it as a sibling of the Clojure and Python players.

To use build with SBT and add the resulting class files to your classpath when running Player (which will then pick up the new players by reflection)

[AlexLandau]

I don't know much about sbt, unfortunately. I assume from what I've seen that it's valuable enough for Scala users that they'd want to use it over Gradle's Scala plugin.

This might benefit from the proposed change to break up GGP-Base into multiple projects within the repository (see discussion on #91), but there's no real timeline for that.

What does it looks like to "add the resulting class files to your classpath"? Where are those files generated? Can we customize that? I'm hoping we can put that output someplace where it can automatically be picked up when running an application via Gradle.

[SteveDraper]

The class files wind up in (as a relative sub-dir of the 'scala' directory) 'target/scala.2.11/classes' - within that a package hierarchy layout containing the class files from the build, so adding that 'classes' directory to your classpath allows the JVM class loader to find them.

I could probably have the build package up a JAR if that would be more easily integrated...?

[AlexLandau]

I'd like to play around with this a little (sometime in the next week or two, probably) and see if I can get it playing nicely with the Gradle layout in both directions (sbt picks up dependencies and classes/jars produced by Gradle, Gradle application classpaths pick up things built by sbt).

[AlexLandau]

I need to try this on a machine with sbt, but I'm pretty sure we'll want build.sbt in the root of the repository and the source files in just src/main/scala/(etc.), so the 'scala' directory is a sibling of 'java' and 'resources'.

[AlexLandau]

Okay, looks like if we do that then SBT will try to build everything in src/main/java as well, but fails due to not knowing about Guava and other dependencies. We could fix that by specifying the dependencies, but it would be better to not have dependencies specified in multiple places. Next step will be to see if we can configure SBT to ignore the src/main/java files (and perhaps src/test/java and src/main/resources).

[AlexLandau]

More thoughts: Say a user wants to add a dependency to use in their Scala gamer code. Then they want to run that gamer from the Player or Kiosk app. Then SBT will need to know about the new dependency in order to compile the code, and Gradle will separately need to know about it in order to run the application.

Similarly, if they're trying to run some application from SBT, it will likely call into Guava code and need to know the dependencies in SBT.

So if we do use SBT, I think we do need it to know about dependencies to avoid massive user confusion. At that point we might just let it do the compilation of the Java files itself instead of requiring a separate Gradle command; so the two build systems would essentially be living side-by-side, both fully capable of building things. Given the existence of the Gradle Scala plugin this may be overkill. (Really, we should at least see if we can get rid of the Ant build.xml file.) If we do want to use SBT, we could consider e.g. specifying lists of dependencies in text files and having them dynamically added to the builds as dependencies. (I'm pretty sure both Gradle and SBT are flexible enough to support this. But will it work well in a multiple-project world?)

Additional note: An sbt wrapper script exists: yahoo/CMAK#4

[AlexLandau]

At this point I'm considering just adding your sample Scala players using the Gradle Scala plugin. This would take pretty minimal changes, I expect, and as long as the scala code is just for player implementations (and possibly state machine implementations used by the players) I think all the code would work together nicely.

If someone really wants to use sbt, we can figure something out, but having that build work through Gradle would mean that the set of instructions for Java-based gamers would still pretty much work the same (i.e. running the same commands from the command line to compile and run programs), so there wouldn't be a relative lack of documentation for people writing gamers in Scala. If someone wants to use Scala, but their level of sbt skill is just "run the lines on the assignment page", this would probably be a better experience.

[SteveDraper]

Alex,

That would be fine as far as I am concerned.  Gradle has decent Scala

support, and our build susyem needs in this area are extremely simple.

Steve

On Wed, Dec 30, 2015 at 9:13 PM, AlexLandau [email protected]
wrote:

At this point I'm considering just adding your sample Scala players using
the Gradle Scala plugin. This would take pretty minimal changes, I expect,
and as long as the scala code is just for player implementations (and
possibly state machine implementations used by the players) I think all the
code would work together nicely.

If someone really wants to use sbt, we can figure something out, but
having that build work through Gradle would mean that the set of
instructions for Java-based gamers would still pretty much work the same
(i.e. running the same commands from the command line to compile and run
programs), so there wouldn't be a relative lack of documentation for people
writing gamers in Scala. If someone wants to use Scala, but their level of
sbt skill is just "run the lines on the assignment page", this would
probably be a better experience.

—
Reply to this email directly or view it on GitHub
#99 (comment).