Update-Site: Separate Feature for Scala Library
The Scala-IDE update site (all versions) also provide a version of Scala Library with proper OSGi Manifest.
I developed an Eclipse Plugin that is written in Scala, so its makes sense, to reused the OSGi-ified Scala library of Scala IDE.
Unfortunatelly, this can only be installed, if one decides to install the "Scala IDE for Eclipse Feature", which obviously installs the complete Scala IDE. This is more than is needed, and users of my plugin might not want to install a complete Scala IDE just to get the Scala Library.
My Request:
Split up the current "Scala IDE for Eclispe Feature" into two parts, a "Scala" part, which could contain the library and possibly the compiler too, and an "IDE" part, containing the rest.
There was an discussion in the past, unfortunatelly, without an result: https://groups.google.com/d/topic/scala-ide-dev/0bdjtZVXR_k/discussion
I developed an Eclipse Plugin that is written in Scala, so its makes sense, to reused the OSGi-ified Scala library of Scala IDE.
Unfortunatelly, this can only be installed, if one decides to install the "Scala IDE for Eclipse Feature", which obviously installs the complete Scala IDE. This is more than is needed, and users of my plugin might not want to install a complete Scala IDE just to get the Scala Library.
My Request:
Split up the current "Scala IDE for Eclispe Feature" into two parts, a "Scala" part, which could contain the library and possibly the compiler too, and an "IDE" part, containing the rest.
There was an discussion in the past, unfortunatelly, without an result: https://groups.google.com/d/topic/scala-ide-dev/0bdjtZVXR_k/discussion
Leave a comment
on 2012-11-10 04:42 *
By Iulian Dragos
What is the exact use-case? I don't think you need an Eclipse feature for your plugin to work. Features are sets of bundles that are installed/uninstalled together, so it is not a good fit for the Scala library. The library is another bundle that your feature needs.
The Scala library is already available in a P2 repository, probably the simplest to use is http://download.scala-ide.org/releases-29/milestone/site. If you are using Maven/Tycho, simply add this repository to your pom file and it should be resolved. Same for your feature. The resulting update site should contain the library bundle along with your bundles.
The Scala library is already available in a P2 repository, probably the simplest to use is http://download.scala-ide.org/releases-29/milestone/site. If you are using Maven/Tycho, simply add this repository to your pom file and it should be resolved. Same for your feature. The resulting update site should contain the library bundle along with your bundles.
on 2012-11-11 11:38 *
By Tobias Roeser
(This my second atempt to comment, last one was lost after some captcha issues. Hope, you understand my point, as I'm a bit in a rush now.)
You are right, I do not necessarily need a feature for my plugin to work. But, in this case, I have either to depend on a preinstalled Scala runtime or I have to distribute it by myself. The later is the way I currently do and that you suggested.
My motivation behind my feature request is to decouple the lifecycle for my plugin and the one of the Scala runtime (library). When my plugin and possibly some other plugins too, depend on a Scala runtime, and all these plugins come with a redsitribution of it, the user installing those plugins end up with a lot of scala library bundles. Even, if storage space is not an concern here, maintenance is. If the Scala runtime would be distributed via a central update site, all other plugins that require a Scala runtime could simply require it. They could depend on the feature or the concrete bundle and provide the Scala runtime feature as discovery URL. Now, if an update of the Scala runtime is required, e.g. because of a bug fix, all bundles requiring the Scala runtime would benetif, even without the need to update those plugins.
This is, what OSGi is meant for, isn't it?
In fact, this is what I currently do for my plugin, which is the SBuild Eclipse Plugin (http://sbuild.tototec.de). I provide a Scala Library Feature and a SBuild Eclipse Plugin Feature. When I bump the SBuild version and the plugin version, I do not need to redistribute the Scala library. When a new compatible Scala release is out, I can bump my Scala Library feature and all previous releases of my bundle would work properly against this new version. I would love to see such a feature in some official place, though.
(I even have another plugin (Cmvn Eclipse Plugin, http://cmvn.tototec.de) which also depends on a Scala Runtime. Both would profit from a authentic Scala Runtime feature. I even believe, the decission to write a plugin in Scala could be made easier if an Scala Runtime update site would be advertised.)
You are right, I do not necessarily need a feature for my plugin to work. But, in this case, I have either to depend on a preinstalled Scala runtime or I have to distribute it by myself. The later is the way I currently do and that you suggested.
My motivation behind my feature request is to decouple the lifecycle for my plugin and the one of the Scala runtime (library). When my plugin and possibly some other plugins too, depend on a Scala runtime, and all these plugins come with a redsitribution of it, the user installing those plugins end up with a lot of scala library bundles. Even, if storage space is not an concern here, maintenance is. If the Scala runtime would be distributed via a central update site, all other plugins that require a Scala runtime could simply require it. They could depend on the feature or the concrete bundle and provide the Scala runtime feature as discovery URL. Now, if an update of the Scala runtime is required, e.g. because of a bug fix, all bundles requiring the Scala runtime would benetif, even without the need to update those plugins.
This is, what OSGi is meant for, isn't it?
In fact, this is what I currently do for my plugin, which is the SBuild Eclipse Plugin (http://sbuild.tototec.de). I provide a Scala Library Feature and a SBuild Eclipse Plugin Feature. When I bump the SBuild version and the plugin version, I do not need to redistribute the Scala library. When a new compatible Scala release is out, I can bump my Scala Library feature and all previous releases of my bundle would work properly against this new version. I would love to see such a feature in some official place, though.
(I even have another plugin (Cmvn Eclipse Plugin, http://cmvn.tototec.de) which also depends on a Scala Runtime. Both would profit from a authentic Scala Runtime feature. I even believe, the decission to write a plugin in Scala could be made easier if an Scala Runtime update site would be advertised.)
I understand your request better now, and I think it would be useful, but I fear this is not something we can be working on in the near future. However, if you are willing to contribute it, we'll definitely consider it.
on 2015-03-13 18:15 *
By Simon Schäfer
Version changed from 2.0.2-final-29 to 4.0.0
Milestone changed from Enhancements to -none-