Dear all,
I've also read the things further down in this thread. I feel some
chicken and egg problem here.
It is Ok and I welcome to have a JavaPlatform installer in the Java
Platforms.
What got me is, that if a feature won't be mainstream NetBeans
functionality, then the community shall not run another round of release
dance on a special branch.
Everyone has the right to fork the NetBeans repository with its release
branches and add functionality upon them then bundle the whole thing
together as a distribution. There are many other ways of course, but
generating more work for the community for some vendor specific thing is
a big no-no for me.
On 6/27/20 1:06 AM, Geertjan Wielenga wrote:
Azul would most likely want to include functionality for selecting, using,
and updating Zulu from within their bundle of NetBeans. I.e., so that when
Java development is done in the NetBeans bundled with Zulu, the developer
can choose Zulu and also keep their Zulu install updated.
This would not be mainstream NetBesns functionality, we’d need a special
branch off the release branch for this, with an official Apache NetBeans
release process, voting, etc, and then the convenience binary would be
bundled with Zulu and made available on an azul.com domain.
Does this sound doable?
Gj
On Sat, 27 Jun 2020 at 08:33, Geertjan Wielenga <geert...@apache.org> wrote:
Hi all,
If Azul were to distribute a bundle of NetBeans with Zulu, i.e., the
bundle would be downloadable from an Azul domain, would we as a community
be interested in doing the work of putting that bundle together?
It would be a process that would take place once a year, with our NetBeans
LTS together with whatever the current LTS of Zulu is at that time.
We in the NetBeans community would create and test the bundle, and would
approve it as a community — sometime after the NetCAT process since the
binaries would need to exist for the bundle to be created, so maybe simply
by approving the bundle in a thread, not as an official vote thread since
the bundle would not be an Apache release, of course.
Potentially, Azul could create a plugin for updating Zulu after it’s been
installed — and put that plugin into our Plugin Portal.
This would solve our problem of not having a JDK vendor that provides the
complete NetBeans out of the box experience. The bundle would be called
“Apache NetBeans Zulu Bundle” and we’d point to it from our download page,
with statements that it is not an Apache release, etc.
With my three hats “Apache”, “NetBeans”, “Azul” on at the same time, this
sounds good.
Thoughts on this?
Thanks,
Gj
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
