Use of SBT for Builds

[benjchristensen]

Anyone else having issues with SBT? I am spending more time fighting SBT than building.

Since this is a Java project, any reason to not stick with Maven or Gradle?

[viktorklang]

What issues are you having?

[benjchristensen]

I am using the SBT Eclipse plugin, and it generates the correct project files, but the classpaths are somehow broken so that things compile, but nothing can be executed. It always says it can't find the classes, even though the code is compiling. I spent about 30 minutes trying to get SBT working, and trying to manually fix the Eclipse project setup and gave up, deleted the project and re-created it manually without SBT so I can both build and execute the code in Eclipse.

This is with Eclipse Kepler and sbt launcher version 0.13.1

addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.4.0")

[viktorklang]

Sounds weird, if you run sbt in a terminal, does it work just fine?

[benjchristensen]

In the terminal yes, it works fine.

[viktorklang]

Alright, could be an sbt-eclipse issue then, great that it works in the terminal (I always run sbt in terminal only).

[rkuhn]

I think the problem is that we removed the scala library from the classpath, which the Eclipse plugin does not cope with, but I currently do not have the bandwidth to fix that.

[viktorklang]

@rkuhn Since the project is technically no longer a Scala project, that may very well be.

[banshee]

A little bit more detail - sbteclipse creates Eclipse Scala projects, not java projects. You'll see that in the .project files, where the build command is set to org.scala-ide.sdt.core.scalabuilder, and the project has org.scala-ide.sdt.core.scalanature:

<projectDescription>
  <name>reactive-streams-spi</name>
  <buildSpec>
    <buildCommand>
      <name>org.scala-ide.sdt.core.scalabuilder</name>
    </buildCommand>
  </buildSpec>
  <natures>
    <nature>org.scala-ide.sdt.core.scalanature</nature>
    <nature>org.eclipse.jdt.core.javanature</nature>
  </natures>
  <linkedResources> </linkedResources>
</projectDescription>

I think benjchristensen's comment that "it generates the correct project files" isn't really correct; sbteclipse isn't doing the right thing. (To be fair, sbteclipse isn't advertised as being capable of generating Java projects.)

[benjchristensen]

Then should we migrate to maven or gradle, or will sbt be changed to support a pure java project including IDEs?

[rkuhn]

Seems to be a matter of configuration: https://github.com/typesafehub/sbteclipse/wiki/Using-sbteclipse#projectflavor

[rkuhn]

@benjchristensen can you try out my PR to see if it works for you as well?

[benjchristensen]

That fixed the issue, thank you.

Now this is no longer a blocker and it can be okay to use SBT, but it is still something that plain Java projects do not normally use, and IDEs do not have native plugins (everything is done from command line to build project files).

Considering this and the intent to have this project be broadly adopted for plain Java, I still suggest considering either Maven or Gradle that support IDEs better.

/cc @jbrisbin @smaldini for your input on this.

[jbrisbin]

Maven is more widely-supported across IDE versions (being older) so is a logical choice for maximum compatibility, while Gradle is certainly the up-and-comer (we use it extensively at Pivotal) but oftens lags behind Maven in IDE support.

That said, Gradle build files are considerably more succinct and easy to read, being Groovy code and not XML. My own preference would be for Gradle since it's more forward-focussed than Maven and will continue to improve whereas Maven is basically as developed as its ever going to get. IMHO Gradle will appeal to a wider audience of early adopters and implementors better than Maven will (though I admit that's a purely subjective assessment :)).