Re: Git Toolbar into NetBeans
Hi. The plugin code is already licensed as Apache 2.0. So feel free to integrate it as a plugin for the official plugin center, fork it or integrate the layer entries into the layer.xml of the git plugin. And yes, it is only a layer.xml. This type of a layering filesystem registry is very mighty - thanks to the original authors Best regards Benno On Wed, Jan 30, 2019, 7:40 AM Tomas Poledny Hi, Why this git actions (create branch ...) are not simple available in > customize toolbar? > > On Wed, Jan 30, 2019, 07:34 Laszlo Kishalmi wrote: > >> Dear Benno, Team, >> >> I'm wandering if we can add the Git Toolbar Plugin to the 11.0 release. >> https://github.com/markiewb/nb-git-toolbar >> >> I find this plugin quite useful, as even the most common Git actions are >> 2-3 level deep in submenu-s, so for me most of the times it is easier to >> deal with the command line tools, rather than using the IDE Git >> integration. This plugin changes that. >> >> The original author announced that the project is dead and seeking for >> maintenance takeover. Well, actually the essence of this plugin is a >> simple layer.xml which we can easily put into our existing Git module >> without any hustle. >> >> Can we simply do that, mentioning Benno somewhere? >> >> >> 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 >> >> >> >>
Re: Git Toolbar into NetBeans
Hi, Why this git actions (create branch ...) are not simple available in customize toolbar? On Wed, Jan 30, 2019, 07:34 Laszlo Kishalmi Dear Benno, Team, > > I'm wandering if we can add the Git Toolbar Plugin to the 11.0 release. > https://github.com/markiewb/nb-git-toolbar > > I find this plugin quite useful, as even the most common Git actions are > 2-3 level deep in submenu-s, so for me most of the times it is easier to > deal with the command line tools, rather than using the IDE Git > integration. This plugin changes that. > > The original author announced that the project is dead and seeking for > maintenance takeover. Well, actually the essence of this plugin is a > simple layer.xml which we can easily put into our existing Git module > without any hustle. > > Can we simply do that, mentioning Benno somewhere? > > > 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 > > > >
Git Toolbar into NetBeans
Dear Benno, Team, I'm wandering if we can add the Git Toolbar Plugin to the 11.0 release. https://github.com/markiewb/nb-git-toolbar I find this plugin quite useful, as even the most common Git actions are 2-3 level deep in submenu-s, so for me most of the times it is easier to deal with the command line tools, rather than using the IDE Git integration. This plugin changes that. The original author announced that the project is dead and seeking for maintenance takeover. Well, actually the essence of this plugin is a simple layer.xml which we can easily put into our existing Git module without any hustle. Can we simply do that, mentioning Benno somewhere? 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
Re: Re: What to do with features for EARs and EJBs?
I’m a little bit of an outsider looking in but give the older technologies are still Java EE why confuse things with Vintage and Legacy and just leave them there with the new Jakarta EE category when available. Then just make sure to have a Version attribute to configure the setup of the project? I thought recent Java EE has different profiles ( Web Profiles, Full Profiles,etc.). Would linking with these profiles work better? Or is the Java Web not necessarily related to Java EE Web Profiles? Is the Java Web more of a micro service? Would having an Enterprise category work better maybe and allowing different flavors under that? Eric Bresie ebre...@gmail.com > On January 28, 2019 at 11:50:02 PM CST, Josh Juneau > wrote: > I certainly agree that we need to keep this functionality within the IDE. > Regarding naming and/or breaking it out into an extension: I would be in > favor of keeping this functionality under a "Vintage Java EE" category. That > is what it is, correct? I think we will need a "Jakarta EE" category in the > near future, and this new category will not contain older functionality. I > would prefer going straight to "Jakarta EE" as a category, rather than use > "Modern Java EE". Jakarta EE 8 is due out soon and it will be in alignment > with Java EE 8. > > Older (deprecated) functionality should go into the "Vintage Java EE" > category. As Ken had mentioned, these technologies have not been deprecated, > but these older EAR wizards would certainly be vintage in my opinion. If the > day comes where most of the necessary EJB functionality is moved into other > APIs, then maybe it can be broken off as an add-on extension...but not until > then. > > Hope this makes sense. Thanks for all of the work that has gone into moving > the IDE forward. > > Josh Juneau > juneau...@gmail.com > http://jj-blogger.blogspot.com > https://www.apress.com/index.php/author/author/view/id/1866 > > > On Jan 28, 2019, at 3:41 PM, Brett Ryan wrote: > > > > Geertjan’s article is not about removing EE support it’s what to do about > > the old Java EE which is deprecated in favour of Jakarta EE in the future > > being the modern EE variant. > > > > For those that do not know, yes; Java EE 8 is the last version of Java EE, > > Jakarta EE while not being a replacement it is the new way forward for > > enterprise web applications. Removing legacy support in favour of new > > technologies is certainly not suicide it is moving with the times. > > > > Spring support has always been brilliant in NetBeans with bean navigation > > suppirt and now a lot of bootstrap support, but that’s the modern current > > focus. > > > > > On 29 Jan 2019, at 08:33, Tomas Poledny wrote: > > > > > > NetBeans had the best support of JEE from all IDE. Support for Spring is > > > very poor. I think remove of support part of JEE is suicide for NetBeans. > > > This is main reason why I am using NetBeans. > > > Tomas > > > > > > > On Mon, Jan 28, 2019, 22:24 Brett Ryan > > > > > > > It’s always a sensitive topic whenever considering to remove something, > > > > however; I am in favour for removing classic JavaEE support in favour of > > > > concentrating on modern java web technologies such as spring and > > > > Jakarta. > > > > > > > > It becomes an enormous task to support everything. We can always provide > > > > support in the form of a plugin though I feel that those using classic > > > > Java > > > > EE may not benefit from the additions being added to NetBeans IDE and > > > > may > > > > continue to use 8.2. > > > > > > > > > > On 29 Jan 2019, at 06:05, Geertjan Wielenga > > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > Especially to Java/Jakarta EE people out there, e.g., Ivar, Josh, > > > > > David, > > > > at > > > > > least -- please advise what should be done with the EAR and EJB > > > > > support, > > > > as > > > > > described here: > > > > https://blogs.apache.org/netbeans/entry/enterprise-cluster-integrated-into-apache > > > > > > > > > > And, hurray, thanks Matthias especially, and Vikas, Arunava, Sarvesh, > > > > > and > > > > > Reema, for a lot of work on relicensing, for getting the enterprise > > > > cluster > > > > > integrated! > > > > > > > > > > Gj > > > > > > > > - > > > > 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: > >
Re: Opening existing Gradle projects in new Gradle support
Well, I would not say that this is impossible to do. My only concern is
to be able to support this, I would need to implement some command line
parser.
It would be good if Gradle come out with some out-of-the-box solution
for this. As at the moment this is even a workaround in Gradle itself.
Please create a JIRA Improvement on this, but I fear it won't be
included in the 11.0 release.
On 1/29/19 7:54 AM, Scott Palmer wrote:
For non-modular projects that need to add modules to the module-path, I'm
using Gradle code to add --module-path and --add-modules calls to the javac
tasks.
E.g. something like this:
tasks.withType(JavaCompile) {
options.compilerArgs.add '--module-path'
options.compilerArgs.add configurations.modules.asPath
options.compilerArgs.add '--add-modules'
options.compilerArgs.add addedModules.join(',')
}
This works for building with Gradle, but NetBeans is blind to the added
modules. It highlights import statements as errors for example.
I'm currently hacking around this my also adding the modules to the
'compileOnly' configuration (so the modules aren't added to the classpath
at runtime or included in the dependency set for the project). Is there a
better way to handle this?
This workaround only works because the modules (JavaFX) are available as
jars as well as jmods. I'm using the jmods to generate a runtime where the
native libraries are properly installed so I don't have to deal with the
hack of extracting them from a jar at runtime.
It is likely that my project will never be truly modular because that only
works properly when all dependencies are *explicit* modules as well.
Something that is still a long way off.
Scott
On Thu, Jan 24, 2019 at 3:53 AM Geertjan Wielenga
wrote:
Great to hear. Would be great to have step by step instructions for opening
Griffon into Apache NetBeans, trying via your instructions now.
I also tried to open this, which opened without a problem at all and looks
great in Apache NetBeans:
https://github.com/gradle/gradle-build-scan-quickstart
Would be excellent if multiple people would try to open their Gradle
projects (daily builds are here
https://builds.apache.org/job/incubator-netbeans-linux/) and provide
comments and feedback on success/failure.
Gj
On Thu, Jan 24, 2019 at 9:29 AM Laszlo Kishalmi
Well you've picked a good one. It does not even loadable from command
line once you've checked out.
It requires 3 external project to be downloaded next to this one. Also
it needs some sonatypeUsername and sonatypePassword.
I tried to provide some value to those, but it seems I need to provide
my bintray username and password for this to work otherwise I get:
> Configure project :application-master-pom
[application-master-pom] Bintray credentials.username is blank
[application-master-pom] Bintray credentials.password is blank
FAILURE: Build failed with an exception.
The only cheat I've made to get there is to comment out the includeBuild
from settings.gradle and set Gradle version to 5.1.1 in the Tools >
Options > Java > Gradle
Probably I shall file them some PR-s to be more friendly with newcomers.
I've used a former version of this project as test about a year ago.
On 1/23/19 11:51 PM, Geertjan Wielenga wrote:
Hi all,
I'm looking at existing projects and trying to open them now that
Gradle
is
integrated into Apache NetBeans.
For example, should this be openable:
https://github.com/griffon/griffon
Thanks,
Gj
-
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: [VOTE] Apache NetBeans Version Number: 11.0
+1 Le mar. 29 janv. 2019 à 20:34, Jose Ch a écrit : > +1 > > El lun., 28 ene. 2019 a las 18:03, Junichi Yamamoto (< > junichi0...@gmail.com>) > escribió: > > > +1 > > > > On Sat, Jan 26, 2019 at 12:51 PM Laszlo Kishalmi > > wrote: > > > > > > Dear all, > > > > > > Well, it is time to finalize out version scheme for a while. There will > > > be three voting threads created on this topic with subjects: > > > > > > * [VOTE] Apache NetBeans Version Number: 11 > > > * [VOTE] Apache NetBeans Version Number: 11.0 > > > * [VOTE] Apache NetBeans Version Number: 2019.03 > > > > > > Everyone from the community can cast his/her own vote on each thread > as: > > > > > > +1 I like it, let's do this way > > > 0I'm Ok with it, does not particularly like it, but won't mind it > > > -1 I do not like it at all. > > > > > > Each thread is going to be open for 72+ hours and going to be closed at > > > the same time. Regardless from the number of votes, that version number > > > would win which has the greatest sum of the vote values. > > > > > > Voting is a community event! Be a proud community member and cast your > > vote! > > > > > > Thank you! > > > > > > Laszlo Kishalmi > > > > > > Volunteer Release Manager of Apache NetBeans 11.0 > > > > > > P.S.: Please keep this thread for voting only! > > > > > > > - > > 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: [VOTE] Apache NetBeans Version Number: 11
-1 Le mar. 29 janv. 2019 à 20:34, Jose Ch a écrit : > -1 > > El lun., 28 ene. 2019 a las 18:02, Junichi Yamamoto (< > junichi0...@gmail.com>) > escribió: > > > 0 > > > > On Sat, Jan 26, 2019 at 12:51 PM Laszlo Kishalmi > > wrote: > > > > > > Dear all, > > > > > > Well, it is time to finalize out version scheme for a while. There will > > > be three voting threads created on this topic with subjects: > > > > > > * [VOTE] Apache NetBeans Version Number: 11 > > > * [VOTE] Apache NetBeans Version Number: 11.0 > > > * [VOTE] Apache NetBeans Version Number: 2019.03 > > > > > > Everyone from the community can cast his/her own vote on each thread > as: > > > > > > +1 I like it, let's do this way > > > 0I'm Ok with it, does not particularly like it, but won't mind it > > > -1 I do not like it at all. > > > > > > Each thread is going to be open for 72+ hours and going to be closed at > > > the same time. Regardless from the number of votes, that version number > > > would win which has the greatest sum of the vote values. > > > > > > Voting is a community event! Be a proud community member and cast your > > vote! > > > > > > Thank you! > > > > > > Laszlo Kishalmi > > > > > > Volunteer Release Manager of Apache NetBeans 11 > > > > > > P.S.: Please keep this thread for voting only! > > > > > > > - > > 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: [VOTE] Apache NetBeans Version Number: 11.0
+1 El lun., 28 ene. 2019 a las 18:03, Junichi Yamamoto () escribió: > +1 > > On Sat, Jan 26, 2019 at 12:51 PM Laszlo Kishalmi > wrote: > > > > Dear all, > > > > Well, it is time to finalize out version scheme for a while. There will > > be three voting threads created on this topic with subjects: > > > > * [VOTE] Apache NetBeans Version Number: 11 > > * [VOTE] Apache NetBeans Version Number: 11.0 > > * [VOTE] Apache NetBeans Version Number: 2019.03 > > > > Everyone from the community can cast his/her own vote on each thread as: > > > > +1 I like it, let's do this way > > 0I'm Ok with it, does not particularly like it, but won't mind it > > -1 I do not like it at all. > > > > Each thread is going to be open for 72+ hours and going to be closed at > > the same time. Regardless from the number of votes, that version number > > would win which has the greatest sum of the vote values. > > > > Voting is a community event! Be a proud community member and cast your > vote! > > > > Thank you! > > > > Laszlo Kishalmi > > > > Volunteer Release Manager of Apache NetBeans 11.0 > > > > P.S.: Please keep this thread for voting only! > > > > - > 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: [VOTE] Apache NetBeans Version Number: 11
-1 El lun., 28 ene. 2019 a las 18:02, Junichi Yamamoto () escribió: > 0 > > On Sat, Jan 26, 2019 at 12:51 PM Laszlo Kishalmi > wrote: > > > > Dear all, > > > > Well, it is time to finalize out version scheme for a while. There will > > be three voting threads created on this topic with subjects: > > > > * [VOTE] Apache NetBeans Version Number: 11 > > * [VOTE] Apache NetBeans Version Number: 11.0 > > * [VOTE] Apache NetBeans Version Number: 2019.03 > > > > Everyone from the community can cast his/her own vote on each thread as: > > > > +1 I like it, let's do this way > > 0I'm Ok with it, does not particularly like it, but won't mind it > > -1 I do not like it at all. > > > > Each thread is going to be open for 72+ hours and going to be closed at > > the same time. Regardless from the number of votes, that version number > > would win which has the greatest sum of the vote values. > > > > Voting is a community event! Be a proud community member and cast your > vote! > > > > Thank you! > > > > Laszlo Kishalmi > > > > Volunteer Release Manager of Apache NetBeans 11 > > > > P.S.: Please keep this thread for voting only! > > > > - > 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 > > > >
Upgrading ASM libraries
Dear all, We have multiple usage of ASM libraries and a lib module to provide ASM 5.0.1 to other modules. I happen to need ASM 7.0 which officially supports Java 11, in order to support Code coverage for Gralde projects running Java 11. Should we upgrade our ASM dependency as well? - 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: Opening existing Gradle projects in new Gradle support
For non-modular projects that need to add modules to the module-path, I'm
using Gradle code to add --module-path and --add-modules calls to the javac
tasks.
E.g. something like this:
tasks.withType(JavaCompile) {
options.compilerArgs.add '--module-path'
options.compilerArgs.add configurations.modules.asPath
options.compilerArgs.add '--add-modules'
options.compilerArgs.add addedModules.join(',')
}
This works for building with Gradle, but NetBeans is blind to the added
modules. It highlights import statements as errors for example.
I'm currently hacking around this my also adding the modules to the
'compileOnly' configuration (so the modules aren't added to the classpath
at runtime or included in the dependency set for the project). Is there a
better way to handle this?
This workaround only works because the modules (JavaFX) are available as
jars as well as jmods. I'm using the jmods to generate a runtime where the
native libraries are properly installed so I don't have to deal with the
hack of extracting them from a jar at runtime.
It is likely that my project will never be truly modular because that only
works properly when all dependencies are *explicit* modules as well.
Something that is still a long way off.
Scott
On Thu, Jan 24, 2019 at 3:53 AM Geertjan Wielenga
wrote:
> Great to hear. Would be great to have step by step instructions for opening
> Griffon into Apache NetBeans, trying via your instructions now.
>
> I also tried to open this, which opened without a problem at all and looks
> great in Apache NetBeans:
>
> https://github.com/gradle/gradle-build-scan-quickstart
>
> Would be excellent if multiple people would try to open their Gradle
> projects (daily builds are here
> https://builds.apache.org/job/incubator-netbeans-linux/) and provide
> comments and feedback on success/failure.
>
> Gj
>
>
> On Thu, Jan 24, 2019 at 9:29 AM Laszlo Kishalmi >
> wrote:
>
> > Well you've picked a good one. It does not even loadable from command
> > line once you've checked out.
> >
> > It requires 3 external project to be downloaded next to this one. Also
> > it needs some sonatypeUsername and sonatypePassword.
> >
> > I tried to provide some value to those, but it seems I need to provide
> > my bintray username and password for this to work otherwise I get:
> >
> > > Configure project :application-master-pom
> > [application-master-pom] Bintray credentials.username is blank
> > [application-master-pom] Bintray credentials.password is blank
> >
> > FAILURE: Build failed with an exception.
> >
> > The only cheat I've made to get there is to comment out the includeBuild
> > from settings.gradle and set Gradle version to 5.1.1 in the Tools >
> > Options > Java > Gradle
> >
> > Probably I shall file them some PR-s to be more friendly with newcomers.
> > I've used a former version of this project as test about a year ago.
> >
> > On 1/23/19 11:51 PM, Geertjan Wielenga wrote:
> > > Hi all,
> > >
> > > I'm looking at existing projects and trying to open them now that
> Gradle
> > is
> > > integrated into Apache NetBeans.
> > >
> > > For example, should this be openable:
> > >
> > > https://github.com/griffon/griffon
> > >
> > > Thanks,
> > >
> > > Gj
> > >
> >
> > -
> > 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: Netbeans future platform and IDE packaging and design - brainstorming
My 2 Kč: Versioning of individual JAR files produced by NetBeans is already semantic versioning friendly. However such versioning is completely independent from the version of the final IDE. Version of the whole NetBeans IDE has always been a "marketing number", not a technical one. E.g. no rules apply, changes are made chaotically just to impress, not to mean something. Certainly they aren't predictable - a necessary attribute of semantic versioning. -jt út 29. 1. 2019 v 1:23 odesílatel hanas...@gmail.com napsal: > May I also suggest the following pattern for future release consideration? > > Maven'like / semver.org : using X.Y.Z > > * The netbeans "product" would be X.Y with any value for Z being 100% > compatible with X.Y > > * Thus an executable netbeans jar of netbeans-x.y.z.jar and maybe > netbeans-x.y.jar which wraps and executes the newest x.y.z.jar > available (maybe downloading it from the netbeans site for auto-upgrade > > * the executable JAR would be the slim netbeans application framework > with the following unremovable plugins: > - plugin manager > - plugin for 'distributions' like > : ee > : base > : php > : the different setups as the old netbeans.org > * Each distribution specifies a set of plugins > - each plugin has an x.y.z > > If needed, netbeans...jar and each plugin...jar may be basically a BOM > (bill of materials) that contains required JAR files (think of a FAT > JAR, shade, or SpringBoot executable JAR) > > Thank you, Frederick Bloom > hanasaki > > > - > 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 > >
