-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved support for multiple scala versions #356
Improved support for multiple scala versions #356
Conversation
…pport-for-ScalaIDE-4.6 improved-support-for-multiple-scala-versions
…pport-for-multiple-scala-versions into src/main/scala-sbt-1.0/
#239 provided a initial support for multiple scala versions for Scala-IDE4.0, but is the implementation looked for scala-2.10 specifically. As a consequence the issue raised again when Scala-IDE4.6.0 came out targeting scala-2.12 as default. |
README.md
Outdated
|
||
Given | ||
``` | ||
EclipseKeys.defaultScalaInstallation := "xD.yD" // "2.12" is the default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what the D
represents here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
D stands for "default". 'xD.yD' represents the scala installation eclipse is using as default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the description. I hope it is more clear now.
val ideSettings = fromScalacToSDT(options) | ||
ScalaVersion.parse(version).settingsFrom(ideSettings.toMap).toSeq | ||
ScalaVersion.parse(installation, version).settingsFrom(ideSettings.toMap).toSeq |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be accurate to call these variables installationVersion
and projectVersion
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fine for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
update as you suggested has been pushed
installation -> installationVersion version -> projectVersion
Both #356 and #340 determine the version value for the properties The introduction of To be clear, import sbt._
import Keys._
import com.typesafe.sbteclipse.plugin.EclipsePlugin.EclipseKeys._
object SbtEclipseSettings extends Plugin {
override def settings = Seq(
defaultScalaInstallation := "2.11"
)
} This may look complex, but most people will not need it, and for those who need it, it is easier than being blocked or having to create a pull request on sbteclipse again. I don't know exactly what all implications are of the setting Up till now, I think approach B had the smallest impact on the sbteclipse code based and it's behaviour, and it is better than before #356, as well as approach A. It will help people out using scala 2.11 on a recent Scala IDE's, and don't break functionality for others. A better solution may be possible in the future. It would be nice if the engineers of the eclipse Scala IDE would join this discussion. |
@wpopielarski @sschaef do you think that sbteclipse is taking the correct approach to generating eclipse files for use by scala IDE here? |
Defining a project in The question is whether generating the latter directly in a (eclipse) Scala IDE format is the best approach. To decouple the dependencies on the IDE, maybe you could agree on an a generic resolved project definition format (something straight and simple, all you need in a single file: property-file or json formatted). The Scala IDE should than support importing the latter. During the import, warnings of incompatibility could be generated. This approach would also require an update-import feature in eclipse. So far, I've no experience with https://github.com/scala-ide/sbt-integration. At first glance, it looks more complex to setup. |
Thinking about this more, I believe that setting |
I agree with
That's exactly what the code does, in case the defaultScalaInstallation > projectScalaVersion
The fact that also |
Can we do it always so that this plugin does not to have to know about |
Yes, but it has consequences. So yes, we can apply these settings in all cases, which means we apply also If some people would need macro-expand support in eclipse, sbt-eclipse could define a setting key |
We may only need to do that when setting
I'm not sure though when they say "This probably will remain a long-term limitation of this mode." whether that means we need to do it for newer versions as well. Maybe you're right that it always needs to be done |
Maybe a better option would be to have a boolean flag like |
I keep the sbt-eclipse plugin and its settings as global settings on my machine only, as other developers may not use it. I do share the concern that having to maintain a version number in the build config with Based on your view I summarize the solution as:
|
Yes, sounds good to me Sorry for the back-and-forth on this one and my taking so long. I no longer use sbt as we have migrated to Play on Gradle, so I've had a hard time finding time to devote to this |
improved-support-for-multiple-scala-versions
for ScalaIDE-4.6 and up
to support also scala-2.11 while preserving functionality for older versions,
i.e. support for scala-2.10 in ScalaIDE-4.0 and up.
This is a patch on top of commit 1bbf64c (Fix #239)
added EclipseKeys.defaultScalaInstallation
usage documentation added in README.md