You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@netbeans.apache.org by * William <wi...@gmail.com> on 2018/08/03 07:49:25 UTC
Plug-in support and compatibility suggestion
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.
___________________________________
Re: Plug-in support and compatibility suggestion
Posted by Will Hartung <wi...@gmail.com>.
I mis-replied this before, so resending it.
On Tue, Aug 7, 2018 at 9:04 AM, Emilian Bold <emilian.bold@protonmail.ch.
invalid> wrote:
> Beansbinding can be brought back easily. We have the existing code
> service-based, we only have to put the GPL w/ CPE plugin somewhere online
> and suggest it to users, just like we suggest nb-javac.
>
Well, that's an interesting point.
Now, I don't know, but I don't think there can be an "official" Apache
point for distribution of GPL and other non-APL code, right?
But there could be some semi-official "Friends of Netbeans" place that
would be "friendly" to things like that and would be a sane default for
Netbeans to go and fetch things from.
Re: Plug-in support and compatibility suggestion
Posted by Emilian Bold <em...@protonmail.ch.INVALID>.
Beansbinding can be brought back easily. We have the existing code service-based, we only have to put the GPL w/ CPE plugin somewhere online and suggest it to users, just like we suggest nb-javac.
--emi
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 7 August 2018 6:56 PM, Oliver Rettig <Ol...@orat.de> wrote:
> Hi,
>
>
>
> Can we establish a page in the wiki with the problematic libraries:
>
>
>
> org.jdesktop.beansbinding
>
> org.jdesktop.swingx
>
> javahelp
>
>
>
> Are there others?
>
>
>
> What is to do? How can the functionality in the first two be substituted?
>
>
>
> What can we do to substitute javahelp.
>
>
>
> best regards
>
> Oliver
>
> > The owner is Oracle. And the JSR for BeansBinding is dead.
>
> >
>
> > And that is not my point — my point is that any plugin using that JAR needs
>
> > to be rewritten to not use it.
>
> >
>
> > Gj
>
> >
>
> >
>
> > On Friday, August 3, 2018, Boris Heithecker <bo...@gmx.net>
>
> >
>
> > wrote:
>
> > > Hi,
>
> > > does anybody know who's the owner of org.jdesktop.beansbinding? Whom
>
> > > should I contact? Is the license really GPL, or LGPL? Same question
>
> > > applies to org.jdesktop.swingx: GPL oder LGPL? Who's the owner?
>
> > > Havn't found any robust information about these libraries so far.
>
> > > Am I allowed to ship them with my platform application?
>
> > > Boris
>
> > >
>
> > > 2018-08-03 9:59 GMT+02:00 Geertjan Wielenga
>
> > >
>
> > > <ge...@googlemail.com.invalid>:
>
> > > > 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
>
> > > >
>
> > > > <ge...@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 <wi...@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.
>
> > > >>>
>
> > > >>> Capability -- Evidently Netbeans as RC1 can support QuickOpener (it is
>
> > > >>> feasible and practical)
>
> > > >>> 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.
>
> > > >>>
>
> > > >>> ___________________________________
>
> > >
>
> > > --
>
> > > Boris Heithecker
>
> > >
>
> > >
>
> > > Dr. Boris Heithecker
>
> > > Lüneburger Str. 30
>
> > > 28870 Ottersberg
>
> > > Tel.: 0 42 05/ 31 58 34
>
> > >
>
> > > ---------------------------------------------------------------------
>
> > > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>
> > > For additional commands, e-mail: users-help@netbeans.apache.org
>
> > >
>
> > > For further information about the NetBeans mailing lists, visit:
>
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Plug-in support and compatibility suggestion
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
Yup, makes sense and is sorely needed, would be great to have a page where
these can be documented and referenced.
Another one is Hibernate.
We'd refer to the PRs that are relevant, the mailing list threads that
relate, etc.
Gj
On Tue, Aug 7, 2018 at 5:56 PM, Oliver Rettig <Ol...@orat.de> wrote:
> Hi,
>
>
>
> Can we establish a page in the wiki with the problematic libraries:
>
>
>
> org.jdesktop.beansbinding
>
> org.jdesktop.swingx
>
> javahelp
>
>
>
> Are there others?
>
>
>
> What is to do? How can the functionality in the first two be substituted?
>
>
>
> What can we do to substitute javahelp.
>
>
>
> best regards
>
> Oliver
>
> > The owner is Oracle. And the JSR for BeansBinding is dead.
>
> >
>
> > And that is not my point — my point is that any plugin using that JAR
> needs
>
> > to be rewritten to not use it.
>
> >
>
> > Gj
>
> >
>
> >
>
> > On Friday, August 3, 2018, Boris Heithecker <bo...@gmx.net>
>
> >
>
> > wrote:
>
> > > Hi,
>
> > > does anybody know who's the owner of org.jdesktop.beansbinding? Whom
>
> > > should I contact? Is the license really GPL, or LGPL? Same question
>
> > > applies to org.jdesktop.swingx: GPL oder LGPL? Who's the owner?
>
> > > Havn't found any robust information about these libraries so far.
>
> > > Am I allowed to ship them with my platform application?
>
> > > Boris
>
> > >
>
> > > 2018-08-03 9:59 GMT+02:00 Geertjan Wielenga
>
> > >
>
> > > <ge...@googlemail.com.invalid>:
>
> > > > 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
>
> > > >
>
> > > > <ge...@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.moon@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.
>
> > > >>>
>
> > > >>> Capability -- Evidently Netbeans as RC1 can support QuickOpener
> (it is
>
> > > >>> feasible and practical)
>
> > > >>> 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.
>
> > > >>>
>
> > > >>> ___________________________________
>
> > >
>
> > > --
>
> > > Boris Heithecker
>
> > >
>
> > >
>
> > > Dr. Boris Heithecker
>
> > > Lüneburger Str. 30
> <https://maps.google.com/?q=L%C3%BCneburger+Str.+30+%0D%0A+28870+Ottersberg&entry=gmail&source=g>
>
> > > 28870 Ottersberg
> <https://maps.google.com/?q=L%C3%BCneburger+Str.+30+%0D%0A+28870+Ottersberg&entry=gmail&source=g>
>
> > > Tel.: 0 42 05/ 31 58 34
>
> > >
>
> > > ---------------------------------------------------------------------
>
> > > To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
>
> > > For additional commands, e-mail: users-help@netbeans.apache.org
>
> > >
>
> > > For further information about the NetBeans mailing lists, visit:
>
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
Re: Plug-in support and compatibility suggestion
Posted by Oliver Rettig <Ol...@orat.de>.
Hi,
Can we establish a page in the wiki with the problematic libraries:
org.jdesktop.beansbinding
org.jdesktop.swingx
javahelp
Are there others?
What is to do? How can the functionality in the first two be substituted?
What can we do to substitute javahelp.
best regards
Oliver
> The owner is Oracle. And the JSR for BeansBinding is dead.
>
> And that is not my point — my point is that any plugin using that JAR needs
> to be rewritten to not use it.
>
> Gj
>
>
> On Friday, August 3, 2018, Boris Heithecker <bo...@gmx.net>
>
> wrote:
> > Hi,
> > does anybody know who's the owner of org.jdesktop.beansbinding? Whom
> > should I contact? Is the license really GPL, or LGPL? Same question
> > applies to org.jdesktop.swingx: GPL oder LGPL? Who's the owner?
> > Havn't found any robust information about these libraries so far.
> > Am I allowed to ship them with my platform application?
> > Boris
> >
> > 2018-08-03 9:59 GMT+02:00 Geertjan Wielenga
> >
> > <ge...@googlemail.com.invalid>:
> > > 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
> > >
> > > <ge...@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
> >
Re: Plug-in support and compatibility suggestion
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
The owner is Oracle. And the JSR for BeansBinding is dead.
And that is not my point — my point is that any plugin using that JAR needs
to be rewritten to not use it.
Gj
On Friday, August 3, 2018, Boris Heithecker <bo...@gmx.net>
wrote:
> Hi,
> does anybody know who's the owner of org.jdesktop.beansbinding? Whom
> should I contact? Is the license really GPL, or LGPL? Same question
> applies to org.jdesktop.swingx: GPL oder LGPL? Who's the owner?
> Havn't found any robust information about these libraries so far.
> Am I allowed to ship them with my platform application?
> Boris
>
> 2018-08-03 9:59 GMT+02:00 Geertjan Wielenga
> <ge...@googlemail.com.invalid>:
> > 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
> > <ge...@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 <wi...@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.
> >>>
> >>> Capability -- Evidently Netbeans as RC1 can support QuickOpener (it is
> >>> feasible and practical)
> >>> 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.
> >>>
> >>>
> >>> ___________________________________
> >>>
> >>>
> >>>
> >>
> >
>
>
>
> --
> Boris Heithecker
>
>
> Dr. Boris Heithecker
> Lüneburger Str. 30
> 28870 Ottersberg
> Tel.: 0 42 05/ 31 58 34
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: users-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
Re: Plug-in support and compatibility suggestion
Posted by Boris Heithecker <bo...@gmx.net>.
Hi,
does anybody know who's the owner of org.jdesktop.beansbinding? Whom
should I contact? Is the license really GPL, or LGPL? Same question
applies to org.jdesktop.swingx: GPL oder LGPL? Who's the owner?
Havn't found any robust information about these libraries so far.
Am I allowed to ship them with my platform application?
Boris
2018-08-03 9:59 GMT+02:00 Geertjan Wielenga
<ge...@googlemail.com.invalid>:
> 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
> <ge...@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 <wi...@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.
>>>
>>> Capability -- Evidently Netbeans as RC1 can support QuickOpener (it is
>>> feasible and practical)
>>> 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.
>>>
>>>
>>> ___________________________________
>>>
>>>
>>>
>>
>
--
Boris Heithecker
Dr. Boris Heithecker
Lüneburger Str. 30
28870 Ottersberg
Tel.: 0 42 05/ 31 58 34
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@netbeans.apache.org
For additional commands, e-mail: users-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Plug-in support and compatibility suggestion
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <in...@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.wielenga@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 <wi...@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.
>>>
>>>
>>> ___________________________________
>>>
>>>
>>>
>>>
>>
>
>
>
Re: Plug-in support and compatibility suggestion
Posted by Eduard <in...@dejongfrz.nl>.
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.wielenga@googlemail.com
> <ma...@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.moon@gmail.com <ma...@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.
>
>
> ___________________________________
>
>
>
>
>
Re: Plug-in support and compatibility suggestion
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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.wielenga@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 <wi...@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.
>>
>>
>> ___________________________________
>>
>>
>>
>>
>
Re: Plug-in support and compatibility suggestion
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
I see two QuickOpener plugins:
http://plugins.netbeans.org/plugin/43217/quickopener
http://plugins.netbeans.org/plugin/62668/quickopener
Which of these, or another one, is being referred to in this thread? To fix
the problem described in the thread, send a PR to the GitHub repo of the
plugin you're using and remove BeansBinding JAR from it.
Happy to do it myself, just tell me which plugin you're referring to in
this thread.
Gj
On Tue, Aug 7, 2018 at 9:40 AM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> Not sure I understand fully, but isn't what you describe already the case?
> Backward compatibility is one of the key aspects of NetBeans going many
> years back now.
>
> Gj
>
> On Tue, Aug 7, 2018 at 8:58 AM, * William <wi...@gmail.com>
> wrote:
>
>>
>> Thank you Geertjan,
>>
>> I understand the licienseing point -- Yes in that specific case, yes the
>> plugin needs to be compatible.
>>
>> I am unconcerned about specific missing plugins. I had hoped my point
>> was clear enough as this is something that applies to a Great Many products
>> that use "plug-in" and "add-on" mechanisms.
>>
>> I feel that products in general should provide 'useability' support for
>> compliant and compatible plug-ins that work from the previous version.
>>
>> In the case of Netbeans as on specific example, v9.0 *would* permit
>> support for v8.2 plugins.
>>
>> And only the ones that work/are compatible and compliant with the
>> licensing and infrastructiure/platform changes.
>>
>> I really think that would be a big plus for any platform/product.
>>
>>
>>
>> On 3 August 2018 at 17:57, Geertjan Wielenga <
>> geertjan.wielenga@googlemail.com.invalid> 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.
>>>
>>>
>>
>
Re: Plug-in support and compatibility suggestion
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
Not sure I understand fully, but isn't what you describe already the case?
Backward compatibility is one of the key aspects of NetBeans going many
years back now.
Gj
On Tue, Aug 7, 2018 at 8:58 AM, * William <wi...@gmail.com>
wrote:
>
> Thank you Geertjan,
>
> I understand the licienseing point -- Yes in that specific case, yes the
> plugin needs to be compatible.
>
> I am unconcerned about specific missing plugins. I had hoped my point was
> clear enough as this is something that applies to a Great Many products
> that use "plug-in" and "add-on" mechanisms.
>
> I feel that products in general should provide 'useability' support for
> compliant and compatible plug-ins that work from the previous version.
>
> In the case of Netbeans as on specific example, v9.0 *would* permit
> support for v8.2 plugins.
>
> And only the ones that work/are compatible and compliant with the
> licensing and infrastructiure/platform changes.
>
> I really think that would be a big plus for any platform/product.
>
>
>
> On 3 August 2018 at 17:57, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com.invalid> 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.
>>
>>
>
Fwd: Plug-in support and compatibility suggestion
Posted by * William <wi...@gmail.com>.
Thank you Geertjan,
I understand the licienseing point -- Yes in that specific case, yes the
plugin needs to be compatible.
I am unconcerned about specific missing plugins. I had hoped my point was
clear enough as this is something that applies to a Great Many products
that use "plug-in" and "add-on" mechanisms.
I feel that products in general should provide 'useability' support for
compliant and compatible plug-ins that work from the previous version.
In the case of Netbeans as on specific example, v9.0 *would* permit support
for v8.2 plugins.
And only the ones that work/are compatible and compliant with the licensing
and infrastructiure/platform changes.
I really think that would be a big plus for any platform/product.
On 3 August 2018 at 17:57, Geertjan Wielenga <geertjan.wielenga@googlemail.
com.invalid> 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.
>
>
Re: Plug-in support and compatibility suggestion
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <wi...@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.
>
>
> ___________________________________
>
>
>
>