ApacheNetBeans
From APIDesign
In autumn 2016 Oracle decided to donate NetBeans to Apache foundation. The process wasn't smooth, but the community made it! This page contains my reflection on the history of NetBeans at Apache.
Contents |
Apache can Distribute GPLwithClassPathException Code
NetBeans 13 has been released in February 2022 and it contains bundled nb-javac (licensed under GPLwithClassPathException). This is the first GPLwithClassPathException component approved for distribution by any Apache project. Getting the approval wasn't easy, but it certainly worth it!
Regular Quarterly Releases
Apache NetBeans project got out of incubator and is now regular top level Apache project. Since July 2019 there are regular quarterly releases of the Apache NetBeans IDE. Heaving such predictability in the release schedule is great. Everyone building own applications on top of NetBeans Runtime Container knows when bugfixes will be made. It is clear when new bits appear on Maven central.
Great work Apache NetBeans community!
Apache HTML/Java API 1.5 has been released!
It is Oct 23, 2017 and the first project from the NetBeans Apache incubator has managed to create a release. The HTML/Java API version 1.5 has passed through all the Apache tests and is now available as a source download: see the netbeans svn repository. In addition to that I have uploaded the binaries to Maven central repository: see for example the pom parent project. As you can see the bits have Apache license now.
Time to give the release a try. Time to update to 1.5 release! Time to contribute. Just fork the GitHub repository.
Relicensing
The first step after donating to Apache was to change licenses in all files and verify that all libraries are compatible with Apache license. Everything went fine, just once library org.json JSON parser was found inappropriate. Funny why: its is a MIT licensed piece of software, just with one additional note: the software shall be used for good and not evil!. Based on that Apache (as well as Debian, as well as Android - e.g. Google) concluded that the software is associated with field of use restriction and as such it can't be replaced. I have bug NETBEANS-89 to deal with it in future versions.
Automate what you can!
The process of releasing the source code (yes, source code, as Apache releases are always about source code! Didn't you know? I didn't!) wasn't easy. That was sort of expected. First release under a new organization is never easy. The organization has new rules, workflows, terminology and fulfilling all of that takes time.
Moreover I decided to do everything correctly - e.g. don't take any shortcuts, but rather set infrastructure up to simplify future releases. For example, we have a jenkins job to create the .zip file as well as associated .md5 and .sha1 files. The job is set up to produce so called parametrized builds - once anybody feels it is time to release - one can pass in the new release version number and start the build.
While running the build, it gets the name release-X.Y based on the specified version parameter. As you can see, there were a few attempts that didn't make it (rc1-1.5 and rc2-1.5) and also few complete failures (completely deleted builds) before build #19 succeeded.
Signing
The final build has to be accompanied with a .asc signing file. The key used to generate the signing file has to come from list of keys approved for the Apache NetBeans project. That took a while as well, but at the end I made it and the release got approved.