Create Eclipse bundles by sbt

[Simon Schäfer]

One thing I extremely dislike about a maven-tycho build for an Eclipse
bundle is that half of the work is configured in Eclipse build files
(don't know how to call them (the MANIFEST.MF etc.)), which are then
read by tycho to make their information available to maven. Especially
the need to manually create plugin fragments, update sites is annoying
and clutters a repo.

Therefore the thought to configure everything in one build tool and
generate all the stuff Eclipse needs to function properly by the build.
Has anyone already experimented in this area and knows if this is in
general a goal to strive for?

At the moment it looks like there doesn't exist such a solution for sbt.
I found sbt-osgi (https://github.com/sbt/sbt-osgi), but its only
functionality is to generate packaged bundles, which is not yet enough
for plugin development where one needs the MANIFEST.MF etc. available to
allow Eclipse to build and run the code. I guess one could integrate a
separate build system in Eclipse, but I don't think its worth the
efforts. But I'm not sure about that because Scala IDE would benefit
from an extension that can understand sbt builds anyway. Maybe it isn't
much work anymore to make OSGi dependencies configured in sbt available
to Eclipse, once Eclipse can understand dependencies configured in sbt.

sbt-osgi uses bndtools (https://github.com/bndtools/bnd), which supports
a lot of functionality, but I haven't used it so far. It could be that
it already supports everything I need and the only thing that is missing
is a more complete sbt integration. Does someone know more about bndtools?

I also found sbt-osgi-manager
(https://github.com/digimead/sbt-osgi-manager), which seems to be a
solution to read Eclipse build files by sbt. This would only allow to
replace maven by sbt as a build tool for an Eclipse build, but the
Eclipse build would still be required.

scala-ide/sbt-integration (https://github.com/scala-ide/sbt-integration)
already supports some functionality, but is in general too much
outdated. While I managed to update it to Scala 2.11, some of its
dependencies can't be used anymore (especially sbt-remote-control has
been completely refactored and scala.rx should nowadays probably
replaced by reactive-streams), which means that the code doesn't compile
anymore with updated dependencies. Especially because Scala IDE somehow
needs to be refactored internally to support sbt-remote-control in
future it may be possible to implement a sbt driven OSGi bundle build
alongside.

[iulian dragos]

On Mon, Feb 9, 2015 at 1:14 PM, Simon Schäfer <ma...@antoras.de> wrote:

One thing I extremely dislike about a maven-tycho build for an Eclipse bundle is that half of the work is configured in Eclipse build files (don't know how to call them (the MANIFEST.MF etc.)), which are then read by tycho to make their information available to maven. Especially the need to manually create plugin fragments, update sites is annoying and clutters a repo.

Therefore the thought to configure everything in one build tool and generate all the stuff Eclipse needs to function properly by the build. Has anyone already experimented in this area and knows if this is in general a goal to strive for?

I agree that the state of tooling for Eclipse is pretty bad, at least when it comes to command line tooling. I looked into sbt a while ago and I didn't find anything good enough. Right now I think it's better to stick with Tycho:

- it is very actively maintained

- it is what Eclipse itself is migrating to, if not already using

- you can always do more. No matter how much time to allocate to "cleaning the build and infrastructure", you always use it fully, and could use more.

In my view our priorities should be centered around usability, and this is my list:

- better macro support in builder (essentially, compiling src/macros before src/main (if there is one), and run the incremental compiler in different runs for each source folder)

- better refactoring, especially Organize Imports and Rename.

- debugger improvements

  - usability (demangle names, de-mangle stack frames)

  - simpler stepping (the "step-into" closure feature seems a bit confusing nowadays)

  - include eval-expression PR in one form or another

  - exception breakpoints

- remove scala-actors and switch to akka-actors

- Sbt support

This is not an exhaustive list, of course, but I think that help with any of the above points (with the exception of removing actors) would have a huge impact on our users.

iulian

At the moment it looks like there doesn't exist such a solution for sbt. I found sbt-osgi (https://github.com/sbt/sbt-osgi), but its only functionality is to generate packaged bundles, which is not yet enough for plugin development where one needs the MANIFEST.MF etc. available to allow Eclipse to build and run the code. I guess one could integrate a separate build system in Eclipse, but I don't think its worth the efforts. But I'm not sure about that because Scala IDE would benefit from an extension that can understand sbt builds anyway. Maybe it isn't much work anymore to make OSGi dependencies configured in sbt available to Eclipse, once Eclipse can understand dependencies configured in sbt.

sbt-osgi uses bndtools (https://github.com/bndtools/bnd), which supports a lot of functionality, but I haven't used it so far. It could be that it already supports everything I need and the only thing that is missing is a more complete sbt integration. Does someone know more about bndtools?

I also found sbt-osgi-manager (https://github.com/digimead/sbt-osgi-manager), which seems to be a solution to read Eclipse build files by sbt. This would only allow to replace maven by sbt as a build tool for an Eclipse build, but the Eclipse build would still be required.

scala-ide/sbt-integration (https://github.com/scala-ide/sbt-integration) already supports some functionality, but is in general too much outdated. While I managed to update it to Scala 2.11, some of its dependencies can't be used anymore (especially sbt-remote-control has been completely refactored and scala.rx should nowadays probably replaced by reactive-streams), which means that the code doesn't compile anymore with updated dependencies. Especially because Scala IDE somehow needs to be refactored internally to support sbt-remote-control in future it may be possible to implement a sbt driven OSGi bundle build alongside.

--
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-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/54D8A4AC.2050508%40antoras.de.
For more options, visit https://groups.google.com/d/optout.

--

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

[Matthias Langer]

In my view our priorities should be centered around usability, and this is my list:

- better macro support in builder (essentially, compiling src/macros before src/main (if there is one), and run the incremental compiler in different runs for each source folder)

- better refactoring, especially Organize Imports and Rename.

- debugger improvements

  - usability (demangle names, de-mangle stack frames)

  - simpler stepping (the "step-into" closure feature seems a bit confusing nowadays)

  - include eval-expression PR in one form or another

  - exception breakpoints

- remove scala-actors and switch to akka-actors

- Sbt support

I definitely agree. In my opinion we don't need any new features. If all the features we have or appear to have would actually work flawlessly, Scala-IDE would be really great. I can easily work around the missing SBT integration because "sbt eclipse" works very well. On the other hand, doing the most basic refactorings like rename and move manually, because these features are completely broken, really sucks.

[Simon Schäfer]

Fixing the refactorings also sucks. It is complicated as hell due to restoring all the information the compiler removes from the trees. But hopefully new contributors arrive, which hope to learn new things by contributing...

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/91dc7d66-4de8-4fd1-9205-4405091b31be%40googlegroups.com.

[Simon Schäfer]

On Monday, February 9, 2015 at 6:02:40 PM UTC+1, Iulian Dragos wrote:

On Mon, Feb 9, 2015 at 1:14 PM, Simon Schäfer <ma...@antoras.de> wrote:

One thing I extremely dislike about a maven-tycho build for an Eclipse bundle is that half of the work is configured in Eclipse build files (don't know how to call them (the MANIFEST.MF etc.)), which are then read by tycho to make their information available to maven. Especially the need to manually create plugin fragments, update sites is annoying and clutters a repo.

Therefore the thought to configure everything in one build tool and generate all the stuff Eclipse needs to function properly by the build. Has anyone already experimented in this area and knows if this is in general a goal to strive for?

I agree that the state of tooling for Eclipse is pretty bad, at least when it comes to command line tooling. I looked into sbt a while ago and I didn't find anything good enough. Right now I think it's better to stick with Tycho:

- it is very actively maintained

- it is what Eclipse itself is migrating to, if not already using

- you can always do more. No matter how much time to allocate to "cleaning the build and infrastructure", you always use it fully, and could use more.

Yeah, I already guessed that the outcome may not be worth the efforts.

In my view our priorities should be centered around usability, and this is my list:

- better macro support in builder (essentially, compiling src/macros before src/main (if there is one), and run the incremental compiler in different runs for each source folder)

- better refactoring, especially Organize Imports and Rename.

- debugger improvements

  - usability (demangle names, de-mangle stack frames)

  - simpler stepping (the "step-into" closure feature seems a bit confusing nowadays)

  - include eval-expression PR in one form or another

  - exception breakpoints

- remove scala-actors and switch to akka-actors

- Sbt support

My idea was that I give the sbt integration another look, as discussed on https://gitter.im/sbt/sbt-remote-control today. Let's see if I can come up with something useful. And maybe it occurs that a tycho/bndtools integration in sbt is not so far away and therefore worth of deserving a look...

[Naftoli Gugenheim]

What about working type hierarchy, call hierarchy, and supported search?

--

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/91dc7d66-4de8-4fd1-9205-4405091b31be%40googlegroups.com.

[Simon Schäfer]

On 02/10/2015 01:13 AM, Naftoli Gugenheim wrote:

What about working type hierarchy, call hierarchy, and supported search?

Oh dear! Even more work ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CANpg8PC67XYa5YsH%2BrB9qmdo8YLDvxwkJQ%3Ddf%3DrcxDhiVv1CDw%40mail.gmail.com.

[Naftoli Gugenheim]

Yup :)

Honestly it's really disappointing, it sounds like you guys are between a rock and a hard place from _both_ sides - JDT and scalac. I always assumed that ultimately you'd for sure overtake and outpace IntelliJ, having scalac on your side.

Maybe you should go over to the paulp side ;)

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/54D953DC.3050707%40antoras.de.

[iulian dragos]

On Tue, Feb 10, 2015 at 1:13 AM, Naftoli Gugenheim <nafto...@gmail.com> wrote:

What about working type hierarchy, call hierarchy, and supported search?

Have you tried scala-search? Type hierarchy and Find References should work.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CANpg8PC67XYa5YsH%2BrB9qmdo8YLDvxwkJQ%3Ddf%3DrcxDhiVv1CDw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[iulian dragos]

On Tue, Feb 10, 2015 at 3:14 AM, Naftoli Gugenheim <nafto...@gmail.com> wrote:

Yup :)

Honestly it's really disappointing, it sounds like you guys are between a rock and a hard place from _both_ sides - JDT and scalac. I always assumed that ultimately you'd for sure overtake and outpace IntelliJ, having scalac on your side.

Maybe you should go over to the paulp side ;)

This is a general problem we have: people don't feel the need to contribute when something is missing. "There's Typesafe out there, they should fix Scala|Eclipse|Akka|Play|Sbt" (all of these are open-source and free, but we prefer to be consumers). The same goes for Eclipse (replace Typesafe by IBM or SAP or...)... Unfortunately, Typesafe can't fix everything, and even though we've pushed this as hard as we can, we simply can't compete with commercial companies who have tens of engineers working on tools. Don't get me wrong, this is nothing against you personally, but rather a general attitude in the industry.

We've been very lucky to have a few dedicated contributors like Simon, Matthias, Mirko, David... but there's too much to do and so little time! And yeah, it's too easy to give up.

So here's my pledge: if you're an Eclipse and Scala user, I'd be extremely happy to work with you to get started fixing your favorite bug or implementing a missing feature. Only by engaging the community, and having more people give back, we'll move this forward.

iulian

 

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CANpg8PC9sUQ-Z6D4LMuoF2NSnF_y214uytsMVA0p70ajW43e4w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Simon Schäfer]

On 02/09/2015 06:02 PM, iulian dragos wrote:
>
> I agree that the state of tooling for Eclipse is pretty bad, at least
> when it comes to command line tooling. I looked into sbt a while ago
> and I didn't find anything good enough. Right now I think it's better
> to stick with Tycho:
>
> - it is very actively maintained
> - it is what Eclipse itself is migrating to, if not already using
> - you can always do more. No matter how much time to allocate to
> "cleaning the build and infrastructure", you always use it fully, and
> could use more.

Yeah, I already guessed that the outcome may not be worth the efforts.

>

> In my view our priorities should be centered around usability, and
> this is my list:
>
> - better macro support in builder (essentially, compiling src/macros
> before src/main (if there is one), and run the incremental compiler in
> different runs for each source folder)
> - better refactoring, especially Organize Imports and Rename.
> - debugger improvements
> - usability (demangle names, de-mangle stack frames)
> - simpler stepping (the "step-into" closure feature seems a bit
> confusing nowadays)
> - include eval-expression PR in one form or another
> - exception breakpoints
> - remove scala-actors and switch to akka-actors
> - Sbt support

[Naftoli Gugenheim]

It was not a criticism, I was expressing sympathy. It sounded like the job is a lot bigger than it seemed at first.

And yes, I understand the frustration of insufficient community participation. If I implied somehow that anyone in the team was doing less than they should, it certainly was not intentional. I was only trying to throw out my 2 cents on what i would hope would make the list of priorities.

Regarding search, I was just referring to the fact that it's a separate plugin, which makes it sound like it's either unofficial or experimental.

--
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-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/54D9331B.7050804%40antoras.de.