On Sun, Sep 23, 2018 at 11:03 AM Christian Lenz <christian.l...@gmx.net> wrote:
> Hey guys, > > please see my last 3 comments of this ticket. It explains, why it is > important to have public APIs instead of Friends: > https://issues.apache.org/jira/browse/NETBEANS-1035?focusedCommentId=16574478&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16574478 > > My personal opinion only. I think noone doubts the a public API is better for plugins. However, I think that it is necessary that at least one of the following is true: a) someone signs up to make a proper public API, that we will be able to enhance compatibly b) we accept that there are smaller or bigger incompatible API changes (size of the incompatible change depends on the nature of the change and of the existing API) c) we accept that some changes to the API will be very difficult to do (compatibly), maybe even so difficult that they won't be made (so difficult that noone will sign up to do the change) So, I wonder what are the views of others on these. Thanks, Jan > The Thing is, no one know, what other nice Plugins will come in the > future, but everytime, someone creates a Plugin which Needs to be friend, > depends on only the next release that someone adds it. That means, that > this Plugin will first work only for the next release, if someone decided > to add this Plugin as a friend. Same happens for every other Plugins that > Comes later. > > It is not that everytime a user want to use the newest IDE, often someone > stays at the IDE if there is Nothing really new for him/her to Change > update. That means, that he/she could miss the Plugin, if it is relevant > for him. In this release. > > And what happens, if someone removes the Plugin as a friend? That happens > for Geertjans KendoUI Plugin. The Plugin worked some versions before, not > now anymore, because it was removed from being a friend. > > Making APIs public makes much more sense for 3rd-party Plugin developers. > I think HTML, JS, CSS, C/C++ PHP and whatever is there is stable enough for > years to say: yes, make them public. And will there some exceptions, that > the devs figure out, someone can fix it Maybe as a patch or for the next > release, which is acceptable. > > > Cheers > > Chris > > > > Von: Laszlo Kishalmi > Gesendet: Sonntag, 23. September 2018 04:45 > An: dev@netbeans.incubator.apache.org > Betreff: Re: Public vs. Friend API Reloaded (Summary) > > Hi all, > This list is what we have inside the current codebase (Without Yenta on > other locations.) > I put those here which have 10+ friend marked. (The complete list is > attached) > Upon this list it could be a good choice to try make the following public > (maybe for NetBeans 10): > • gsf.testrunner > • gsf.testrunner.ui > I know that a few external language plugins are using those as well, and > the API is quite a good shape anyway. > What do you think? > Generated using: find . -name project.xml -exec grep -H -c friend\> {} > \;|sort -r -gt : -k 2 |grep -v :0 > ./ide/dlight.nativeexecution/nbproject/project.xml:147 > ./ide/dlight.nativeexecution.nb/nbproject/project.xml:145 > ./ide/web.common/nbproject/project.xml:68 > ./ide/gsf.testrunner/nbproject/project.xml:40 > ./php/php.api.phpmodule/nbproject/project.xml:39 > ./java/java.api.common/nbproject/project.xml:39 > ./ide/options.editor/nbproject/project.xml:39 > ./java/maven/nbproject/project.xml:37 > ./enterprise/j2ee.common/nbproject/project.xml:34 > ./profiler/profiler.api/nbproject/project.xml:32 > ./profiler/lib.profiler/nbproject/project.xml:32 > ./java/maven.embedder/nbproject/project.xml:31 > ./webcommon/web.clientproject.api/nbproject/project.xml:29 > ./profiler/lib.profiler.common/nbproject/project.xml:29 > ./ide/gsf.testrunner.ui/nbproject/project.xml:28 > ./php/php.api.executable/nbproject/project.xml:27 > ./ide/html.editor.lib/nbproject/project.xml:26 > ./enterprise/j2ee.api.ejbmodule/nbproject/project.xml:25 > ./ide/web.browser.api/nbproject/project.xml:24 > ./ide/lib.terminalemulator/nbproject/project.xml:24 > ./profiler/lib.profiler.ui/nbproject/project.xml:23 > ./java/maven.model/nbproject/project.xml:23 > ./java/j2ee.core.utilities/nbproject/project.xml:23 > ./enterprise/websvc.jaxwsmodel/nbproject/project.xml:23 > ./ide/team.commons/nbproject/project.xml:22 > ./ide/html.editor/nbproject/project.xml:22 > ./profiler/profiler/nbproject/project.xml:21 > ./platform/libs.jna/nbproject/project.xml:21 > ./php/php.api.editor/nbproject/project.xml:21 > ./java/java.preprocessorbridge/nbproject/project.xml:20 > ./ide/web.common.ui/nbproject/project.xml:20 > ./ide/terminal/nbproject/project.xml:20 > ./ide/terminal.nb/nbproject/project.xml:20 > ./java/j2ee.persistenceapi/nbproject/project.xml:19 > ./enterprise/javaee.specs.support/nbproject/project.xml:19 > ./webcommon/javascript2.lexer/nbproject/project.xml:17 > ./ide/xml.multiview/nbproject/project.xml:17 > ./ide/versioning.util/nbproject/project.xml:17 > ./ide/code.analysis/nbproject/project.xml:17 > ./php/php.api.framework/nbproject/project.xml:16 > ./ide/xml.text/nbproject/project.xml:16 > ./ide/versioning.core/nbproject/project.xml:16 > ./webcommon/javascript2.types/nbproject/project.xml:15 > ./platform/core.startup.base/nbproject/project.xml:15 > ./ide/editor.settings.storage/nbproject/project.xml:15 > ./enterprise/websvc.clientapi/nbproject/project.xml:15 > ./enterprise/web.project/nbproject/project.xml:15 > ./websvccommon/websvc.jaxwsmodelapi/nbproject/project.xml:14 > ./webcommon/javascript2.editor/nbproject/project.xml:14 > ./platform/core.startup/nbproject/project.xml:14 > ./java/j2ee.persistence/nbproject/project.xml:14 > ./ide/xml.axi/nbproject/project.xml:14 > ./enterprise/websvc.jaxwsapi/nbproject/project.xml:14 > ./websvccommon/websvc.saas.api/nbproject/project.xml:13 > ./java/whitelist/nbproject/project.xml:13 > ./enterprise/websvc.core/nbproject/project.xml:13 > ./platform/o.n.core/nbproject/project.xml:12 > ./ide/web.webkit.debugging/nbproject/project.xml:12 > ./ide/dlight.terminal/nbproject/project.xml:12 > ./webcommon/javascript2.model/nbproject/project.xml:11 > ./php/php.api.annotation/nbproject/project.xml:11 > ./java/maven.indexer/nbproject/project.xml:11 > ./java/javaee.injection/nbproject/project.xml:11 > ./java/j2ee.metadata.model.support/nbproject/project.xml:11 > ./ide/hudson/nbproject/project.xml:11 > ./extide/options.java/nbproject/project.xml:11 > ./enterprise/j2ee.sun.dd/nbproject/project.xml:11 > ./enterprise/glassfish.common/nbproject/project.xml:11 > ./platform/o.n.bootstrap/nbproject/project.xml:10 > ./java/java.testrunner/nbproject/project.xml:10 > ./java/java.j2seproject/nbproject/project.xml:10 > > ./ide/xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/project.xml:10 > ./ide/jumpto/nbproject/project.xml:10 > ./enterprise/web.jsf/nbproject/project.xml:10 > ./enterprise/web.jsfapi/nbproject/project.xml:10 > > On 09/21/2018 05:26 PM, Tim Boudreau wrote: > You may want to survey modules on Github that use implementation > dependencies or use Uenta to bypass them. For example, I've been tweaking > the rust module from github, which does tag with a couple of csl modules. > Those should count toward "friends". > > -Tim > > On Fri, Sep 21, 2018 at 8:01 PM Laszlo Kishalmi <laszlo.kisha...@gmail.com > > > wrote: > > Dear all, > > I'd like to summarize whet happened on the "API Friendliness" issue: > > We collected a number of possible options on our previous discussions at: > > https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API > > Commenting these options remained really silent though. This means our > Friend APIs most likely stay as they are now. > > I must acknowledge that adding new friends to an existing API is easier > than ever having NetBeans under Apache umbrella. > > I plan not to give up on making some APIs public though. Regarding the > low interest of making something big around this area, I think the most > viable solution is: > > Option 4: Make Module Public when There is more than a Certain Number of > Friend Dependencies. > > So sometime in the future I'm going to create a list of how many friends > a module does have and share the list with you. > > > Thank you all who participated in this effort! > > Laszlo Kishalmi > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org > For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > -- > http://timboudreau.com > > > >
