The problems are a bit more complex than how you describe them, in the case of Apache NetBeans.
Take for example 'org.jdesktop.beansbinding'. This is a library that has been part of NetBeans for many years. And it's been used by a variety of plugins as well, such as some of those you seem to be trying to install. However, the licensing of that library is GPL. The Apache Software Foundation does not allow Apache projects to distribute GPL-based libraries. So, we had to remove it from Apache NetBeans. And now some of the plugins that rely on that library will not work. There are other similar cases, though not too many. Another example is Hibernate (http://hibernate.org/community/license), which had to be removed in order for Apache NetBeans to be acceptable to the Apache Software Foundation. Hope this gives some insights, Gj On Fri, Aug 3, 2018 at 9:49 AM, * William <william.full.m...@gmail.com> wrote: > Hello all... > > I have an interesting general for platforms supporting: extras, macros, > add-ons, plug-ins, extensions, themes, what have you. For this post, I'll > jsut use "plug-in" as a *generic* term meaning all things you can > add/theme, etc. > > > *use-case:* > > I've faced the same situation on many platforms, across many > release-cycles, and over many years. Some identifable examples include > Netbeans, Firefox (since v5), Chrome, Eclipse, even application tools > Excel, Word and OpenOffice/LibreOffice, etc. > > Almost with out exception, when new releases comes-out I as an end-user > loose functionality when the "plug-in" version no longer matches or if the > model changes. Last year Firefox changed the whole plug-in interface and I > lost every day productivity because things aI had a habit of using were no > longer "present" or compatible. > > I am sure you are familiar with the feeling when your favoured tool or > add-on is no longer there? An example to talk to is this: the Netbeans RC > and Beta both happily supported the plugin QuickOpener during my various > opportunities to trial these two pre-release candidates. > > Alas, Netbeans release 9 does not. I'm sure there are reasons. I'm > taling to two points. > > 1. Capability -- Evidently Netbeans as RC1 can support QuickOpener (it > is feasible and practical) > 2. Usability -- Those features that I may use 4 or 24 times a day are > now gone. > > I believe there are ways to be nicer to end-uers when migrating / > upgrading versions. > > *suggestion*: > > Here's an approach to improve the User Experiece. > > Support backward compatibility for just one version back. In this case > Netbeans 9 might have supported existing Netbeans 8 plug-ins. Not all of > them but from my using of Netbeans pre-releases I had no problem with most > of them. > > *process*: > > In order to Not be a burden progressing between versions there need to be > some simple rules/steps. > > - Make the previous version compatiblity layer a configurable option > in the config file (or start-up option). > - No support is promised for unqualified / out of certification, older > plugins, but if it works why not let it run. > - When a compatible version comes along the normal update stream > should upgrade the plugin. > - On the Netbeans Tools / Options panel, all plug-ins should report a > few things in an about box or sub-panel > - Plug-in version number > - Netbeans certificaiton / release compatibility > - Project URL (and source when open source -- encourage folk to > upgrade old plug-ins) > - URL-s to report bugs, documentation > - The infrastructure to activate/deactivate plug-ins already exists > - Highlight any Retro Plug-in in the plug-ins in a different colour > (brown??) > - In the plug-in sources settings provide two plug-in repository > channels > - current plugins > - retro plug-ins > - Perhaps even provide a check-box or a tab on the plugin choosing > panel to select between the two sets of plug-ins. > - Get plugin to provide a button for displaying or saving settings to > a human readable format > - that way settings that are not saved in Export can be kept > > *summary:* > > I happily installed Netbeans 9 and import-ed by settings from netbeans > v8.2. All was good ...So far as it goes on the technical side. However all > these platforms that use plugins share the same issue when it comes to > breaking changes -- And the end-user always loses the toss of the coin. > The main tools I would need to use Netbeans day to day are not ready yet. > > At least that means without some level of a retro plugin layer, adoption > is retarded and the user base is limited. > > In a nut shell, I think that for the sake of continuity of service and > maintaing a great User Experience the software industry (meaning > individuals and projects... ) need to really factor in support for > > - "User Experience Service Continuity". > > The label is awkward, I know. Thing is the settings I imported can not all > work because the plugin that might know about them doesn't 'exist' for > Netbeans 9 or Firefox 54 or Excel 2010. People often say how they want to > support the users, but these workflow breaking changes remind me of the > 1980-s user design. > > I would keep silent if not for the lucky evidence from the Beta and RC1 > experince where plugins I can't use today worked happily on Netbeans RC1. > > That's all. What about it? Wouldn't you like to have compatible tools > from the previous version until they are upgraded? > > Best wishes, > > aplatypus > > -- -- -- > Some plugins require plugin org.jdesktop.beansbinding to be installed. The > plugin org.jdesktop.beansbinding is requested in version 1.13.1.121. > > The following plugin is affected: > QuickOpener > Some plugins require plugin Common Test Runner API to be installed. The > plugin Common Test Runner API is requested in version >= 1.31.1 (release > version 1) but only 2.11.1 (of release version different from 1) was found. > > The following plugin is affected: > Gradle Support > Some plugins require capability cnb.org.netbeans.modules.groovy.kit No > plugin providing the capability cnb.org.netbeans.modules.groovy.kit could > be found. > > The following plugin is affected: > Gradle Support > > Some plugins not installed to avoid potential installation problems. > > > ___________________________________ > > > >
