And the solution is to get hold of the owners of the plugins that do not work with 9.0 and ask them/work with them to make them compatible with 9.0.
Gj On Fri, Aug 3, 2018 at 9:57 AM, Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: > 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. >> >> >> ___________________________________ >> >> >> >> >
