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 <boris.heithec...@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 > <geertjan.wiele...@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.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. > >>> > >>> 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-unsubscr...@netbeans.apache.org > For additional commands, e-mail: users-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > >
