Re: [DISCUSS] Apache NetBeans roadmap updates
> There should be no barriers in implementing functionality as plugins. Everything about programming and API design is making barriers. Although, if you think about it there are no true barriers, you can use reflection to hack into almost every corner of NetBeans. But what you would ideally want is for a neat API that provides you all these hooks, so the plugin author does little work and NetBeans takes the burden of creating (and maintaining!) this open API. So, it's a false problem. The actual problem has always been the same: maintaining quality and backwards compatibility implies being intentional about the things we support and the things we don't. There is nothing stopping people suggesting API improvements and making PRs, but we can't just make everything public and call it a day. Because then the next release comes and all the existing plugins stop working (or... we can't evolve anymore since we commit to such a big public API that we painted ourselves in a corner). The idea of providing experimental features as plugins is cool but somebody will have to do the work for all the plumbing. Those experimental features won't just become new modules into core, they will just get absorbed into the existing codebase when they are fully baked. Nothing preventing this to happen even right now, there just is no such magical generic infrastructure for it to happen. > How is it with PHP, is it a plugin which can be updated when new versions are > released e.g. PHP 7.4, or do we need to wait until the next major release of > Netbeans to get support for new versions? Worse case scenario we are looking at a 3-6 months delay, correct? Although the problem won't be about the release date, it will be about making sure somebody actually implements the proper support for the next PHP dot release. Assuming we are proactive about that, I don't see why we wouldn't have an out-of-band release specifically to include our improved PHP stuff. These things are not set in stone. --emi On Fri, Nov 16, 2018 at 5:00 PM Ondro Mihályi wrote: > > I fully agree. There should be no barriers in implementing functionality as > plugins. Before every NB release, the community could vote on plugins to > include in NB core to add their functionality into core. That would still > allow updating core plugins to a newer version without waiting for another > NB release. > > Dňa št 15. 11. 2018, 11:39 Christian Lenz > napísal(a): > > > Hey, > > > > My 2 cents here again. First I want to know, what you think, how the minor > > Releases should look like. If they also contains Features, I’m fine with > > that two. > > > > I will be more fine to have only 2 releases, if we can have more public > > apis for other languages except Java. This is, IMHO a big Problem that a > > lot of stuff, can’t be done with 3rd-party Plugins for HTML, PHP, JS, CSS, > > etc. because of missing public APIs. If we have more public APIs, we can > > have more Features inside of NetBeans with only 3rd-party Plugins. > > > > We can’t adding hints and Code fixes for JS, CSS/LESS/SCSS, PHP or HTML > > which could make the work easier. And this is only one Little example. We > > can’t adding embedding languages to the mentioned languages. > > > > NetBeans first was build only for Java, this is why the Tokens of Java are > > public, the hints and fixes you can add with 3rd-party Plugins. So this is > > why you can add a lot of stuff to the Java Editor with 3rd-party Plugins. > > If we are open-source, we should open minded too to let the Developers > > decide, whether I want to add my feature into the core and wait 6 month > > after it is relased to the next Version or to add it via a Plugin and can > > bring it up today or tomorrow. > > > > > > Cheers > > > > Chris > > > > > > > > Von: Peter Hull > > Gesendet: Donnerstag, 15. November 2018 09:06 > > An: dev.ataur.rah...@gmail.com > > Cc: neilcsm...@apache.org; jiri.koval...@oracle.com; NetCAT team; > > NetBeans Mailing List; d...@netbeans.apache.org > > Betreff: Re: [DISCUSS] Apache NetBeans roadmap updates > > > > The 2 + 2 option makes sense to me. I'd be interested in hearing > > people's thoughts about how this lines up with JDK releases: > > * Is it better to do the NB testing after the general availability of > > the JDK, or aim to have them released about the same time? > > * What versions of JDK does Netbeans need to support, in terms of > > developing/building NB itself, running NB and developing Java > > applications using NB. (since there are alternatives to Oracle JDK I > > suppose we don't need to be influenced by Oracle's support scheme) > > > > - > > 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: > >
RE: using tools repository for holding jenkins build script
Hi I try start branding the javadoc for release90 on this PR https://github.com/apache/incubator-netbeans/pull/1022 I would like that the Antonio Vieiro commit be also on release90. How can this be done ? 4f98d5b61eb81ea88f1e441a517dbb8864ff20ee I'm not sure this is good enough because we write NetBeans instead of Apache NetBeans in lots of place. Should we fix that or postpone this kind of issue. Best Regards Eric -Message d'origine- De : Neil C Smith Envoyé : jeudi 15 novembre 2018 16:34 À : dev@netbeans.incubator.apache.org Objet : Re: using tools repository for holding jenkins build script Hi, On Wed, 14 Nov 2018 at 15:45, Eric Barboni wrote: > This is possible but we need someone to do it on the netbeans-vm. > Do you have the knowledge? Sorry, somehow missed this. No, not directly for the netbeans-vm. I've used them a lot and set up a few on frameworks for work projects, but not sure what we've got on the vm that would be the best way to handle this. Using Apache or something else? A quick search found ... webhook! :-) There's an Ubuntu package for it. Might be a simple way to do it? https://github.com/adnanh/webhook Best wishes, Neil - 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 - 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
Re: [DISCUSS] Apache NetBeans roadmap updates
I fully agree. There should be no barriers in implementing functionality as plugins. Before every NB release, the community could vote on plugins to include in NB core to add their functionality into core. That would still allow updating core plugins to a newer version without waiting for another NB release. Dňa št 15. 11. 2018, 11:39 Christian Lenz napísal(a): > Hey, > > My 2 cents here again. First I want to know, what you think, how the minor > Releases should look like. If they also contains Features, I’m fine with > that two. > > I will be more fine to have only 2 releases, if we can have more public > apis for other languages except Java. This is, IMHO a big Problem that a > lot of stuff, can’t be done with 3rd-party Plugins for HTML, PHP, JS, CSS, > etc. because of missing public APIs. If we have more public APIs, we can > have more Features inside of NetBeans with only 3rd-party Plugins. > > We can’t adding hints and Code fixes for JS, CSS/LESS/SCSS, PHP or HTML > which could make the work easier. And this is only one Little example. We > can’t adding embedding languages to the mentioned languages. > > NetBeans first was build only for Java, this is why the Tokens of Java are > public, the hints and fixes you can add with 3rd-party Plugins. So this is > why you can add a lot of stuff to the Java Editor with 3rd-party Plugins. > If we are open-source, we should open minded too to let the Developers > decide, whether I want to add my feature into the core and wait 6 month > after it is relased to the next Version or to add it via a Plugin and can > bring it up today or tomorrow. > > > Cheers > > Chris > > > > Von: Peter Hull > Gesendet: Donnerstag, 15. November 2018 09:06 > An: dev.ataur.rah...@gmail.com > Cc: neilcsm...@apache.org; jiri.koval...@oracle.com; NetCAT team; > NetBeans Mailing List; d...@netbeans.apache.org > Betreff: Re: [DISCUSS] Apache NetBeans roadmap updates > > The 2 + 2 option makes sense to me. I'd be interested in hearing > people's thoughts about how this lines up with JDK releases: > * Is it better to do the NB testing after the general availability of > the JDK, or aim to have them released about the same time? > * What versions of JDK does Netbeans need to support, in terms of > developing/building NB itself, running NB and developing Java > applications using NB. (since there are alternatives to Oracle JDK I > suppose we don't need to be influenced by Oracle's support scheme) > > - > 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 > > > > >
Re: Profiler crash for NB10
On Thu, Nov 15, 2018 at 6:02 AM Emilian Bold wrote: > PS: @Peter: if you could also make a recompiled .DLL available > together with the branch it would be great. Right, I have put changes into a fork here: https://github.com/pedro-w/incubator-netbeans/tree/profiler-tmp and the binaries (just the native code dll) https://github.com/pedro-w/incubator-netbeans/releases/tag/v0.1-alpha I have tested it and it seems to be working on Windows 64. I've tested it compiles on Windows 32. I have not tested or looked at any other platform (though I don't think my changes should cause problems) I speculate the problem was some incorrect casting (can't cast a 64 bit pointer to long on Windows?) which maybe didn't manifest on previous JDKs because the values of jmethodid. I don't know enough about the internals of the JVM but I'm still not sure if the method used to convert a jmethodid to a jint is robust going forward. Please let me know what you think, Pete - 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
