Apache NetBeans

Monday June 10, 2019

Apache NetBeans, OpenJFX, and AdoptOpenJDK

Check out a great series of articles on a killer combination, by Chris Luff—Apache NetBeans, OpenJFX, and AdoptOpenJDK.

In part one you see how to get a modular JavaFX application built and running from NetBeans. In part two, you look at generating, from Maven, a runtime to execute the application. In part 3, you learn about the distribution of the new application.

Here are the three parts:

Posted at 10:35AM Jun 10, 2019 by Geertjan in General | Comments [3] |

Thursday April 25, 2019

[ANNOUNCE] Apache NetBeans Has Graduated!

We have graduated from the Apache Incubator and we are now a top level Apache project at The Apache Software Foundation (ASF).

"Being part of the ASF means that NetBeans is now not only free and Open Source software: it is also, uniquely, and for the first time, part of a foundation specifically focused on enabling open governance," said Geertjan Wielenga, Vice President of Apache NetBeans. "Every contributor to the project now has equal say over the roadmap and direction of NetBeans. That is a new and historic step and the community has been ready for this for a very long time. Thanks to the strong stewardship of NetBeans in Sun Microsystems and Oracle, Apache NetBeans is now ready for the next phase in its development and we welcome everyone to participate as equals as we move forward."

The above is from the official Apache press release, all of which can be read here:

https://blogs.apache.org/foundation/entry/the-apache-software-foundation-announces51

Posted at 08:36PM Apr 25, 2019 by Geertjan in General | Comments [1] |

Friday April 05, 2019

[ANNOUNCE] Apache NetBeans (incubating) 11.0 Released

The Apache NetBeans team is proud to announce the release of Apache NetBeans (incubating) 11.0.

Apache NetBeans (incubating) 11.0 constitutes all clusters in the Apache NetBeans Git repo, which together provide the NetBeans Platform (i.e., the underlying application framework), as well as all the modules that provide the Java SE, Java EE, PHP, JavaScript and Groovy features of Apache NetBeans.

In short, Apache NetBeans (incubating) 11.0 is a full IDE for Java SE, Java EE, PHP and JavaScript development with some Groovy language support.

Read more on our download page:

https://netbeans.apache.org/download/nb110/nb110.html

New & Noteworthy features of the 11.0 Release:

https://netbeans.apache.org/download/nb110/index.html

Posted at 02:56PM Apr 05, 2019 by Geertjan in General | Comments [4] |

Friday February 01, 2019

Restructuring of Project Templates in Apache NetBeans

There's been lots of discussion in the Apache NetBeans community about how best to express the fact that Apache Maven and Apache Gradle are more modern choices to be aware of than Apache Ant, while at the same time not implying that there's anything wrong with using Apache Ant.

Here's what we seem to have reached consensus around, i.e., move all Ant-based project templates into a separate Ant-specific folder, while putting the other two build systems higher and therefore more prominently in the list:

With the above, someone is less likely to simply go to the no-longer-existing Java category and then end up with an Ant-based project, without thinking about it. By default, the user of Apache NetBeans is now encouraged to consider Apache Maven and Apache Gradle first. The old Ant-related categories are still there, so as not to confuse anyone completely, just structured within a lower ranked "Java with Ant" category. The above also solves the discussion re "Java EE", i.e., here the idea, from discussions, is to name the category "Java Enterprise".

At startup, all categories are closed, i.e., none is more prominent initially than any other.

An objection one could have is that, if you're a complete Java newbie, you won't know what Maven, Gradle, or Ant are. Well, that has always been the case and NetBeans has artificially hidden that choice by having a category simply named "Java", which then resulted in everyone ending up with Ant-based projects. To turn that around and have a category simply named "Java" that results in Maven-based projects is probably not right either, i.e., a careful balance needs to be struck.

Hoping that all factions in this lengthy discussion are relatively satisfied with this approach. :-)

Issue: https://issues.apache.org/jira/browse/NETBEANS-2040

Pull request: https://github.com/apache/incubator-netbeans/pull/1115

Posted at 02:31PM Feb 01, 2019 by Geertjan in General | |

Monday January 28, 2019

Enterprise Cluster Integrated into Apache NetBeans

Hurray, the 'enterprise' cluster, constituting all the modules in Apache NetBeans GitHub that provide features for Java/Jakarta EE development, provided in the 2nd Oracle donation of NetBeans to Apache, has been integrated into the daily builds.

Now, for the first time, out of the box, you'll have the support that was part of NetBeans IDE 8.2 for Java EE development directly available in Apache NetBeans, that is, without you needing to install any plugins.

However, aside from the point that this means we do not yet have Java EE 8 support, since 8.2 did not (could not, because of being released some time prior to Java EE 8) have support for Java EE 8, another question now presents itself—whether we really want to have two categories in the New Project dialog, one named "Java EE" and the other named "Java Web", as shown below, with the former containing project types relating to EJBs and EARs, which are not (should not) be very current anymore, as shown below in the screenshots.

My suggestion would be to either relabel the above to "Modern Java EE" and "Vintage Java EE". (I like the word "Vintage", which I've learned about from JUnit, i.e., that's how they refer to JUnit 4.) Once there is Java EE 8 support, we could use the name "Jakarta" instead of "Modern Java EE". Or, maybe the EJB and EAR support should simply be removed?

Posted at 07:03PM Jan 28, 2019 by Geertjan in General | Comments [2] |

Sunday January 27, 2019

Junit 5, Apache Ant, and Apache NetBeans

Junit 5 is, architecturally, so different to previous versions, that it should really be called Jupiter, instead. However, this is not a problem when you're using Maven, since Maven resolves all transitive dependencies for you, and is supported in that way from Apache NetBeans 10 onwards. Not so with Apache Ant, of course, where you need to set each and every JAR you need on a classpath of one form or another.

That is not a pretty picture in the end, when compared to JUnit 4, where you had just that JAR, plus Hamcrest. With JUnit 5, you need, in addition to junit-jupiter-api, junit-jupiter-params, and junit-jupiter-engine, to also declare the transitive dependency apiguardian-api, while in the case of Apache Ant, you need to deal with the JUnitLauncher, if you want to make use of the new junitlauncher Ant task, in addition to four other JARs, which need to be on Ant's classpath, as explained here.

An alternative approach is to use org.junit.platform.console.ConsoleLauncher, as shown here, which looks like this in my build.xml, i.e., it is named test, so that it will run automatically at the end of the test run when the Test Project action is invoked:

<target name="test" depends="compile-test,-pre-test-run">
    <java dir="${work.dir}" 
          classpath="${run.test.classpath}"  
          classname="org.junit.platform.console.ConsoleLauncher">
        <arg value="--scan-classpath"/>
        <arg line="--reports-dir build/test/results"/>
    </java>
    <junitreport todir="build/test/results">
        <fileset dir="build/test/results">
            <include name="TEST-*.xml"/>
        </fileset>
        <report format="frames" todir="build/test/results/html"/>
    </junitreport>
</target>

The above means that the JUnit tasks set by default in the build-impl.xml file will simply fail silently, since I don't have JUnit 4 on my classpath. At the end of the process, the above will be run, org.junit.platform.console.ConsoleLauncher will be found on my classpath, and then the JUnit 5 tests will be run.

What is the advantage of the above over using JUnitLauncher? Well, JUnitLauncher has requirements relating to Ant's path, which has advantages too, of course, i.e., simply set everything up once (which can also be done inside Apache NetBeans, in the Ant tab in the Options window). But, for right now, I'd prefer to work with just one path, i.e., the application's path.

Another downside is that, so far, the above solution doesn't integrate with the Test Results window, though it does produce some nice reports via the junitreport task above, in the build folder.

The key problem seems to me to be that the JUnit Ant task no longer exists in JUnit 5, which was for Ant-based projects the basis of the integration with the Test Results window in Apache NetBeans. If the JUnit task could continue to be used, in whatever way, that would solve a lot of the problems, though the question of the many JARs needed on the classpath would remain. Maybe library providers should reach out to tools providers when putting these kinds of new solutions together, since the only reason that JUnit 5 now works with Maven in Apache NetBeans is that Surefire is used, i.e., in the case of Maven the completely new approach JUnit has taken can simply be avoided there. Here is some relevant discussion in Apache NetBeans GitHub, and the Launcher API looks interesting.

Probably the best solution for Ant users in Apache NetBeans would be to be able to continue to use JUnit 4, rather than JUnit 5, since the latter is a total nightmare to set up in the context of Ant, as described above. In the world of JUnit, "vintage" is the cool name they have for "legacy", and if you're using Ant at all, you're probably best described as "vintage" and hence only having support for JUnit 4 is not a big deal for you. However, not sure at all how that would work, we'd need to investigate how/if when JUnit tests are added to Maven projects, JUnit 5 tests and dependencies would be set, while when adding JUnit tests to Ant projects JUnit 4 tests and dependencies would be set.

Posted at 12:00PM Jan 27, 2019 by Geertjan in General | Comments [0] |

Thursday January 24, 2019

Master Your Scripting Skills with the New Tutorial!

Enhanced scripting tutorial has just become part of Apache NetBeans documentation. It contains various examples showing how to communicate from Java with JavaScript, Python and other languages. The following topics are covered:

Call guest language functions from Java

Access a JavaScript class

Access guest language data structures from Java

Access Java from guest languages

While the primary use-case for this enhanced scripting API is to simplify usage of scripting languages in NetBeans based applications, the API itself is standalone and can be used outside of NetBeans in any project. We are working on making it available in the Maven central repository.

PHP 7.3 Support

To enable it, you have to set PHP 7.3 as the PHP version of your PHP project.

NetBeans provides support for the new three syntaxes.

Allow a trailing comma in function calls

list() Referenct Assignment

Flexible Heredoc and Nowdoc Syntaxes

Note: We won't provide support for the old syntax any longer. i.e. NetBeans treats the following code as an error.

$heredoc = <<< END
END{$variable}
END;

PHP 7.1, 7.2 and more PHP features

The other PHP features for NetBeans 10 are here. We have also implemented PHP7.1, 7.2, new hints, new code foldings and more.

That's all for today. As always, please test it. You can download a development version from Jenkins Build. If you find some issues or enhancements, please report them to JIRA with your exact steps to reproduce them. (Components: php - Editor). Thanks.

Posted at 04:06AM Oct 01, 2018 by Junichi in PHP | Comments [4] |

Wednesday September 26, 2018

PHPStan Support

Hi all. Today, we will show you about PHPStan integration which will be available in the next NetBeans version i.e. NetBeans 10 as a new code analysis feature. If you have already used other code analysis features(e.g. Code Sniffer), you should be able to use this with similar way soon.

Options

First of all, let's set the Options (Tools > Options > PHP > Code Analysis > PHPStan). You can set a script path, a configuration file path and a level. At least you have to set the PHPStan script path to "PHPStan". If you don't set "Configuration" path, the configuration file of project root directory would be used.

Inspect project/directory/file

Then, let's inspect a project/direcoty/file using PHPStan. Please click "Source > Inspect...". The inspect dialog is shown.

Please choose "Scope" which you would like to inspect and PHPStan as "Configuration". The files are inspected when you click the "inspect" button. Finally, The results are shown in the inspector window after the inspection is done.

That's all for today. As always, please test it. You can download a development version from Jenkins Build. If you find some issues or enhancements, please report them to JIRA (Components: php - Code). Thanks.

Posted at 03:21AM Sep 26, 2018 by Junichi in PHP | Comments [5] |

Thursday September 06, 2018

Audio of Virtual Apache NetBeans Meeting 3

The third of a series of informal virtual meetups took place today, focused specifically on why/how/when to move netbeans.org to Apache.

The audio of the meeting is available here and takes about 53 minutes:

https://www.youtube.com/watch?v=VmhX4VAlWlc

Screenshot of what we saw of each other, partly:

The Apache Software Foundation
Blogging in Action.