Tweaks to project/plugin files. #140

wants to merge 2 commits into from

2 participants

Lightbend Inc. member
  • set sbt version explicitly
  • add sbteclipse configuration
gkossakowski added some commits Dec 6, 2012
@gkossakowski gkossakowski Set sbt version used for building explicitly.
Added `project/` that sets sbt version used
for building the plugin explicitly to 0.12.1 (latest stable release).

Without this change sbteclipse plugin wouldn't even build on machine
because sbt launcher would default to 0.11.3 version that does not
work because of missing plugins used by sbteclipse project.
@gkossakowski gkossakowski Eating your own dog food. Add sbteclipse to sbteclipse.
Added plugin configuration for sbteclipse plugin (2.1.0 version).
@hseeberger hseeberger commented on the diff Dec 13, 2012
@@ -4,3 +4,5 @@ libraryDependencies <+= (sbtVersion)("org.scala-sbt" % "scripted-plugin" % _)
addSbtPlugin("com.github.gseitz" % "sbt-release" % "0.5")
addSbtPlugin("com.typesafe.sbtscalariform" % "sbtscalariform" % "0.5.1")
+addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.1.0")

@gkossakowski, this is discouraged: IDE specific plugins should never be added to a project's plugins definition, but to the users global plugins definition.

Lightbend Inc. member

@hseeberger: Where project-specific configuration of IDE plugin should go then?

@gkossakowski: For most projects that should not be necessary. If it is necessary for some reason, then create eclipse.sbt in plugins/ and . Others can decide to exclude these files then.

Lightbend Inc. member

I see. Just for the record, here's an example of a situation when it's necessary (at least short-term):

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Greg, I have to agree with heiko on including sbteclispe in itself. This causes no end of pain when upgrading to a non-BC version of SBT (right now). In the future, I'm all for it, but we need a better Plugin story in the future (i.e. building plugins against different sbt versions than the current).

I think the change is worth pursuing if you also upgrade to use the cross-plugin-releasing plugin, otherwise it just puts a strain on regular plugin maintenance for a rather esoteric case.

As far as explicitly specifying sbt.version in, I'm all for it.


Oh, just a note: I'm going to close this in one week, unless we come to further action or deciion on a path forward. Trying to clear out the backlog on sbteclipse

Lightbend Inc. member

@jsuereth: I think it's a deficiency of sbt that its plugins cannot fail gracefully and thus could be included in project configuration. This is area where sbt is significantly weaker than, for example, Maven.

I'm ok with closing this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment