Need Some() to define mainClass about sbt-assembly

[eed3si9n]

When you submit an issue, please describe the reproduction steps, problem, and your expectation.
You've outlined a scenario regarding mainClass key, but I don't understand what you think should have happened.
I am guessing you're claiming that sbt-assembly should have accepted:

mainClass in assembly := "main.ClassName"

The problem is that mainClass is a common key defined by sbt itself as TaskKey[Option[String]], which makes perfect sense in my opinion. By default, sbt (or sbt-assembly) would guess the main class for you. If you explicitly want to set it, it needs Some().

[edlg]

I see three problems with your response.

1. sbt failed to find the one and only main class in my project for me, so I was forced to declare it myself.

2. Other settings don't work that way. The usual approach is exactly as you wrote, mainClass in assembly := "main.ClassName"

3. The odd behavior of "mainClass in assembly := Some(xxx) " is not documented, leaving the hapless user to sort it out from the error message.

Is just closing this bug the best way to further the cause of sbt-assembly and sbt?

[eed3si9n]

Is just closing this bug the best way to further the cause of sbt?

First, it probably should be made clear that sbt-assembly is just one plugin maintained by the community (mostly me), and is not part of the sbt project itself. The reason it's in sbt organization is mostly to do with convenience of sharing rights with other plugin authors. I closed the bug, because I did not find it actionable.

1. sbt failed to find the one and only main class in my project for me, so I was forced to declare it myself.

If sbt failed to find your main class, that should be discussed separately, probably on sbt's google group.

2. Other settings don't work that way. The usual approach is exactly as you wrote, mainClass in assembly := "main.ClassName"

Other settings like name doesn't work that way because the normal state of those settings is to have some value. mainClass may or may not have a value specified by the user, thus, Option[String] is appropriate. If that needs to be challenged it should be done on sbt's google group, not a bug to sbt-assembly.

3. The odd behavior of "mainClass in assembly := Some(xxx) " is not documented

This is something I can work on.

[edlg]

I should take the time to say how much I appreciate your plug-in. I need to package a script to move it to another machine. This plugin makes it trivial to do that with a Scala script. That makes Scala a better solution than even Groovy, which is really saying something when it comes to scripting. Thank you for all your efforts.

I do think it would help make sbt, and by extension Scala, adoption easier if the build.sbt DSL could be as simple and regular as possible. Needing to use Some() raises the bar a bit. If it's OK I might look at the source to see if there's a simple way to have a setting for the main class that would be optional w/o Some(). The default would be the value returned by a function that would try to locate the main() method. It would work just like other settings that get a sensible default if left unspecified.

[eed3si9n]

Thank you for all your efforts.

You're quite welcome. The credit also goes to the original 0.7 plugin author Coda Hale and his likely inspiration Maven Assembly Plugin.

When I ported this to sbt 0.10, I tried to reuse as many sbt built-in keys as I could, and tried to be consistent with the built-in tasks and commands. In this case, mainClass key is a setting that's used by run task. Even if changing the mainClass did make assembly "simple" in some way, reducing consistency with sbt's run or breaking many builds out there aren't worth it.

In my opinion, having Option[String] is better because it's using the type to express the lack of value instead of some "default value". If someone want to find out if the value has been set or not, they need to know the default value somehow and test if the value is the same. (What if the value set by the user is the same as the default value?)

If enough people think it's still worth the downsides, maybe some future version of sbt would address it, but again, this is not the forum to discuss it.