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
