I would recommend to fix the sources of the plugin so that this library isn't used there.
Gj On Fri, Aug 3, 2018 at 12:10 PM, Eduard <i...@dejongfrz.nl> wrote: > So it appears that in this case there exists a one-off reason for the > incompatibility. > > As a heavy user of QuickOpener I'd need a solution that makes it work. It > did so in the RC1. That suggests I could just use the or.opendesktop jar > from the RC1 and add it to Netbeans. 9.0. Is there anything else needed to > patch this licensing hick-up? > > Cheers > Eduard > > > > Geertjan Wielenga wrote: > > 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. >>> >>> >>> ___________________________________ >>> >>> >>> >>> >> > > >
