use sbt-assembly to build fat JAR

[SethTisue]

A user reports:

ran the plugin against simple cases via the commands as suggested in the README file. Although, it seems that there is a difficulty to apply the same approach when utilising Sculpt with our Gradle-based projects. When providing the settings such as -Xplugin:scala-sculpt_2.11-0.1.0.jar:spray-json_2.11-1.3.2.jar, an error “Missing scalac-plugin.xml in D:\jars\scala-sculpt-0.1.0\spray-json_2.11-1.3.2.jar” occurs. That seems right, as the JAR providing spray is not a Scalac plugin itself, but only a dependency for Sculpt. According to the documentation, -Xplugin option is supposed to point at Scalac plugins only, so I am not sure why it works out of the Gradle, when calling Scalac as shown in the README file

I'm not sure either, not knowing anything about Gradle. @typesafehub/scala-team, is there any policy or history on the question of how a Scala compiler plugin's dependencies should be handled? (and does anyone have a hypothesis about why the behavior would be different in Gradle? I'm mostly just curious.)

for the moment, I'll just add sbt-assembly and ship a fat JAR. we might want to reconsider that if scala-sculpt becomes released publicly, though. as the sbt-assembly readme says, "Publishing fat JARs out to the world is discouraged because non-modular JARs cause much sadness". if compiler plugins simply don't support additional JAR dependencies, and we're forced to ship a fat JAR, we might want to consider shading. (or maybe just see if anyone actually complains...)

[retronym]

Uberjar is probably still state of the art. http://www.scala-lang.org/old/node/6664

⚡ (scalac -Y; scalac -X) 2>&1 | grep plugin
  example: -Xplugin:option1,option2
  example: -Xplugin:option1,option2
  -Xplugin:<paths>               Load a plugin from each classpath.
  -Xplugin-disable:<plugin>      Disable plugins by name.
  -Xplugin-list                  Print a synopsis of loaded plugins.
  -Xplugin-require:<plugin>      Abort if a named plugin is not loaded.
  -Xpluginsdir <path>            Path to search for plugin archives.

[SethTisue]

I see that sbt-assembly actually does shading for you (using Jar Jar Links), so flipping that switch later wouldn't be hard.

[retronym]

Actually, it looks like the -Xplugin argument is supposed to be a a comma separated list of plugin classpaths, where each element is a classpath deliminted with platform-specific path separator.

Implementation: https://github.com/scala/scala/blob/v2.11.7/src/compiler/scala/tools/nsc/plugins/Plugins.scala#L27-L30

In any case, plugins are loaded in separate classloaders, so the usual objections to uberjars aren't as relevant.

[retronym]

The error message about "missing plugin.xml in ..." is issued at end of the list of classpath elements; the last entry is being blamed unfairly. Perhaps the issue is simply that they are using relative paths for the JARs and under Gradle the working directory is different.

[SethTisue]

thanks for the info about plugin paths. this is useful for me to know.

for now, I'm happy just sending them the fat JAR and perhaps revisiting later.

[szeiger]

I did a bit of googling and found nothing that would indicate that there is support for scala compiler plugins in gradle. Apparently you have to set the -Xplugin option manually. Maybe they're just using the wrong path separator?

[SethTisue]

Maybe they're just using the wrong path separator

but it worked outside of Gradle — he verified that first