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 :)).

[viktorklang]

Very few should ever have to touch the build of this project as the jars should be published and used from the implementors' side. Given that sbt currently works and we have bigger fish to fry—If anybody feels strongly about changing, put together a vote and create an issue to migrate to the winning build system.
Personally I really dislike both Ant and Maven, from years of torture :)

[benjchristensen]

I also agree with Gradle being the choice. In addition to my positive experience with it, Google adopting it for Android significantly pushed it into the mainstream.

I am also in agreement that this is not high priority.

[jbrisbin]

I agree that there are more important matters at hand but I think it would be a good idea to leave this issue open in case people come here later and have similar feelings. At least it can be seen that the issue has been raised and opinions are welcome about it but that it's not at the top of the list ATM.

[benjchristensen]

Works for me ... so my vote is for someone migrating us to Gradle if they feel so inclined.

[jbrisbin]

I did a PR for that once already so it's someone else's turn. ;)

[benjchristensen]

/cc @alkemist who may be able to help out here.

[alchemist-zz]

Not sure why I was CC¹ed on this.

On 4/21/14, 3:45 PM, "Ben Christensen" notifications@github.com wrote:

/cc @alchemist https://github.com/alchemist who may be able to help out
here.

‹
Reply to this email directly or view it on GitHub
<#34 (comment)
0980847> .

[jbrisbin]

@alchemist Not sure how you ended up with a notification because the mention above was for @alkemist (with a "k" not a "ch").

[benjchristensen]

Autocorrect accidentally made it be with a ch the first time, then I updated to a k.

[ldaley]

I'd be more than happy to work on a top class Gradle build here.

[benjchristensen]

Thanks Luke!

[normanmaurer]

Yeah I think having a gradle / maven / ant build here would make the most sense and have the java dev feel like "home".

[ldaley]

Is there any scope for having the site / docs / samples built and tested?

[benjchristensen]

I don't know about site and docs. I would like to have /src/examples supported in the Gradle build in addition to the regular /src/test and /src/main

[ldaley]

So does using Gradle need more consensus? Or is it green lit?

On Wed, Apr 23, 2014 at 7:33 AM, Ben Christensen notifications@github.com
wrote:

I don't know about site and docs. I would like to have /src/examples supported in the Gradle build in addition to the regular /src/test and /src/main

Reply to this email directly or view it on GitHub:
#34 (comment)

[alexandru]

I'm a SBT user and in so far as popularity is concerned, SBT is used by almost all Scala projects, including major ones that expose Java APIs, like Typesafe's Play 2.x and Akka. In a debate of which is more popular, SBT or Gradle, I would say the jury is still out on this one.

A switch to Maven to increase its reach makes sense somewhat because Maven is the standard and its packaging and repository format is used by all alternatives anyway, even though those most affected by a change are those that are tagging releases and publishing the packages on Maven Central, since that's were you need automation - but given that this is a simple project exposing a standard API, a switch to Maven should be painless.

However a switch to Gradle doesn't make sense. Think of it from my point of view - I use SBT for every project I touch, I tolerate Maven for building other people's projects and now I would have to get familiar with a third build system. That's way too much and I wouldn't prefer a switch to Gradle for the same reasons for why the switch away from SBT is discussed.

[jrudolph]

@alexandru But this is not a Scala initiative.

Right now we should focus on something that works for the early adopters (which sbt seems to achieve) and then go with something that is popular enough for the general JVM crowd because that's where this standardization is targeted at.

Gradle seems to be the favorite right now and @alkemist already "volunteered", so 👍 from me.

[alexandru]

@jrudolph yes, it's not a Scala initiative, that's why I would prefer Maven.

Though I just saw who @alkemist is, pretty cool he volunteered, so whatever, this is a minor bike-shedding issue on my part.

[viktorklang]

Also, repeating myself; very few will ever have to use the RS build (& tool) as both end-users and implementors will simply depend on the published artifacts.

[benjchristensen]

I just found another odd issue with SBT in Eclipse. It allows me to run the code after the previous fix, but it oddly doesn't correctly show compilation errors in the navigator. When I was refactoring things it was behaving very oddly so I had to revert away from using SBT again and just hand-build the Eclipse project.

[benjchristensen]

As @jrudolph says, this is not a Scala project, it is a pure Java project. Considering my continued issues with SBT and that it is not a normal solution for pure Java projects, I will appreciate the change to a pure Java build system.

As for Gradle ... with Google choosing it for Android that has pushed it significantly into the mainstream as Android is a major driver of Java these days.

[alexandru]

@benjchristensen Google also chose IntelliJ IDEA as the platform for Android Studio to go along with Gradle (Android Studio is actually based on the Android plugin developed and distributed by IntelliJ) and using Gradle implies Android Studio, speaking of which I recommend it - IntelliJ IDEA version 13, along with the oficial Scala plugin (also developed by IntelliJ), can import SBT projects directly and can auto-refresh them on changes, no need for SBT plugins specified as part of project/plugins.sbt. TestNG integration is provided out-of-the-box too.

If you take a look at the build file, you'll notice that it's effectively blank, only providing POM info for publishing, whereas the sub-projects definitions are only providing the compiler options. Surely Maven, the only option that's available out-of-the-box everywhere, can manage that.

[benjchristensen]

Yup, I know they chose IntelliJ. I have it and Eclipse ... but 10 years of experience with Eclipse keeps me there as every time I try and convert I waste more time than it's worth. I am not impeded by Eclipse thus I still use it.

A build system should not dictate the development environment whether it be Eclipse, IntelliJ, Vim, Emacs or a text editor.

SBT == Scala Build Tool ... this is a pure Java project ... and I still have problems with SBT even after the first bug was fixed.

As I've said though, this is a low priority issue as it's not a project I'll interact with much once we finish defining the interfaces.

[viktorklang]

Well, technically:

"sbt is an open source build tool for Scala and Java projects, similar to Java's Maven or Ant.
sbt is the abbreviation for "simple build tool"."

http://en.wikipedia.org/wiki/SBT_(software)

so I +1 myself (classy!) and @benjchristensen when he/we say:

"As I've said though, this is a low priority issue as it's not a project I'll interact with much once we finish defining the interfaces."

[rkuhn]

Sorry for being away so long (the talk about Reactive Streams was well received, by the way, especially the interoperability part): I’m fine with changing to a Gradle build—anything that works—so the only vote against would be from @alexandru (who indicated flexibility as well), with one “neutral” (down-priorization) from @viktorklang. Since I have never used that build tool, I cannot help out in the change, so I am very grateful for @alchemist to offer his assistance.

[jbrisbin]

@rkuhn it's actually @alkemist (with a "k" not a "ch")

[rkuhn]

aargh, sorry, I knew that something looked amiss!

[viktorklang]

Seems like sbt is working fine for now. Lets revisit this as we approach 1.0.

Proposing to move to closed for now, @reactive-streams/contributors wdyt?