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
<mailto: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
<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 <mailto: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
o Plug-in version number
o Netbeans certificaiton / release compatibility
o Project URL (and source when open source -- encourage
folk to upgrade old plug-ins)
o 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
o current plugins
o retro plug-ins
o 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
o 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.
___________________________________
