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.
--
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.
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
--
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.
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
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.
What about working type hierarchy, call hierarchy, and supported search?
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CANpg8PC67XYa5YsH%2BrB9qmdo8YLDvxwkJQ%3Ddf%3DrcxDhiVv1CDw%40mail.gmail.com.
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.
What about working type hierarchy, call hierarchy, and supported search?
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-dev/CANpg8PC67XYa5YsH%2BrB9qmdo8YLDvxwkJQ%3Ddf%3DrcxDhiVv1CDw%40mail.gmail.com.
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/CANpg8PC9sUQ-Z6D4LMuoF2NSnF_y214uytsMVA0p70ajW43e4w%40mail.gmail.com.
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.