Next release of the Scala IDE

[iulian dragos]

Hi all,

I'd like to share our plans for the next Scala IDE release. It's no secret that since the 3.0 release in March we focused less on the core IDE and more on building plugins on top of it. That's how the Play IDE plugin came about, and Scala Search too (ScalaTest was already there, and is the most downloaded Scala IDE plugin!).

As time passed, we realized that core needs to expose a real API. We built functionality, fixed bugs, but didn't really plan for an ecosystem of plugins. In the long run, this is an essential piece: it allows plugin writers to provide additional functionality without tying it to a specific version. Moreover, it allows users to upgrade their core plugin without waiting for all plugins to publish an upgrade. It lowers the cost of maintenance, and it's simply decoupling the core from other plugins.

There is no point in pretending: we can't keep source compatibility between 3.0 and 4.0. We will reorganize packages and use `internal` to mark non-API classes (but we'll continue to expose them in MANIFEST files, just like Eclipse does). Since this is anyway going to break clients, we'll also go for `org.scalaide` as the root package. Adding anything in the `scala` package is discouraged, and this is the only chance we have to really clean up everything.

There will be pain for plugin maintainers, but we believe the cost is worth the stability it brings. We're eager to hear your feedback, especially since the ultimate goal of this is to simplify *your* life. Please let us know about things we keep "internal" but you absolutely need. We'll make a best effort to support all existing plugins in this API. Additionally, we'll use semantic versioning, roughly: 

 - micro upgrades are backwards compatible, no new APIs

 - minor upgrades are backwards compatible, introduce new APIs

 - major upgrades may remove or change signatures of API classes and methods

Timewise, we plan to release milestone 1 really soon (this week). No API changes are planned yet (except for the move to Scala-provided OSGi bundles, described here). Milestone 2 will have a first stab at the API, and we hope to get most of the breaking changes done by then (roughly 1 month from now, but it's hard to estimate). Afterwards we plan to go towards a release with a short bug-fixing period followed by RC1.

Obviously, this release won't have a lot of new features. So how can you help? If you're a plugin writer, we absolutely need your feedback. Please try to release a version for M2, and let us know if you're missing anything. If you're a contributor, you can help make this release more awesome! A few areas where we can definitely use some help are:

- your most useful missing feature or your most annoying bug

- usability:

  - cleaning up Scala wizards

  - cleaning up preference pages

  - improving the UI of hovers and other UI elements

  - intro pages/cheat sheets (a first stab is here).

- debugger:

  - run to line, clean up stack trace names, detail formatters, etc.

- worksheet: lots of little improvements possible, from shortcuts to better UI in completions

To summarize, we will continue to work with the community and help integrate any pull-request you throw at us! We've seen a couple of great ones from Daniel Chia and Nicolas Scarcella recently, along with long-time contributors like Simon Schaeffer, so we're confident the 4.0 release will be a successful one!

Thanks for reading, and thanks for helping!

[MVAckel]

Hello,

I'd like to congratulate all IDE team for the good work being done.

I's also like to ask you to seriously consider improving the Scala IDE debugger that's in my opinion it's weakest point. I understand that Scala is still much used for academic purposes and by academic people that usually write small spinets of code but for enterprise real usage it's necessary and fundamental to have a good debugger (and, of course, a good IDE). Most enterprises will _not_ immediately enter test driven development or use the continually increasing features of the language or use functional programming - they will use OO programming in the most trivial way. New features will be incorporated in the code with time and that's why Scala/ScalaIDE is so important, because it has all the modern constructs for the long run.

That's my wish list for the Scala IDE debugger:
- Interactive code testing at any debugging line (to be able to write an expression or a line of code using all the context at any debugging point - like the Matlab debugger) - maybe using the Scala Console (that seems not recognize the context variables) or the Scala Worksheet.
- variables values at the tooltip (maybe configurable: type or value)
- easier configuration of what to debug (usually in 95%+ we debug only our own code - not the library code)
- fewer bugs using the debugger (breakpoint hit counter, expression tab, ...)

Thank you!!

On Wednesday, October 30, 2013 10:18:56 AM UTC-2, Iulian Dragoș wrote:

Hi all,

I'd like to share our plans for the next Scala IDE release. It's no secret that since the 3.0 release in March we focused less on the core IDE and more on building plugins on top of it. That's how the Play IDE plugin came about, and Scala Search too (ScalaTest was already there, and is the most downloaded Scala IDE plugin!).

...

[Seyed H. HAERI (Hossein)]

Good point Marcos. In fact, I use Scala for academic purposes only. Yet, I very recently faced a funny (Scala) bug that got me very unhappy about the absence of a debugger: An implicit was called at a nonsense point where my code would crash for it wasn't designed for that call. I would have got to know about this misbehaviour much faster if I control the execution in its classic step-by-step debug fashion. In the absence of that, I had to manually profile things until I trap the culprit... So, all in all, I too think that's a remarkable missing factor that I would like to urge the nice IDE people to take into consideration as soon as they can. Thanks! :)

--
You received this message because you are subscribed to the Google Groups "Scala IDE User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
--------------------------------------------------------------------------------------------------------------

Seyed H. HAERI (Hossein)

Research Assistant
Institute for Software Systems (STS)
Technical University of Hamburg (TUHH)
Hamburg, Germany

ACCU - Professionalism in programming - http://www.accu.org/
--------------------------------------------------------------------------------------------------------------

[iulian dragos]

I intended to have two links in the text, but unfortunately I lost them when switching between editors. See inline:

On Wed, Oct 30, 2013 at 1:18 PM, iulian dragos <iulian...@typesafe.com> wrote:

Hi all,

I'd like to share our plans for the next Scala IDE release. It's no secret that since the 3.0 release in March we focused less on the core IDE and more on building plugins on top of it. That's how the Play IDE plugin came about, and Scala Search too (ScalaTest was already there, and is the most downloaded Scala IDE plugin!).

As time passed, we realized that core needs to expose a real API. We built functionality, fixed bugs, but didn't really plan for an ecosystem of plugins. In the long run, this is an essential piece: it allows plugin writers to provide additional functionality without tying it to a specific version. Moreover, it allows users to upgrade their core plugin without waiting for all plugins to publish an upgrade. It lowers the cost of maintenance, and it's simply decoupling the core from other plugins.

There is no point in pretending: we can't keep source compatibility between 3.0 and 4.0. We will reorganize packages and use `internal` to mark non-API classes (but we'll continue to expose them in MANIFEST files, just like Eclipse does). Since this is anyway going to break clients, we'll also go for `org.scalaide` as the root package. Adding anything in the `scala` package is discouraged, and this is the only chance we have to really clean up everything.

There will be pain for plugin maintainers, but we believe the cost is worth the stability it brings. We're eager to hear your feedback, especially since the ultimate goal of this is to simplify *your* life. Please let us know about things we keep "internal" but you absolutely need. We'll make a best effort to support all existing plugins in this API. Additionally, we'll use semantic versioning, roughly: 

 - micro upgrades are backwards compatible, no new APIs

 - minor upgrades are backwards compatible, introduce new APIs

 - major upgrades may remove or change signatures of API classes and methods

Timewise, we plan to release milestone 1 really soon (this week). No API changes are planned yet (except for the move to Scala-provided OSGi bundles, described here)

https://groups.google.com/d/msg/scala-ide-dev/MtoG-AwciQI/vPZD5HrIBNIJ

 

. Milestone 2 will have a first stab at the API, and we hope to get most of the breaking changes done by then (roughly 1 month from now, but it's hard to estimate). Afterwards we plan to go towards a release with a short bug-fixing period followed by RC1.

Obviously, this release won't have a lot of new features. So how can you help? If you're a plugin writer, we absolutely need your feedback. Please try to release a version for M2, and let us know if you're missing anything. If you're a contributor, you can help make this release more awesome! A few areas where we can definitely use some help are:

- your most useful missing feature or your most annoying bug

- usability:

  - cleaning up Scala wizards

  - cleaning up preference pages

  - improving the UI of hovers and other UI elements

  - intro pages/cheat sheets (a first stab is here).

https://github.com/dragos/scala-ide/tree/improvement/cheat-sheets 

[Luc Bourlier]

Hossein, there is a Scala debugger, you can find general information about it in the documentation [1]. What was Marco pointing out is the limitation of our implementation compared to the Java debugger.

Luc

P.S.: About Scala being still only academic, it is not Java-level mainstream yet, but here's an (incomplete) list of production user of Scala: http://www.quora.com/Startups/What-startups-or-tech-companies-are-using-Scala

[1] - http://scala-ide.org/docs/current-user-doc/features/scaladebugger/index.html

[Brian Smith]

Hi folks

Thanks for all the effort, it's really appreciated.  

The day to day user experience in scala-ide has come on leaps and bounds since Typesafe began investing in it - in the last year in particular.

As a user my wishlist would revolve around alleviating some of the pain with sbt.

1) Integration with SBT a la M2E/Maven.  It would be great not to have to trash my eclipse project files, make a bunch of project mods manually and then repeat again remembering this time to include with-source=true every time I add a library to my SBT build.  Since the scala-ide embeds sbt anyway, couldn't it use that to pull the library dependencies for different scopes and create classpath containers with them in?  IvyDE might even do most of the lifting.

2) Scala editor support for .scala and .sbt files that sbt sees without having to add them to source folders. 

3) Wizards for creating sbt builds and scala projects from them.  Maybe these could work with the same templates as activator but without adding all the activator boilerplate into the builds?  It would also open up a way for people to contribute recipes without understanding the code base.

4) SBT refactors for creating submodules and moving things between modules - this might help Play in particular where moving code to submodules is a key defence against compile times.

I think this kind of thing might really help enterprises adopt Scala - one of the last remaining fears I often encounter is the steep curve of SBT.

Hope this feedback is useful,

Brian

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.

[Mirco Dotta]

Hi Brian,

Feedback is very much appreciated. In fact, https://github.com/scala-ide/sbt-integration ;-) (work on it will start soon, stay tuned).

-- Mirco

[Seyed H. HAERI (Hossein)]

Hi Luc,

> Hossein, there is a Scala debugger, you can find general information about it in the documentation [1].

OK, I seem to have miscommunicated myself here, for which I apologise.
I did already know about the availability of that in the nightlies.
Yet, for stability purposes, I tend to only use the stable versions.
In other words, I look forward seeing a good debugger in the stables.

> What was Marco pointing out is the limitation of our implementation compared to the Java debugger.

I see.

Cheers,
--Hossein

[Brian Smith]

Hi Hossein

The debugger has been in a stable release since March 2013 when 3.0.0 became final.

It's available now.

Brian

[Brian Smith]

Hi Mirco

That's great - I've never managed to get my head around the eclipse api enough to help with dev but if you need someone to test it I'll be happy to try it out.

Thanks!

Brian

[iulian dragos]

Hi Brian,

Thanks for the feedback, and also for the good words. We usually get bug reports :)

As Mirco pointed out, we'll be working on better Sbt integration as a separate plugin. We feel that is very important in the long run, especially for Play applications. Part of this cleanup and API work is to better support plugins for Play and Sbt.

cheers,

iulian

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Daniel Chia]

Micro, +1 on sbt-integration. I know the people at work would be very pleased when that gets working - we have many play projects and it's getting to be quite a pain to keep the eclipse project in sync.

Let me know how I can help out.