Sure, whatever works best. Is there a way a plugin can be pre-installed, that would very simply solve this.
Gj On Mon, 29 Jun 2020 at 09:07, Laszlo Kishalmi <laszlo.kisha...@gmail.com> wrote: > 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 > > > >