Re: [VOTE] Release Apache NetBeans 11.2-u1 update

[Josh Juneau]

+1: Successfully passed all steps and runs well.  Thanks for your time and
effort!

Josh Juneau
juneau...@gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/us/search?query=Juneau




On Wed, Nov 27, 2019 at 9:21 AM Neil C Smith  wrote:

> Dear all,
>
> This is the voting candidate for the 11.2 update 1 release of Apache
> NetBeans. This release is identical to 11.2 except for backported
> fixes for -
>
> [NETBEANS-3257] Fixed issue on refactoring rename of java method (and
> potentially other nb-javac issues)
> [NETBEANS-3335] Enhance robustness of HTML Lexer - enter key doesn't
> work in certain files
> [NETBEANS-3290] Fix common.xml causing layer build problems in RCP
> applications
>
> Note you are required to check both sources and convenience binaries
> before voting! See requirements below, as well as information on a
> temporary voting update centre for use with 11.2.
>
>
> Build artefacts are available here:
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans/11.2-u1/
>
> They were built by the Jenkins pipeline at:
>
> https://builds.apache.org/view/M-R/view/NetBeans/job/netbeans-TLP/job/netbeans/job/release112/35/
>
> We are primarily voting on:
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans/11.2-u1/netbeans-11.2-u1-source.zip
>
> SHA512:
>
> 815364dc3e87135e5a1ca20f4765a695cb4a922dc60b0b7da38ed2a34f8a4f0251b1b96b06479969a8e17b65dafeac016506598b2845b942bd0587b3007750c0
>  ./netbeans-11.2-u1-source.zip
>
> KEYS file:
> https://dist.apache.org/repos/dist/release/netbeans/KEYS
>
>
> Before voting +1 you are required to download the signed source code
> package, compile it as provided, and test the resulting executable on
> your own platform, along with also verifying that the package meets
> the requirements of the ASF policy on releases - see
> http://www.apache.org/legal/release-policy.html#management
>
> In particular, you should (at least) follow these steps.
>
> 1. Download the artefact to be voted on and unzip it.
> 2. Check that the artefact does not contain any jar files, except for:
> -
> platform/autoupdate.services/test/unit/src/org/netbeans/api/autoupdate/data/empty.jar
> - enterprise/glassfish.common/test/unit/data/nottaDir-4_1_2.jar
> - enterprise/glassfish.common/test/unit/data/subdir/nottaDir-5.0.jar
> - enterprise/payara.common/test/unit/data/nottaDir-4_1_2.jar
> - enterprise/payara.common/test/unit/data/subdir/nottaDir-5.0.jar
> which are only jars by their name
> 3. Verify the cryptographic signatures, the NOTICE and LICENSE file
> 4. Build it using the README provided by the artefact.
> 5. Look in nbbuild/netbeans for the NetBeans installation created by
> the build process and try running it.
>
>
> In addition to checking the sources, you should check the associated
> convenience binary NBMs at the artefact links above. As well as
> checking any artefact functions correctly, you should check that it
> has been correctly signed by a PMC member, and that the source being
> voted on is sufficient to build the relevant binary.
>
> You can test update of the IDE using the provided NBMs by adding a
> temporary update centre in Tools / Plugins / Settings. You may wish to
> use a temporary install or userdir for this!
>
> https://netbeans.apache.org/nb/updates/11.2/updates.xml.u1
>
> The updated NBM files are JAR signed with an ASF certificate, so will
> show as Third-Party but at least Signed and Valid. A second round of
> updates will download the actual updated nb-javac libraries -
> unfortunately, due to the current temporary keystore used in the build
> process, the nb-javac updates will show as self-signed - I do not
> believe we have any way to fix that for 11.2.
>
>
> This vote is going to be open at least 72 hours, vote with +1, 0, and
> -1 as usual.  Please mark your vote with (binding) if you're an Apache
> NetBeans PMC member to help with voting admin.
>
> If and when this vote passes, the updated source and NBMs will be
> released on to the mirrors, and the updated catalog (as per above)
> merged into the existing update centre on the NetBeans VM.
>
>
> Thank you for all the hard work!
>
> Best wishes,
>
> Neil
>
> -
> 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
>
>
>
>

Re: release verification/validation practices

[Neil C Smith]

On Thu, 28 Nov 2019, 23:52 Ernie Rael,  wrote:

> There might be something with simpler output.
>

Do check the page at
https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+README
That covers both the signing process and some of the checks.

I'm less sure what the best command to recommend to download everything is.

Best wishes,

Neil

>

Re: release verification/validation practices

[Ernie Rael]

The .asc check should look like

   for i in $(find nbms -name '*.asc'); do echo === $i; gpg2 --verify
   $i ${i%.asc};done

There might be something with simpler output.

-ernie

On 11/28/2019 3:29 PM, Ernie Rael wrote:
Going through the verification steps for 11.2-u1, I first downloaded 
the source (with a browser), built, tested. Then saw request to check 
convenience NBMs. I downloaded a set of nbm/asc/sha512 and discovered 
that sha512sum wanted to run from the parent of the nbms directory. I 
wanted to fetch the whole nbms tree. I dusted off wget, but ran into 
trouble and got a tree rooted at dist.apache.org with some stuff not 
of interest downloaded as well. I finally hit upon --no-parent 
(otherwise wget will look at "..") and more options.


Here's some things I found useful, would like to hear tips that others 
can share. To get the nbms tree


   $ wget -o LOG -r --no-parent -nH --cut-dirs=6 --reject 'index.html*' \
https://dist.apache.org/repos/dist/dev/netbeans/netbeans/11.2-u1/nbms
   $ ls
   LOG  nbms  robots.txt

If I'd better realized what I would need beforehand I would have 
started with wget of 11.2-u1


   $ wget -o LOG -r --no-parent --reject 'index.html*' -nH --cut-dirs=5 \
https://dist.apache.org/repos/dist/dev/netbeans/netbeans/11.2-u1/

With the nbm tree rooted at nbms, I could looks at things and check 
sha512 with the commands


   ls -R nbms
   find nbms -name '*.sha512'
   sha512sum -c $(find nbms -name '*.sha512')

Similarly for .asc check.

-ernie


-
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








-
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

release verification/validation practices

[Ernie Rael]

Going through the verification steps for 11.2-u1, I first downloaded the 
source (with a browser), built, tested. Then saw request to check 
convenience NBMs. I downloaded a set of nbm/asc/sha512 and discovered 
that sha512sum wanted to run from the parent of the nbms directory. I 
wanted to fetch the whole nbms tree. I dusted off wget, but ran into 
trouble and got a tree rooted at dist.apache.org with some stuff not of 
interest downloaded as well. I finally hit upon --no-parent (otherwise 
wget will look at "..") and more options.


Here's some things I found useful, would like to hear tips that others 
can share. To get the nbms tree


   $ wget -o LOG -r --no-parent -nH --cut-dirs=6 --reject 'index.html*' \
   https://dist.apache.org/repos/dist/dev/netbeans/netbeans/11.2-u1/nbms
   $ ls
   LOG  nbms  robots.txt

If I'd better realized what I would need beforehand I would have started 
with wget of 11.2-u1


   $ wget -o LOG -r --no-parent --reject 'index.html*' -nH --cut-dirs=5 \
   https://dist.apache.org/repos/dist/dev/netbeans/netbeans/11.2-u1/

With the nbm tree rooted at nbms, I could looks at things and check 
sha512 with the commands


   ls -R nbms
   find nbms -name '*.sha512'
   sha512sum -c $(find nbms -name '*.sha512')

Similarly for .asc check.

-ernie


-
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

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Jan Lahoda]

Hi Ken,

I think your input is needed on these legal-discuss threads:
https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201911.mbox/%3C4169588f-731b-df79-de80-d6640a9e9fa8%40gmail.com%3E
https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201911.mbox/%3CCEB62E1B-B884-4DD3-92BA-5A979AD21D02%40dotnetrdf.org%3E
https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201911.mbox/%3Cd99bd5ff-c44b-a724-d5e7-28de791462e6%40gmail.com%3E

And/or on these legal jira questions:
https://issues.apache.org/jira/browse/LEGAL-488
https://issues.apache.org/jira/browse/LEGAL-489

Jan

On Thu, Nov 28, 2019 at 5:45 PM Kenneth Fogel 
wrote:

> I apologize if I misunderstood but the conversation appeared to me, likely
> incorrectly, to go beyond just bundling a Java JDK. The installers that are
> already there, are they downloading a JDK if one is not present? Requiring
> a separate install of Java is the status quo. If we could make that part of
> the NetBeans installer then we should an we should pursue an exemption to
> Apache policies if required.
>
> Ken
>
>
> -Original Message-
> From: Geertjan Wielenga 
> Sent: November 28, 2019 11:30 AM
> To: dev@netbeans.apache.org
> Subject: Re: [DISCUSS] Dropping Installers from the Release Process leave
> that work to Third Party Distributors
>
> You’re aware that we’re already distributing an installer, right? And that
> that is not what we’re talking about?
>
> We’re talking about the fact that we can’t bundle the JDK with that
> installer and then distribute that installer from Apache.
>
> A simple link on our download page to OpenBeans and AdoptOpenJDK and any
> other distributor is all we need, for the installers of NetBeans that
> bundle the JDK.
>
> Gj
>
>
> On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel 
> wrote:
>
> > This is a bad idea. I personally feel that an installer is mandatory.
> > Eclipse and IntelliJ have installers for all platforms. Leaving it to
> > third parties will mean that we have no oversight on the quality and
> > ease of use of the installer. Only distributing a zip file implies
> > that skills beyond learning to code with NetBeans will be required. We
> > can pretty much write off the education sector if there is no
> > installer. Sorry to be harsh but this is a line I believe we must not
> cross.
> >
> > It is unfortunates, as someone has pointed out, that Apache is not end
> > user friendly but that is no excuse. NetBeans is an end user program
> > and must be as easy to install as any other IDE and have an official
> installer.
> >
> > Ken
> >
> >
> > -Original Message-
> > From: Laszlo Kishalmi 
> > Sent: November 27, 2019 2:41 PM
> > To: Apache NetBeans 
> > Subject: [DISCUSS] Dropping Installers from the Release Process leave
> > that work to Third Party Distributors
> >
> > Dear all,
> >
> > It is a great burden to us to provide the best out-of-the-box install
> > experience with NetBeans. That would mean, providing an installer with
> > JDK, nb-javac probably javafx.
> >
> > See the threads:
> >
> >
> > https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
> > d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E
> >
> >
> > https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
> > a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E
> >
> > On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
> > >
> > > Dear all,
> > >
> > > I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
> > > with Apache NetBeans.
> > >
> > > There are mainly two readings of GPL+CPE:
> > >
> > >  1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
> > > distributed under Apache license, due to CPE  2. CPE only allows
> > > other product built on Java to be distributed
> > > under their own license.
> > >
> > > As I'm not a lawyer, I cannot answer which interpretation is correct
> > > (maybe none of them). ASF has every right to regard the second
> > > interpretation, thus GPL+CPE ended up in the Category-X licenses.
> > >
> > > The following viable possibilities were brought up:
> > >
> > >  1. We may apply for an exception to the board  2. Use some download
> > > logic in the installer.
> > >  3. Leave the binary packaging and distribution to third parties.
> > >
> > > Regarding that there are interest from third parties to built on
> > > Apache NetBeans, I'm going to recommend the PMC to select a few
> > > distributor for creating installer packages and we limit/drop our
> > > installer bundle creation in the future.
> > >
> > > Thank you,
> > >
> > > Laszlo Kishalmi
> > >
> >
> > I do not think that after this discussion we would get the exception
> > from the board Geertjan might try to bring it up there as well.
> >
> > As of me option 2 is questionable.
> >
> > Option 3. is a bit hard to say, but if we can't produce proper
> > installation packages, it would probably better to not create those
> > packages at all, leave that for others.
> >
> > How I imagine 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Emilian Bold]

Does this work: https://github.com/OpenBeans/NetBeans/releases/tag/11.2 ?

--emi


On Thu, Nov 28, 2019 at 11:11 PM Geertjan Wielenga  wrote:
>
> Sure, I don’t see why not. The question is (1) who will make it, (2) what
> will its name and brand be, (3) which JDK will be included, (4) who will
> provide active support when things go wrong.
>
> Gj
>
>
> On Thu, 28 Nov 2019 at 21:44, Ernie Rael  wrote:
>
> > Is it possible, and legal, to put an install bundle on github and point
> > to it?
> >
> > -ernie
> >
> > On 11/28/2019 9:23 AM, Geertjan Wielenga wrote:
> > > Just note that nb-javac won’t be with us forever, work is being done to
> > > remove our need for it. Once that is done, we’ll be in a really good
> > state.
> > >
> > > In the meantime, as well as atter that, we should do everything we can to
> > > work with Kirk and anyone else to provide a bundle of their JDK with
> > > NetBeans.
> > >
> > > Our installer, in whatever way we provide it, will be problematic in one
> > > way or another.
> > >
> > > I just don’t see how we can provide an installer from Apache that bundles
> > > both NetBeans and JDK, whatever that JDK is, but (unless AdoptOpenJDK
> > makes
> > > such a bundle prominently and stably available) that doesn’t mean we
> > should
> > > not try to make even a flawed installer available, i.e., without the JDK,
> > > which is a lot better than nothing.
> > >
> > > Gj
> > >
> > > On Thu, 28 Nov 2019 at 18:08, Laszlo Kishalmi  > >
> > > wrote:
> > >
> > >> Just adding some info:
> > >>
> > >> It is not just about the JDK, but JDK, nb-javac and probably a fitting
> > >> JavaFX runtime.
> > >>
> > >> If someone can bundle those up and provide an installer most probably
> > >> based on the installer code we have, then that would be the best end
> > >> user experience, like in the old days when we said NetBeans just works.
> > >>
> > >> Separate distributions, like OpenBeans, would eventually emerge.
> > >>
> > >> It is just a question of what would be better for the brand. Keeping our
> > >> "crippled" installers and/or offer additional install experience from
> > >> third parties.
> > >>
> > >> On 11/28/19 8:49 AM, Kirk Pepperdine wrote:
> > >>> Hi all,
> > >>>
> > >>> Again, I believe that you could distribute from Adopt with a JDK
> > >> bundled. So maybe this is a case where using a 3rd party makes sense.
> > >>> Kind regards,
> > >>> Kirk
> > >>>
> > >>>
> >  On Nov 28, 2019, at 8:45 AM, Kenneth Fogel <
> > kfo...@dawsoncollege.qc.ca>
> > >> wrote:
> >  I apologize if I misunderstood but the conversation appeared to me,
> > >> likely incorrectly, to go beyond just bundling a Java JDK. The
> > installers
> > >> that are already there, are they downloading a JDK if one is not
> > present?
> > >> Requiring a separate install of Java is the status quo. If we could make
> > >> that part of the NetBeans installer then we should an we should pursue
> > an
> > >> exemption to Apache policies if required.
> >  Ken
> > 
> > 
> >  -Original Message-
> >  From: Geertjan Wielenga 
> >  Sent: November 28, 2019 11:30 AM
> >  To: dev@netbeans.apache.org
> >  Subject: Re: [DISCUSS] Dropping Installers from the Release Process
> > >> leave that work to Third Party Distributors
> >  You’re aware that we’re already distributing an installer, right? And
> > >> that that is not what we’re talking about?
> >  We’re talking about the fact that we can’t bundle the JDK with that
> > >> installer and then distribute that installer from Apache.
> >  A simple link on our download page to OpenBeans and AdoptOpenJDK and
> > >> any other distributor is all we need, for the installers of NetBeans
> > that
> > >> bundle the JDK.
> >  Gj
> > 
> > 
> >  On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel <
> > kfo...@dawsoncollege.qc.ca
> >  wrote:
> > 
> > > This is a bad idea. I personally feel that an installer is mandatory.
> > > Eclipse and IntelliJ have installers for all platforms. Leaving it to
> > > third parties will mean that we have no oversight on the quality and
> > > ease of use of the installer. Only distributing a zip file implies
> > > that skills beyond learning to code with NetBeans will be required.
> > We
> > > can pretty much write off the education sector if there is no
> > > installer. Sorry to be harsh but this is a line I believe we must not
> > >> cross.
> > > It is unfortunates, as someone has pointed out, that Apache is not
> > end
> > > user friendly but that is no excuse. NetBeans is an end user program
> > > and must be as easy to install as any other IDE and have an official
> > >> installer.
> > > Ken
> > >
> > >
> > > -Original Message-
> > > From: Laszlo Kishalmi 
> > > Sent: November 27, 2019 2:41 PM
> > > To: Apache NetBeans 
> > > Subject: [DISCUSS] Dropping Installers from the Release Process leave
> > > that work to Third 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Geertjan Wielenga]

Sure, I don’t see why not. The question is (1) who will make it, (2) what
will its name and brand be, (3) which JDK will be included, (4) who will
provide active support when things go wrong.

Gj


On Thu, 28 Nov 2019 at 21:44, Ernie Rael  wrote:

> Is it possible, and legal, to put an install bundle on github and point
> to it?
>
> -ernie
>
> On 11/28/2019 9:23 AM, Geertjan Wielenga wrote:
> > Just note that nb-javac won’t be with us forever, work is being done to
> > remove our need for it. Once that is done, we’ll be in a really good
> state.
> >
> > In the meantime, as well as atter that, we should do everything we can to
> > work with Kirk and anyone else to provide a bundle of their JDK with
> > NetBeans.
> >
> > Our installer, in whatever way we provide it, will be problematic in one
> > way or another.
> >
> > I just don’t see how we can provide an installer from Apache that bundles
> > both NetBeans and JDK, whatever that JDK is, but (unless AdoptOpenJDK
> makes
> > such a bundle prominently and stably available) that doesn’t mean we
> should
> > not try to make even a flawed installer available, i.e., without the JDK,
> > which is a lot better than nothing.
> >
> > Gj
> >
> > On Thu, 28 Nov 2019 at 18:08, Laszlo Kishalmi  >
> > wrote:
> >
> >> Just adding some info:
> >>
> >> It is not just about the JDK, but JDK, nb-javac and probably a fitting
> >> JavaFX runtime.
> >>
> >> If someone can bundle those up and provide an installer most probably
> >> based on the installer code we have, then that would be the best end
> >> user experience, like in the old days when we said NetBeans just works.
> >>
> >> Separate distributions, like OpenBeans, would eventually emerge.
> >>
> >> It is just a question of what would be better for the brand. Keeping our
> >> "crippled" installers and/or offer additional install experience from
> >> third parties.
> >>
> >> On 11/28/19 8:49 AM, Kirk Pepperdine wrote:
> >>> Hi all,
> >>>
> >>> Again, I believe that you could distribute from Adopt with a JDK
> >> bundled. So maybe this is a case where using a 3rd party makes sense.
> >>> Kind regards,
> >>> Kirk
> >>>
> >>>
>  On Nov 28, 2019, at 8:45 AM, Kenneth Fogel <
> kfo...@dawsoncollege.qc.ca>
> >> wrote:
>  I apologize if I misunderstood but the conversation appeared to me,
> >> likely incorrectly, to go beyond just bundling a Java JDK. The
> installers
> >> that are already there, are they downloading a JDK if one is not
> present?
> >> Requiring a separate install of Java is the status quo. If we could make
> >> that part of the NetBeans installer then we should an we should pursue
> an
> >> exemption to Apache policies if required.
>  Ken
> 
> 
>  -Original Message-
>  From: Geertjan Wielenga 
>  Sent: November 28, 2019 11:30 AM
>  To: dev@netbeans.apache.org
>  Subject: Re: [DISCUSS] Dropping Installers from the Release Process
> >> leave that work to Third Party Distributors
>  You’re aware that we’re already distributing an installer, right? And
> >> that that is not what we’re talking about?
>  We’re talking about the fact that we can’t bundle the JDK with that
> >> installer and then distribute that installer from Apache.
>  A simple link on our download page to OpenBeans and AdoptOpenJDK and
> >> any other distributor is all we need, for the installers of NetBeans
> that
> >> bundle the JDK.
>  Gj
> 
> 
>  On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel <
> kfo...@dawsoncollege.qc.ca
>  wrote:
> 
> > This is a bad idea. I personally feel that an installer is mandatory.
> > Eclipse and IntelliJ have installers for all platforms. Leaving it to
> > third parties will mean that we have no oversight on the quality and
> > ease of use of the installer. Only distributing a zip file implies
> > that skills beyond learning to code with NetBeans will be required.
> We
> > can pretty much write off the education sector if there is no
> > installer. Sorry to be harsh but this is a line I believe we must not
> >> cross.
> > It is unfortunates, as someone has pointed out, that Apache is not
> end
> > user friendly but that is no excuse. NetBeans is an end user program
> > and must be as easy to install as any other IDE and have an official
> >> installer.
> > Ken
> >
> >
> > -Original Message-
> > From: Laszlo Kishalmi 
> > Sent: November 27, 2019 2:41 PM
> > To: Apache NetBeans 
> > Subject: [DISCUSS] Dropping Installers from the Release Process leave
> > that work to Third Party Distributors
> >
> > Dear all,
> >
> > It is a great burden to us to provide the best out-of-the-box install
> > experience with NetBeans. That would mean, providing an installer
> with
> > JDK, nb-javac probably javafx.
> >
> > See the threads:
> >
> >
> >
> https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
> > 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Ernie Rael]

Is it possible, and legal, to put an install bundle on github and point 
to it?


-ernie

On 11/28/2019 9:23 AM, Geertjan Wielenga wrote:

Just note that nb-javac won’t be with us forever, work is being done to
remove our need for it. Once that is done, we’ll be in a really good state.

In the meantime, as well as atter that, we should do everything we can to
work with Kirk and anyone else to provide a bundle of their JDK with
NetBeans.

Our installer, in whatever way we provide it, will be problematic in one
way or another.

I just don’t see how we can provide an installer from Apache that bundles
both NetBeans and JDK, whatever that JDK is, but (unless AdoptOpenJDK makes
such a bundle prominently and stably available) that doesn’t mean we should
not try to make even a flawed installer available, i.e., without the JDK,
which is a lot better than nothing.

Gj

On Thu, 28 Nov 2019 at 18:08, Laszlo Kishalmi 
wrote:


Just adding some info:

It is not just about the JDK, but JDK, nb-javac and probably a fitting
JavaFX runtime.

If someone can bundle those up and provide an installer most probably
based on the installer code we have, then that would be the best end
user experience, like in the old days when we said NetBeans just works.

Separate distributions, like OpenBeans, would eventually emerge.

It is just a question of what would be better for the brand. Keeping our
"crippled" installers and/or offer additional install experience from
third parties.

On 11/28/19 8:49 AM, Kirk Pepperdine wrote:

Hi all,

Again, I believe that you could distribute from Adopt with a JDK

bundled. So maybe this is a case where using a 3rd party makes sense.

Kind regards,
Kirk



On Nov 28, 2019, at 8:45 AM, Kenneth Fogel 

wrote:

I apologize if I misunderstood but the conversation appeared to me,

likely incorrectly, to go beyond just bundling a Java JDK. The installers
that are already there, are they downloading a JDK if one is not present?
Requiring a separate install of Java is the status quo. If we could make
that part of the NetBeans installer then we should an we should pursue an
exemption to Apache policies if required.

Ken


-Original Message-
From: Geertjan Wielenga 
Sent: November 28, 2019 11:30 AM
To: dev@netbeans.apache.org
Subject: Re: [DISCUSS] Dropping Installers from the Release Process

leave that work to Third Party Distributors

You’re aware that we’re already distributing an installer, right? And

that that is not what we’re talking about?

We’re talking about the fact that we can’t bundle the JDK with that

installer and then distribute that installer from Apache.

A simple link on our download page to OpenBeans and AdoptOpenJDK and

any other distributor is all we need, for the installers of NetBeans that
bundle the JDK.

Gj


On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel 
This is a bad idea. I personally feel that an installer is mandatory.
Eclipse and IntelliJ have installers for all platforms. Leaving it to
third parties will mean that we have no oversight on the quality and
ease of use of the installer. Only distributing a zip file implies
that skills beyond learning to code with NetBeans will be required. We
can pretty much write off the education sector if there is no
installer. Sorry to be harsh but this is a line I believe we must not

cross.

It is unfortunates, as someone has pointed out, that Apache is not end
user friendly but that is no excuse. NetBeans is an end user program
and must be as easy to install as any other IDE and have an official

installer.

Ken


-Original Message-
From: Laszlo Kishalmi 
Sent: November 27, 2019 2:41 PM
To: Apache NetBeans 
Subject: [DISCUSS] Dropping Installers from the Release Process leave
that work to Third Party Distributors

Dear all,

It is a great burden to us to provide the best out-of-the-box install
experience with NetBeans. That would mean, providing an installer with
JDK, nb-javac probably javafx.

See the threads:


https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E


https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E

On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:

Dear all,

I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
with Apache NetBeans.

There are mainly two readings of GPL+CPE:

1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
 distributed under Apache license, due to CPE  2. CPE only allows
other product built on Java to be distributed
 under their own license.

As I'm not a lawyer, I cannot answer which interpretation is correct
(maybe none of them). ASF has every right to regard the second
interpretation, thus GPL+CPE ended up in the Category-X licenses.

The following viable possibilities were brought up:

1. We may apply for an exception to the board  2. Use some download
logic in the installer.
3. Leave the binary 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Ernie Rael]

It's not clear to me who would be putting together this bundle. The 
apache NB team or Adopt?


-ernie

On 11/28/2019 8:56 AM, Geertjan Wielenga wrote:

If we have AdoptOpenJDK officially providing a bundle together with
NetBeans, then I think we should consider not providing an installer at all
— and just make the convenience binary available as a ZIP and point to
AdoptOpenJDK and OpenBeans and any other bundlers/distributors.

Gj



On Thu, 28 Nov 2019 at 17:53, Geertjan Wielenga  wrote:


Excellent news, Kirk.

How do we get this done?

Gj

On Thu, 28 Nov 2019 at 17:49, Kirk Pepperdine  wrote:


Hi all,

Again, I believe that you could distribute from Adopt with a JDK bundled.
So maybe this is a case where using a 3rd party makes sense.

Kind regards,
Kirk



On Nov 28, 2019, at 8:45 AM, Kenneth Fogel 

wrote:

I apologize if I misunderstood but the conversation appeared to me,

likely incorrectly, to go beyond just bundling a Java JDK. The installers
that are already there, are they downloading a JDK if one is not present?
Requiring a separate install of Java is the status quo. If we could make
that part of the NetBeans installer then we should an we should pursue an
exemption to Apache policies if required.

Ken


-Original Message-
From: Geertjan Wielenga 
Sent: November 28, 2019 11:30 AM
To: dev@netbeans.apache.org
Subject: Re: [DISCUSS] Dropping Installers from the Release Process

leave that work to Third Party Distributors

You’re aware that we’re already distributing an installer, right? And

that that is not what we’re talking about?

We’re talking about the fact that we can’t bundle the JDK with that

installer and then distribute that installer from Apache.

A simple link on our download page to OpenBeans and AdoptOpenJDK and

any other distributor is all we need, for the installers of NetBeans that
bundle the JDK.

Gj


On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel 
This is a bad idea. I personally feel that an installer is mandatory.
Eclipse and IntelliJ have installers for all platforms. Leaving it to
third parties will mean that we have no oversight on the quality and
ease of use of the installer. Only distributing a zip file implies
that skills beyond learning to code with NetBeans will be required. We
can pretty much write off the education sector if there is no
installer. Sorry to be harsh but this is a line I believe we must not

cross.

It is unfortunates, as someone has pointed out, that Apache is not end
user friendly but that is no excuse. NetBeans is an end user program
and must be as easy to install as any other IDE and have an official

installer.

Ken


-Original Message-
From: Laszlo Kishalmi 
Sent: November 27, 2019 2:41 PM
To: Apache NetBeans 
Subject: [DISCUSS] Dropping Installers from the Release Process leave
that work to Third Party Distributors

Dear all,

It is a great burden to us to provide the best out-of-the-box install
experience with NetBeans. That would mean, providing an installer with
JDK, nb-javac probably javafx.

See the threads:


https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E


https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E

On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:

Dear all,

I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
with Apache NetBeans.

There are mainly two readings of GPL+CPE:

1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
distributed under Apache license, due to CPE  2. CPE only allows
other product built on Java to be distributed
under their own license.

As I'm not a lawyer, I cannot answer which interpretation is correct
(maybe none of them). ASF has every right to regard the second
interpretation, thus GPL+CPE ended up in the Category-X licenses.

The following viable possibilities were brought up:

1. We may apply for an exception to the board  2. Use some download
logic in the installer.
3. Leave the binary packaging and distribution to third parties.

Regarding that there are interest from third parties to built on
Apache NetBeans, I'm going to recommend the PMC to select a few
distributor for creating installer packages and we limit/drop our
installer bundle creation in the future.

Thank you,

Laszlo Kishalmi


I do not think that after this discussion we would get the exception
from the board Geertjan might try to bring it up there as well.

As of me option 2 is questionable.

Option 3. is a bit hard to say, but if we can't produce proper
installation packages, it would probably better to not create those
packages at all, leave that for others.

How I imagine that:

1.  From 11.3 we remove the convenience binaries and installers from
our download page
2. We would still create, sign and host our nbm-s.
3. On our download page we have the source package and a section for
third party distributors.

Well of 

Re: Issue with Gradle projects - requires manual delete of .nb-gradle folder

[Scott Palmer]

Yes, I know it can be hard to track down.
Is there something I can do to collect useful information if it happens again?

Scott

> On Nov 28, 2019, at 3:14 PM, Laszlo Kishalmi  
> wrote:
> 
> Issues like these are really hard to tackle. Most likely some cache files 
> got corrupted.
> 
> FYI the default Gradle implementation does not use .nb-gradle folder we put 
> our cached things under .gradle.
> 
> BTW deleting .gradle directory is safe you just removed the corrupted cached 
> content.
> 
>> On 11/28/19 12:01 PM, Scott Palmer wrote:
>> [Testing with 11.2-u1 nbms installed from the binaries recently posted...]
>> 
>> Many imports in the project source are erroneously showing errors like this:
>> 
>> cannot access NativeComponent
>>   bad class file: NativeComponent.class
>> illegal start of class file
>> Please remove or make sure it appears in the correct subdirectory of
>> the classpath.
>> 
>> (Alt-Enter shows hints)
>> 
>> The jars where these classes live is listed correctly in the project tree
>> under Configurations/compile/Local Files/.  I can expand the jar in that
>> view and see it has the correct entries of the classes that fail to import.
>> 
>> When I first noticed this problem I modified my build.gradle file to
>> trigger re-initialization of the project in question.   That didn't help.
>> 
>> messages.log is full of this:
>> 
>> INFO [org.netbeans.api.java.source.ElementHandle]: Cannot resolve:
>> ElementHandle[kind=CLASS;
>> sigs=ca.digitalrapids.kayak.graph.impl.KayakNodeImpl_V2 ]
>> INFO [org.netbeans.api.java.source.ElementHandle]: Resolved type is null
>> for kind = INTERFACE
>> 
>> Repeated for hundreds of classes.
>> 
>> I also see this:
>> 
>> INFO [org.netbeans.core.startup.layers.ArchiveURLMapper]: fo:
>> MIMESupport$CachedFileObject@7ee9774c[[Content_Types].xml] archiveFile:
>> C:\dev\\Dev-instructions.docx
>> java.net.URISyntaxException: Illegal character in path at index 0:
>> [Content_Types].xml
>> at java.net.URI$Parser.fail(URI.java:2848)
>> at java.net.URI$Parser.checkChars(URI.java:3021)
>> at java.net.URI$Parser.parseHierarchical(URI.java:3105)
>> at java.net.URI$Parser.parse(URI.java:3063)
>> at java.net.URI.(URI.java:820)
>> [catch] at
>> org.netbeans.core.startup.layers.ArchiveURLMapper.getURL(ArchiveURLMapper.java:76)
>> at org.openide.filesystems.URLMapper.findURL(URLMapper.java:115)
>> at org.openide.filesystems.FileObject.toURL(FileObject.java:1216)
>> at
>> org.netbeans.modules.openide.filesystems.declmime.DefaultParser.parse(DefaultParser.java:117)
>> at
>> org.netbeans.modules.openide.filesystems.declmime.XMLMIMEComponent$SniffingParser.sniff(XMLMIMEComponent.java:267)
>> at
>> org.netbeans.modules.openide.filesystems.declmime.XMLMIMEComponent.acceptFileObject(XMLMIMEComponent.java:81)
>> at
>> org.netbeans.modules.openide.filesystems.declmime.FileElement.resolve(FileElement.java:77)
>> at
>> org.netbeans.modules.openide.filesystems.declmime.MIMEResolverImpl$Impl.findMIMEType(MIMEResolverImpl.java:425)
>> at
>> org.openide.filesystems.MIMESupport$CachedFileObject.resolveMIME(MIMESupport.java:346)
>> at
>> org.openide.filesystems.MIMESupport$CachedFileObject.getMIMEType(MIMESupport.java:287)
>> at org.openide.filesystems.MIMESupport.findMIMEType(MIMESupport.java:111)
>> at org.openide.filesystems.FileUtil.getMIMEType(FileUtil.java:1297)
>> at org.openide.filesystems.FileObject.getMIMEType(FileObject.java:642)
>> at
>> org.openide.filesystems.AbstractFileObject.getMIMEType(AbstractFileObject.java:169)
>> at org.openide.loaders.DataLoaderPool.allLoaders(DataLoaderPool.java:307)
>> at
>> org.openide.loaders.DataLoaderPool.findDataObject(DataLoaderPool.java:505)
>> at org.openide.loaders.FolderList.createBoth(FolderList.java:743)
>> at org.openide.loaders.FolderList.getObjects(FolderList.java:539)
>> at org.openide.loaders.FolderList.access$600(FolderList.java:52)
>> at
>> org.openide.loaders.FolderList$ListTask.computeResult(FolderList.java:938)
>> at org.openide.loaders.FolderList$ListTask.run(FolderList.java:914)
>> at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
>> at
>> org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
>> at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
>> at
>> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
>> 
>> I'm not sure why NB is looking at a .docx file at all, it is in the root of
>> a project folder for one of the libraries that my project with the import
>> problems uses, both projects are open in NB.  That file is not on the
>> classpath of either project.
>> 
>> I re-built the library project from the command line a few times, so the
>> jar would have disappeared and re-appeared.
>> 
>> I also see this earlier in the messages.log, but I'm not sure when it
>> happened (Can we get timestamps for the log entries??)
>> 
>> WARNING [org.openide.filesystems.JarFileSystem]: cannot open
>> C:\dev\\Thing.jar
>> WARNING [null]: 

Re: Issue with Gradle projects - requires manual delete of .nb-gradle folder

[Laszlo Kishalmi]

Issues like these are really hard to tackle. Most likely some cache 
files got corrupted.


FYI the default Gradle implementation does not use .nb-gradle folder we 
put our cached things under .gradle.


BTW deleting .gradle directory is safe you just removed the corrupted 
cached content.


On 11/28/19 12:01 PM, Scott Palmer wrote:

[Testing with 11.2-u1 nbms installed from the binaries recently posted...]

Many imports in the project source are erroneously showing errors like this:

cannot access NativeComponent
   bad class file: NativeComponent.class
 illegal start of class file
 Please remove or make sure it appears in the correct subdirectory of
the classpath.

(Alt-Enter shows hints)

The jars where these classes live is listed correctly in the project tree
under Configurations/compile/Local Files/.  I can expand the jar in that
view and see it has the correct entries of the classes that fail to import.

When I first noticed this problem I modified my build.gradle file to
trigger re-initialization of the project in question.   That didn't help.

messages.log is full of this:

INFO [org.netbeans.api.java.source.ElementHandle]: Cannot resolve:
ElementHandle[kind=CLASS;
sigs=ca.digitalrapids.kayak.graph.impl.KayakNodeImpl_V2 ]
INFO [org.netbeans.api.java.source.ElementHandle]: Resolved type is null
for kind = INTERFACE

Repeated for hundreds of classes.

I also see this:

INFO [org.netbeans.core.startup.layers.ArchiveURLMapper]: fo:
MIMESupport$CachedFileObject@7ee9774c[[Content_Types].xml] archiveFile:
C:\dev\\Dev-instructions.docx
java.net.URISyntaxException: Illegal character in path at index 0:
[Content_Types].xml
at java.net.URI$Parser.fail(URI.java:2848)
at java.net.URI$Parser.checkChars(URI.java:3021)
at java.net.URI$Parser.parseHierarchical(URI.java:3105)
at java.net.URI$Parser.parse(URI.java:3063)
at java.net.URI.(URI.java:820)
[catch] at
org.netbeans.core.startup.layers.ArchiveURLMapper.getURL(ArchiveURLMapper.java:76)
at org.openide.filesystems.URLMapper.findURL(URLMapper.java:115)
at org.openide.filesystems.FileObject.toURL(FileObject.java:1216)
at
org.netbeans.modules.openide.filesystems.declmime.DefaultParser.parse(DefaultParser.java:117)
at
org.netbeans.modules.openide.filesystems.declmime.XMLMIMEComponent$SniffingParser.sniff(XMLMIMEComponent.java:267)
at
org.netbeans.modules.openide.filesystems.declmime.XMLMIMEComponent.acceptFileObject(XMLMIMEComponent.java:81)
at
org.netbeans.modules.openide.filesystems.declmime.FileElement.resolve(FileElement.java:77)
at
org.netbeans.modules.openide.filesystems.declmime.MIMEResolverImpl$Impl.findMIMEType(MIMEResolverImpl.java:425)
at
org.openide.filesystems.MIMESupport$CachedFileObject.resolveMIME(MIMESupport.java:346)
at
org.openide.filesystems.MIMESupport$CachedFileObject.getMIMEType(MIMESupport.java:287)
at org.openide.filesystems.MIMESupport.findMIMEType(MIMESupport.java:111)
at org.openide.filesystems.FileUtil.getMIMEType(FileUtil.java:1297)
at org.openide.filesystems.FileObject.getMIMEType(FileObject.java:642)
at
org.openide.filesystems.AbstractFileObject.getMIMEType(AbstractFileObject.java:169)
at org.openide.loaders.DataLoaderPool.allLoaders(DataLoaderPool.java:307)
at
org.openide.loaders.DataLoaderPool.findDataObject(DataLoaderPool.java:505)
at org.openide.loaders.FolderList.createBoth(FolderList.java:743)
at org.openide.loaders.FolderList.getObjects(FolderList.java:539)
at org.openide.loaders.FolderList.access$600(FolderList.java:52)
at
org.openide.loaders.FolderList$ListTask.computeResult(FolderList.java:938)
at org.openide.loaders.FolderList$ListTask.run(FolderList.java:914)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)

I'm not sure why NB is looking at a .docx file at all, it is in the root of
a project folder for one of the libraries that my project with the import
problems uses, both projects are open in NB.  That file is not on the
classpath of either project.

I re-built the library project from the command line a few times, so the
jar would have disappeared and re-appeared.

I also see this earlier in the messages.log, but I'm not sure when it
happened (Can we get timestamps for the log entries??)

WARNING [org.openide.filesystems.JarFileSystem]: cannot open
C:\dev\\Thing.jar
WARNING [null]: Last record repeated again.

That is repeated for every jar mentioned in the manifest of Thing.jar as
well.  Funny, if you can't read the jar file how do you know about all the
jars in it's manifest???

I restart NetBeans and even though none of the above issues show in
messages.log on after restart, the problem remains.

There is one exception in the log preceeded by many many lines of
whitespace:

INFO [org.netbeans.modules.masterfs.watcher.Watcher]: Exception

Issue with Gradle projects - requires manual delete of .nb-gradle folder

[Scott Palmer]

[Testing with 11.2-u1 nbms installed from the binaries recently posted...]

Many imports in the project source are erroneously showing errors like this:

cannot access NativeComponent
  bad class file: NativeComponent.class
illegal start of class file
Please remove or make sure it appears in the correct subdirectory of
the classpath.

(Alt-Enter shows hints)

The jars where these classes live is listed correctly in the project tree
under Configurations/compile/Local Files/.  I can expand the jar in that
view and see it has the correct entries of the classes that fail to import.

When I first noticed this problem I modified my build.gradle file to
trigger re-initialization of the project in question.   That didn't help.

messages.log is full of this:

INFO [org.netbeans.api.java.source.ElementHandle]: Cannot resolve:
ElementHandle[kind=CLASS;
sigs=ca.digitalrapids.kayak.graph.impl.KayakNodeImpl_V2 ]
INFO [org.netbeans.api.java.source.ElementHandle]: Resolved type is null
for kind = INTERFACE

Repeated for hundreds of classes.

I also see this:

INFO [org.netbeans.core.startup.layers.ArchiveURLMapper]: fo:
MIMESupport$CachedFileObject@7ee9774c[[Content_Types].xml] archiveFile:
C:\dev\\Dev-instructions.docx
java.net.URISyntaxException: Illegal character in path at index 0:
[Content_Types].xml
at java.net.URI$Parser.fail(URI.java:2848)
at java.net.URI$Parser.checkChars(URI.java:3021)
at java.net.URI$Parser.parseHierarchical(URI.java:3105)
at java.net.URI$Parser.parse(URI.java:3063)
at java.net.URI.(URI.java:820)
[catch] at
org.netbeans.core.startup.layers.ArchiveURLMapper.getURL(ArchiveURLMapper.java:76)
at org.openide.filesystems.URLMapper.findURL(URLMapper.java:115)
at org.openide.filesystems.FileObject.toURL(FileObject.java:1216)
at
org.netbeans.modules.openide.filesystems.declmime.DefaultParser.parse(DefaultParser.java:117)
at
org.netbeans.modules.openide.filesystems.declmime.XMLMIMEComponent$SniffingParser.sniff(XMLMIMEComponent.java:267)
at
org.netbeans.modules.openide.filesystems.declmime.XMLMIMEComponent.acceptFileObject(XMLMIMEComponent.java:81)
at
org.netbeans.modules.openide.filesystems.declmime.FileElement.resolve(FileElement.java:77)
at
org.netbeans.modules.openide.filesystems.declmime.MIMEResolverImpl$Impl.findMIMEType(MIMEResolverImpl.java:425)
at
org.openide.filesystems.MIMESupport$CachedFileObject.resolveMIME(MIMESupport.java:346)
at
org.openide.filesystems.MIMESupport$CachedFileObject.getMIMEType(MIMESupport.java:287)
at org.openide.filesystems.MIMESupport.findMIMEType(MIMESupport.java:111)
at org.openide.filesystems.FileUtil.getMIMEType(FileUtil.java:1297)
at org.openide.filesystems.FileObject.getMIMEType(FileObject.java:642)
at
org.openide.filesystems.AbstractFileObject.getMIMEType(AbstractFileObject.java:169)
at org.openide.loaders.DataLoaderPool.allLoaders(DataLoaderPool.java:307)
at
org.openide.loaders.DataLoaderPool.findDataObject(DataLoaderPool.java:505)
at org.openide.loaders.FolderList.createBoth(FolderList.java:743)
at org.openide.loaders.FolderList.getObjects(FolderList.java:539)
at org.openide.loaders.FolderList.access$600(FolderList.java:52)
at
org.openide.loaders.FolderList$ListTask.computeResult(FolderList.java:938)
at org.openide.loaders.FolderList$ListTask.run(FolderList.java:914)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)

I'm not sure why NB is looking at a .docx file at all, it is in the root of
a project folder for one of the libraries that my project with the import
problems uses, both projects are open in NB.  That file is not on the
classpath of either project.

I re-built the library project from the command line a few times, so the
jar would have disappeared and re-appeared.

I also see this earlier in the messages.log, but I'm not sure when it
happened (Can we get timestamps for the log entries??)

WARNING [org.openide.filesystems.JarFileSystem]: cannot open
C:\dev\\Thing.jar
WARNING [null]: Last record repeated again.

That is repeated for every jar mentioned in the manifest of Thing.jar as
well.  Funny, if you can't read the jar file how do you know about all the
jars in it's manifest???

I restart NetBeans and even though none of the above issues show in
messages.log on after restart, the problem remains.

There is one exception in the log preceeded by many many lines of
whitespace:

INFO [org.netbeans.modules.masterfs.watcher.Watcher]: Exception
java.nio.file.ClosedWatchServiceException
at sun.nio.fs.AbstractPoller.invoke(AbstractPoller.java:216)
at sun.nio.fs.AbstractPoller.cancel(AbstractPoller.java:133)
at
sun.nio.fs.WindowsWatchService$WindowsWatchKey.cancel(WindowsWatchService.java:209)
at
org.netbeans.modules.masterfs.watcher.nio2.NioNotifier.removeWatch(NioNotifier.java:62)
Caused: 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Geertjan Wielenga]

Hey Kirk,

Well, on this side we’re ready to move forward, just tell us what we need
to do to proceed.

Looking forward to this happening,

Gj

On Thu, 28 Nov 2019 at 18:43, Kirk Pepperdine  wrote:

> Hi Geertjan,
>
> I can’t personally speak for adopt but my understanding from previous
> conversation was Adopt was amicable to this. I think the only issue is man
> power to get it done.
>
> Kind regards,
> Kirk
>
>
> > On Nov 28, 2019, at 8:56 AM, Geertjan Wielenga 
> wrote:
> >
> > If we have AdoptOpenJDK officially providing a bundle together with
> > NetBeans, then I think we should consider not providing an installer at
> all
> > — and just make the convenience binary available as a ZIP and point to
> > AdoptOpenJDK and OpenBeans and any other bundlers/distributors.
> >
> > Gj
> >
> >
> >
> > On Thu, 28 Nov 2019 at 17:53, Geertjan Wielenga 
> wrote:
> >
> >>
> >> Excellent news, Kirk.
> >>
> >> How do we get this done?
> >>
> >> Gj
> >>
> >> On Thu, 28 Nov 2019 at 17:49, Kirk Pepperdine 
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> Again, I believe that you could distribute from Adopt with a JDK
> bundled.
> >>> So maybe this is a case where using a 3rd party makes sense.
> >>>
> >>> Kind regards,
> >>> Kirk
> >>>
> >>>
>  On Nov 28, 2019, at 8:45 AM, Kenneth Fogel <
> kfo...@dawsoncollege.qc.ca>
> >>> wrote:
> 
>  I apologize if I misunderstood but the conversation appeared to me,
> >>> likely incorrectly, to go beyond just bundling a Java JDK. The
> installers
> >>> that are already there, are they downloading a JDK if one is not
> present?
> >>> Requiring a separate install of Java is the status quo. If we could
> make
> >>> that part of the NetBeans installer then we should an we should pursue
> an
> >>> exemption to Apache policies if required.
> 
>  Ken
> 
> 
>  -Original Message-
>  From: Geertjan Wielenga 
>  Sent: November 28, 2019 11:30 AM
>  To: dev@netbeans.apache.org
>  Subject: Re: [DISCUSS] Dropping Installers from the Release Process
> >>> leave that work to Third Party Distributors
> 
>  You’re aware that we’re already distributing an installer, right? And
> >>> that that is not what we’re talking about?
> 
>  We’re talking about the fact that we can’t bundle the JDK with that
> >>> installer and then distribute that installer from Apache.
> 
>  A simple link on our download page to OpenBeans and AdoptOpenJDK and
> >>> any other distributor is all we need, for the installers of NetBeans
> that
> >>> bundle the JDK.
> 
>  Gj
> 
> 
>  On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel <
> kfo...@dawsoncollege.qc.ca
> 
>  wrote:
> 
> > This is a bad idea. I personally feel that an installer is mandatory.
> > Eclipse and IntelliJ have installers for all platforms. Leaving it to
> > third parties will mean that we have no oversight on the quality and
> > ease of use of the installer. Only distributing a zip file implies
> > that skills beyond learning to code with NetBeans will be required.
> We
> > can pretty much write off the education sector if there is no
> > installer. Sorry to be harsh but this is a line I believe we must not
> >>> cross.
> >
> > It is unfortunates, as someone has pointed out, that Apache is not
> end
> > user friendly but that is no excuse. NetBeans is an end user program
> > and must be as easy to install as any other IDE and have an official
> >>> installer.
> >
> > Ken
> >
> >
> > -Original Message-
> > From: Laszlo Kishalmi 
> > Sent: November 27, 2019 2:41 PM
> > To: Apache NetBeans 
> > Subject: [DISCUSS] Dropping Installers from the Release Process leave
> > that work to Third Party Distributors
> >
> > Dear all,
> >
> > It is a great burden to us to provide the best out-of-the-box install
> > experience with NetBeans. That would mean, providing an installer
> with
> > JDK, nb-javac probably javafx.
> >
> > See the threads:
> >
> >
> >
> https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
> > d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E
> >
> >
> >
> https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
> > a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E
> >
> > On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
> >>
> >> Dear all,
> >>
> >> I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
> >> with Apache NetBeans.
> >>
> >> There are mainly two readings of GPL+CPE:
> >>
> >> 1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
> >>   distributed under Apache license, due to CPE  2. CPE only allows
> >> other product built on Java to be distributed
> >>   under their own license.
> >>
> >> As I'm not a lawyer, I cannot answer which interpretation is correct
> >> 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Kirk Pepperdine]

Hi Geertjan,

I can’t personally speak for adopt but my understanding from previous 
conversation was Adopt was amicable to this. I think the only issue is man 
power to get it done.

Kind regards,
Kirk


> On Nov 28, 2019, at 8:56 AM, Geertjan Wielenga  wrote:
> 
> If we have AdoptOpenJDK officially providing a bundle together with
> NetBeans, then I think we should consider not providing an installer at all
> — and just make the convenience binary available as a ZIP and point to
> AdoptOpenJDK and OpenBeans and any other bundlers/distributors.
> 
> Gj
> 
> 
> 
> On Thu, 28 Nov 2019 at 17:53, Geertjan Wielenga  wrote:
> 
>> 
>> Excellent news, Kirk.
>> 
>> How do we get this done?
>> 
>> Gj
>> 
>> On Thu, 28 Nov 2019 at 17:49, Kirk Pepperdine  wrote:
>> 
>>> Hi all,
>>> 
>>> Again, I believe that you could distribute from Adopt with a JDK bundled.
>>> So maybe this is a case where using a 3rd party makes sense.
>>> 
>>> Kind regards,
>>> Kirk
>>> 
>>> 
 On Nov 28, 2019, at 8:45 AM, Kenneth Fogel 
>>> wrote:
 
 I apologize if I misunderstood but the conversation appeared to me,
>>> likely incorrectly, to go beyond just bundling a Java JDK. The installers
>>> that are already there, are they downloading a JDK if one is not present?
>>> Requiring a separate install of Java is the status quo. If we could make
>>> that part of the NetBeans installer then we should an we should pursue an
>>> exemption to Apache policies if required.
 
 Ken
 
 
 -Original Message-
 From: Geertjan Wielenga 
 Sent: November 28, 2019 11:30 AM
 To: dev@netbeans.apache.org
 Subject: Re: [DISCUSS] Dropping Installers from the Release Process
>>> leave that work to Third Party Distributors
 
 You’re aware that we’re already distributing an installer, right? And
>>> that that is not what we’re talking about?
 
 We’re talking about the fact that we can’t bundle the JDK with that
>>> installer and then distribute that installer from Apache.
 
 A simple link on our download page to OpenBeans and AdoptOpenJDK and
>>> any other distributor is all we need, for the installers of NetBeans that
>>> bundle the JDK.
 
 Gj
 
 
 On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel >>> 
 wrote:
 
> This is a bad idea. I personally feel that an installer is mandatory.
> Eclipse and IntelliJ have installers for all platforms. Leaving it to
> third parties will mean that we have no oversight on the quality and
> ease of use of the installer. Only distributing a zip file implies
> that skills beyond learning to code with NetBeans will be required. We
> can pretty much write off the education sector if there is no
> installer. Sorry to be harsh but this is a line I believe we must not
>>> cross.
> 
> It is unfortunates, as someone has pointed out, that Apache is not end
> user friendly but that is no excuse. NetBeans is an end user program
> and must be as easy to install as any other IDE and have an official
>>> installer.
> 
> Ken
> 
> 
> -Original Message-
> From: Laszlo Kishalmi 
> Sent: November 27, 2019 2:41 PM
> To: Apache NetBeans 
> Subject: [DISCUSS] Dropping Installers from the Release Process leave
> that work to Third Party Distributors
> 
> Dear all,
> 
> It is a great burden to us to provide the best out-of-the-box install
> experience with NetBeans. That would mean, providing an installer with
> JDK, nb-javac probably javafx.
> 
> See the threads:
> 
> 
> https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
> d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E
> 
> 
> https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
> a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E
> 
> On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
>> 
>> Dear all,
>> 
>> I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
>> with Apache NetBeans.
>> 
>> There are mainly two readings of GPL+CPE:
>> 
>> 1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
>>   distributed under Apache license, due to CPE  2. CPE only allows
>> other product built on Java to be distributed
>>   under their own license.
>> 
>> As I'm not a lawyer, I cannot answer which interpretation is correct
>> (maybe none of them). ASF has every right to regard the second
>> interpretation, thus GPL+CPE ended up in the Category-X licenses.
>> 
>> The following viable possibilities were brought up:
>> 
>> 1. We may apply for an exception to the board  2. Use some download
>> logic in the installer.
>> 3. Leave the binary packaging and distribution to third parties.
>> 
>> Regarding that there are interest from third parties to built on
>> Apache NetBeans, I'm going to 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Geertjan Wielenga]

Just note that nb-javac won’t be with us forever, work is being done to
remove our need for it. Once that is done, we’ll be in a really good state.

In the meantime, as well as atter that, we should do everything we can to
work with Kirk and anyone else to provide a bundle of their JDK with
NetBeans.

Our installer, in whatever way we provide it, will be problematic in one
way or another.

I just don’t see how we can provide an installer from Apache that bundles
both NetBeans and JDK, whatever that JDK is, but (unless AdoptOpenJDK makes
such a bundle prominently and stably available) that doesn’t mean we should
not try to make even a flawed installer available, i.e., without the JDK,
which is a lot better than nothing.

Gj

On Thu, 28 Nov 2019 at 18:08, Laszlo Kishalmi 
wrote:

> Just adding some info:
>
> It is not just about the JDK, but JDK, nb-javac and probably a fitting
> JavaFX runtime.
>
> If someone can bundle those up and provide an installer most probably
> based on the installer code we have, then that would be the best end
> user experience, like in the old days when we said NetBeans just works.
>
> Separate distributions, like OpenBeans, would eventually emerge.
>
> It is just a question of what would be better for the brand. Keeping our
> "crippled" installers and/or offer additional install experience from
> third parties.
>
> On 11/28/19 8:49 AM, Kirk Pepperdine wrote:
> > Hi all,
> >
> > Again, I believe that you could distribute from Adopt with a JDK
> bundled. So maybe this is a case where using a 3rd party makes sense.
> >
> > Kind regards,
> > Kirk
> >
> >
> >> On Nov 28, 2019, at 8:45 AM, Kenneth Fogel 
> wrote:
> >>
> >> I apologize if I misunderstood but the conversation appeared to me,
> likely incorrectly, to go beyond just bundling a Java JDK. The installers
> that are already there, are they downloading a JDK if one is not present?
> Requiring a separate install of Java is the status quo. If we could make
> that part of the NetBeans installer then we should an we should pursue an
> exemption to Apache policies if required.
> >>
> >> Ken
> >>
> >>
> >> -Original Message-
> >> From: Geertjan Wielenga 
> >> Sent: November 28, 2019 11:30 AM
> >> To: dev@netbeans.apache.org
> >> Subject: Re: [DISCUSS] Dropping Installers from the Release Process
> leave that work to Third Party Distributors
> >>
> >> You’re aware that we’re already distributing an installer, right? And
> that that is not what we’re talking about?
> >>
> >> We’re talking about the fact that we can’t bundle the JDK with that
> installer and then distribute that installer from Apache.
> >>
> >> A simple link on our download page to OpenBeans and AdoptOpenJDK and
> any other distributor is all we need, for the installers of NetBeans that
> bundle the JDK.
> >>
> >> Gj
> >>
> >>
> >> On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel  >
> >> wrote:
> >>
> >>> This is a bad idea. I personally feel that an installer is mandatory.
> >>> Eclipse and IntelliJ have installers for all platforms. Leaving it to
> >>> third parties will mean that we have no oversight on the quality and
> >>> ease of use of the installer. Only distributing a zip file implies
> >>> that skills beyond learning to code with NetBeans will be required. We
> >>> can pretty much write off the education sector if there is no
> >>> installer. Sorry to be harsh but this is a line I believe we must not
> cross.
> >>>
> >>> It is unfortunates, as someone has pointed out, that Apache is not end
> >>> user friendly but that is no excuse. NetBeans is an end user program
> >>> and must be as easy to install as any other IDE and have an official
> installer.
> >>>
> >>> Ken
> >>>
> >>>
> >>> -Original Message-
> >>> From: Laszlo Kishalmi 
> >>> Sent: November 27, 2019 2:41 PM
> >>> To: Apache NetBeans 
> >>> Subject: [DISCUSS] Dropping Installers from the Release Process leave
> >>> that work to Third Party Distributors
> >>>
> >>> Dear all,
> >>>
> >>> It is a great burden to us to provide the best out-of-the-box install
> >>> experience with NetBeans. That would mean, providing an installer with
> >>> JDK, nb-javac probably javafx.
> >>>
> >>> See the threads:
> >>>
> >>>
> >>> https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
> >>> d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E
> >>>
> >>>
> >>> https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
> >>> a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E
> >>>
> >>> On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
>  Dear all,
> 
>  I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
>  with Apache NetBeans.
> 
>  There are mainly two readings of GPL+CPE:
> 
>  1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
>  distributed under Apache license, due to CPE  2. CPE only allows
>  other product built on Java to be distributed
>  under their own license.
> 
>  As I'm 

Re: [DISCUSS] What to do with old community contributed plugins?

[Emilian Bold]

I have downloaded that Plugin Portal data (which includes the NBMs and
catalog.xml) and am serving all the files from another server. I seem
to be able to register it in the IDE. Looking good.

Once I get some confirmations I can make the URL public.

--emi

On Thu, Nov 21, 2019 at 10:12 PM Jiří Kovalský  wrote:
>
> Hi again Emilian,
>
> this is to confirm that I have sent the download location with PP2
> binaries snapshot to your GMail account.
>
> If you cannot find the e-mail, let me please know.
>
> Best regards,
> -Jirka
>
> Dne 20. 11. 19 v 11:46 Jiří Kovalský napsal(a):
> > Hi Emilian,
> >
> > I am working on that and will send you download coordinates in a
> > private e-mail.
> >
> > -Jirka
> >
> > Dne 18. 11. 19 v 22:57 Emilian Bold napsal(a):
> >> No, really, is there some way to get the whole of plugins.netbeans.org
> >> at once? Or crawl it at a faster speed?
> >>
> >> Seems to server is throttling me at 300KB which means the 20GB would
> >> take me a week.
> >>
> >> --emi
> >>
> >> On Mon, Nov 18, 2019 at 10:47 PM Christian Lenz
> >>  wrote:
> >>>
> >>> ➢ I think it would be a good idea to try to reach all contributers (I
> >>> ➢ assume a mail address is present) and get them to the new (still to be
> >>> ➢ completed) plugin portal.
> >>>
> >>> Just to say smth about that. From round about 10 plugin author, that
> >>> I tried to contact about aourcecode and other stuff, maybe half of it
> >>> answered me. I don’t know it exactly, but this is not that possible,
> >>> that everyone will response or can, because of no access to the mail
> >>> address anymore or discontinueing work or whatever reason. Just to
> >>> let you know, I tried it several times.
> >>>
> >>>
> >>> Cheers
> >>>
> >>> Chris
> >>>
> >>>
> >>>
> >>>
> >>> Von: Matthias Bläsing
> >>> Gesendet: Montag, 18. November 2019 18:40
> >>> An: dev@netbeans.apache.org
> >>> Betreff: Re: [DISCUSS] What to do with old community contributed
> >>> plugins?
> >>>
> >>> Hi,
> >>>
> >>> Am Dienstag, den 12.11.2019, 13:51 +0100 schrieb Jiří Kovalský:
>   we are preparing decommission of the old Plugin Portal 2.0 [1]
>  which
>  is hosted on Oracle infrastructure. Before we turn off the switch we
>  need to decide what we want to do with the plugins contributed by all
>  the kind NetBeans community members over the years totaling ~20 GB. I
>  believe that we don't want to just delete these NBM files.
> 
>  [1]
>  https://urldefense.proofpoint.com/v2/url?u=http-3A__plugins.netbeans.org_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4=O2Fja6PhovWdi4X_mm2m8U9TYkedKKkllioZe0m_UKk=wJ7h5_LWddf9J3WgVdlF3XfjYcV1s0wONqa5fLWYANg=
> 
> 
>   The problem here is the restriction that we can't use Apache
>  infrastructure to host any 3rd party binaries. The only thing what we
>  could potentially do is to publish module catalogs with references to
>  some other publicly accessible places.
> 
>  Any opinions on what is the right thing to do?
> 
> >>>
> >>> I think it would be a good idea to try to reach all contributers (I
> >>> assume a mail address is present) and get them to the new (still to be
> >>> completed) plugin portal.
> >>>
> >>> I would not host the plugins anywhere. If I remember correctly the
> >>> plugin portal was a wild mix of licenses and so from my perspective
> >>> this is a dangerous endeavour. For example take a GPLed plugin, you'd
> >>> need the source code to redistribute it properly.
> >>>
> >>> This is totally different, to the code donation from oracle. Even if we
> >>> end up not integrating all donated code, it is still usable (i.e. later
> >>> intergrated or used outside Apache NetBeans). The same does not hold
> >>> true for all plugins.
> >>>
> >>> Oracle could think about creating a static site, that way the plugins
> >>> would still be accessible, could be transfered to a passive file host
> >>> and be done.
> >>>
> >>> Greetings
> >>>
> >>> Matthias
> >>>
> >>>
> >>> -
> >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_NETBEANS_Mailing-2Blists=DwIFaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=8_Pz0x0SKeT5e3IehhQKCbQ2xl3tz40jnCU133NrdP4=O2Fja6PhovWdi4X_mm2m8U9TYkedKKkllioZe0m_UKk=A_2IGkwhS1Sw3Kygj972S7UE8e-aCupqn6pdAE1wAhE=
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> -
> >> 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:
> >> 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Laszlo Kishalmi]

Just adding some info:

It is not just about the JDK, but JDK, nb-javac and probably a fitting 
JavaFX runtime.


If someone can bundle those up and provide an installer most probably 
based on the installer code we have, then that would be the best end 
user experience, like in the old days when we said NetBeans just works.


Separate distributions, like OpenBeans, would eventually emerge.

It is just a question of what would be better for the brand. Keeping our 
"crippled" installers and/or offer additional install experience from 
third parties.


On 11/28/19 8:49 AM, Kirk Pepperdine wrote:

Hi all,

Again, I believe that you could distribute from Adopt with a JDK bundled. So 
maybe this is a case where using a 3rd party makes sense.

Kind regards,
Kirk



On Nov 28, 2019, at 8:45 AM, Kenneth Fogel  wrote:

I apologize if I misunderstood but the conversation appeared to me, likely 
incorrectly, to go beyond just bundling a Java JDK. The installers that are 
already there, are they downloading a JDK if one is not present? Requiring a 
separate install of Java is the status quo. If we could make that part of the 
NetBeans installer then we should an we should pursue an exemption to Apache 
policies if required.

Ken


-Original Message-
From: Geertjan Wielenga 
Sent: November 28, 2019 11:30 AM
To: dev@netbeans.apache.org
Subject: Re: [DISCUSS] Dropping Installers from the Release Process leave that 
work to Third Party Distributors

You’re aware that we’re already distributing an installer, right? And that that 
is not what we’re talking about?

We’re talking about the fact that we can’t bundle the JDK with that installer 
and then distribute that installer from Apache.

A simple link on our download page to OpenBeans and AdoptOpenJDK and any other 
distributor is all we need, for the installers of NetBeans that bundle the JDK.

Gj


On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel 
wrote:


This is a bad idea. I personally feel that an installer is mandatory.
Eclipse and IntelliJ have installers for all platforms. Leaving it to
third parties will mean that we have no oversight on the quality and
ease of use of the installer. Only distributing a zip file implies
that skills beyond learning to code with NetBeans will be required. We
can pretty much write off the education sector if there is no
installer. Sorry to be harsh but this is a line I believe we must not cross.

It is unfortunates, as someone has pointed out, that Apache is not end
user friendly but that is no excuse. NetBeans is an end user program
and must be as easy to install as any other IDE and have an official installer.

Ken


-Original Message-
From: Laszlo Kishalmi 
Sent: November 27, 2019 2:41 PM
To: Apache NetBeans 
Subject: [DISCUSS] Dropping Installers from the Release Process leave
that work to Third Party Distributors

Dear all,

It is a great burden to us to provide the best out-of-the-box install
experience with NetBeans. That would mean, providing an installer with
JDK, nb-javac probably javafx.

See the threads:


https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E


https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E

On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:

Dear all,

I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
with Apache NetBeans.

There are mainly two readings of GPL+CPE:

1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
distributed under Apache license, due to CPE  2. CPE only allows
other product built on Java to be distributed
under their own license.

As I'm not a lawyer, I cannot answer which interpretation is correct
(maybe none of them). ASF has every right to regard the second
interpretation, thus GPL+CPE ended up in the Category-X licenses.

The following viable possibilities were brought up:

1. We may apply for an exception to the board  2. Use some download
logic in the installer.
3. Leave the binary packaging and distribution to third parties.

Regarding that there are interest from third parties to built on
Apache NetBeans, I'm going to recommend the PMC to select a few
distributor for creating installer packages and we limit/drop our
installer bundle creation in the future.

Thank you,

Laszlo Kishalmi


I do not think that after this discussion we would get the exception
from the board Geertjan might try to bring it up there as well.

As of me option 2 is questionable.

Option 3. is a bit hard to say, but if we can't produce proper
installation packages, it would probably better to not create those
packages at all, leave that for others.

How I imagine that:

1.  From 11.3 we remove the convenience binaries and installers from
our download page
2. We would still create, sign and host our nbm-s.
3. On our download page we have the source package and a section for
third party distributors.

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Neil C Smith]

On Thu, 28 Nov 2019 at 16:52, Geertjan Wielenga  wrote:
> .. Neil, make their own
> JDK+NetBeans available,

That wasn't what I was referring to above.  I was looking at how easy
it would be to make an InnoSetup installer that included the ability
to select and download a JDK.

To do all that, we would obviously need to move to installers that are
not Java based, and ideally that we're not writing from scratch.

It may not be the right use of our time!

Best wishes,

Neil

-
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

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Geertjan Wielenga]

If we have AdoptOpenJDK officially providing a bundle together with
NetBeans, then I think we should consider not providing an installer at all
— and just make the convenience binary available as a ZIP and point to
AdoptOpenJDK and OpenBeans and any other bundlers/distributors.

Gj



On Thu, 28 Nov 2019 at 17:53, Geertjan Wielenga  wrote:

>
> Excellent news, Kirk.
>
> How do we get this done?
>
> Gj
>
> On Thu, 28 Nov 2019 at 17:49, Kirk Pepperdine  wrote:
>
>> Hi all,
>>
>> Again, I believe that you could distribute from Adopt with a JDK bundled.
>> So maybe this is a case where using a 3rd party makes sense.
>>
>> Kind regards,
>> Kirk
>>
>>
>> > On Nov 28, 2019, at 8:45 AM, Kenneth Fogel 
>> wrote:
>> >
>> > I apologize if I misunderstood but the conversation appeared to me,
>> likely incorrectly, to go beyond just bundling a Java JDK. The installers
>> that are already there, are they downloading a JDK if one is not present?
>> Requiring a separate install of Java is the status quo. If we could make
>> that part of the NetBeans installer then we should an we should pursue an
>> exemption to Apache policies if required.
>> >
>> > Ken
>> >
>> >
>> > -Original Message-
>> > From: Geertjan Wielenga 
>> > Sent: November 28, 2019 11:30 AM
>> > To: dev@netbeans.apache.org
>> > Subject: Re: [DISCUSS] Dropping Installers from the Release Process
>> leave that work to Third Party Distributors
>> >
>> > You’re aware that we’re already distributing an installer, right? And
>> that that is not what we’re talking about?
>> >
>> > We’re talking about the fact that we can’t bundle the JDK with that
>> installer and then distribute that installer from Apache.
>> >
>> > A simple link on our download page to OpenBeans and AdoptOpenJDK and
>> any other distributor is all we need, for the installers of NetBeans that
>> bundle the JDK.
>> >
>> > Gj
>> >
>> >
>> > On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel > >
>> > wrote:
>> >
>> >> This is a bad idea. I personally feel that an installer is mandatory.
>> >> Eclipse and IntelliJ have installers for all platforms. Leaving it to
>> >> third parties will mean that we have no oversight on the quality and
>> >> ease of use of the installer. Only distributing a zip file implies
>> >> that skills beyond learning to code with NetBeans will be required. We
>> >> can pretty much write off the education sector if there is no
>> >> installer. Sorry to be harsh but this is a line I believe we must not
>> cross.
>> >>
>> >> It is unfortunates, as someone has pointed out, that Apache is not end
>> >> user friendly but that is no excuse. NetBeans is an end user program
>> >> and must be as easy to install as any other IDE and have an official
>> installer.
>> >>
>> >> Ken
>> >>
>> >>
>> >> -Original Message-
>> >> From: Laszlo Kishalmi 
>> >> Sent: November 27, 2019 2:41 PM
>> >> To: Apache NetBeans 
>> >> Subject: [DISCUSS] Dropping Installers from the Release Process leave
>> >> that work to Third Party Distributors
>> >>
>> >> Dear all,
>> >>
>> >> It is a great burden to us to provide the best out-of-the-box install
>> >> experience with NetBeans. That would mean, providing an installer with
>> >> JDK, nb-javac probably javafx.
>> >>
>> >> See the threads:
>> >>
>> >>
>> >> https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
>> >> d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E
>> >>
>> >>
>> >> https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
>> >> a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E
>> >>
>> >> On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
>> >>>
>> >>> Dear all,
>> >>>
>> >>> I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
>> >>> with Apache NetBeans.
>> >>>
>> >>> There are mainly two readings of GPL+CPE:
>> >>>
>> >>> 1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
>> >>>distributed under Apache license, due to CPE  2. CPE only allows
>> >>> other product built on Java to be distributed
>> >>>under their own license.
>> >>>
>> >>> As I'm not a lawyer, I cannot answer which interpretation is correct
>> >>> (maybe none of them). ASF has every right to regard the second
>> >>> interpretation, thus GPL+CPE ended up in the Category-X licenses.
>> >>>
>> >>> The following viable possibilities were brought up:
>> >>>
>> >>> 1. We may apply for an exception to the board  2. Use some download
>> >>> logic in the installer.
>> >>> 3. Leave the binary packaging and distribution to third parties.
>> >>>
>> >>> Regarding that there are interest from third parties to built on
>> >>> Apache NetBeans, I'm going to recommend the PMC to select a few
>> >>> distributor for creating installer packages and we limit/drop our
>> >>> installer bundle creation in the future.
>> >>>
>> >>> Thank you,
>> >>>
>> >>> Laszlo Kishalmi
>> >>>
>> >>
>> >> I do not think that after this discussion we would get the exception
>> >> from the board Geertjan might try to bring it up there as 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Geertjan Wielenga]

Excellent news, Kirk.

How do we get this done?

Gj

On Thu, 28 Nov 2019 at 17:49, Kirk Pepperdine  wrote:

> Hi all,
>
> Again, I believe that you could distribute from Adopt with a JDK bundled.
> So maybe this is a case where using a 3rd party makes sense.
>
> Kind regards,
> Kirk
>
>
> > On Nov 28, 2019, at 8:45 AM, Kenneth Fogel 
> wrote:
> >
> > I apologize if I misunderstood but the conversation appeared to me,
> likely incorrectly, to go beyond just bundling a Java JDK. The installers
> that are already there, are they downloading a JDK if one is not present?
> Requiring a separate install of Java is the status quo. If we could make
> that part of the NetBeans installer then we should an we should pursue an
> exemption to Apache policies if required.
> >
> > Ken
> >
> >
> > -Original Message-
> > From: Geertjan Wielenga 
> > Sent: November 28, 2019 11:30 AM
> > To: dev@netbeans.apache.org
> > Subject: Re: [DISCUSS] Dropping Installers from the Release Process
> leave that work to Third Party Distributors
> >
> > You’re aware that we’re already distributing an installer, right? And
> that that is not what we’re talking about?
> >
> > We’re talking about the fact that we can’t bundle the JDK with that
> installer and then distribute that installer from Apache.
> >
> > A simple link on our download page to OpenBeans and AdoptOpenJDK and any
> other distributor is all we need, for the installers of NetBeans that
> bundle the JDK.
> >
> > Gj
> >
> >
> > On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel 
> > wrote:
> >
> >> This is a bad idea. I personally feel that an installer is mandatory.
> >> Eclipse and IntelliJ have installers for all platforms. Leaving it to
> >> third parties will mean that we have no oversight on the quality and
> >> ease of use of the installer. Only distributing a zip file implies
> >> that skills beyond learning to code with NetBeans will be required. We
> >> can pretty much write off the education sector if there is no
> >> installer. Sorry to be harsh but this is a line I believe we must not
> cross.
> >>
> >> It is unfortunates, as someone has pointed out, that Apache is not end
> >> user friendly but that is no excuse. NetBeans is an end user program
> >> and must be as easy to install as any other IDE and have an official
> installer.
> >>
> >> Ken
> >>
> >>
> >> -Original Message-
> >> From: Laszlo Kishalmi 
> >> Sent: November 27, 2019 2:41 PM
> >> To: Apache NetBeans 
> >> Subject: [DISCUSS] Dropping Installers from the Release Process leave
> >> that work to Third Party Distributors
> >>
> >> Dear all,
> >>
> >> It is a great burden to us to provide the best out-of-the-box install
> >> experience with NetBeans. That would mean, providing an installer with
> >> JDK, nb-javac probably javafx.
> >>
> >> See the threads:
> >>
> >>
> >> https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
> >> d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E
> >>
> >>
> >> https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
> >> a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E
> >>
> >> On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
> >>>
> >>> Dear all,
> >>>
> >>> I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
> >>> with Apache NetBeans.
> >>>
> >>> There are mainly two readings of GPL+CPE:
> >>>
> >>> 1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
> >>>distributed under Apache license, due to CPE  2. CPE only allows
> >>> other product built on Java to be distributed
> >>>under their own license.
> >>>
> >>> As I'm not a lawyer, I cannot answer which interpretation is correct
> >>> (maybe none of them). ASF has every right to regard the second
> >>> interpretation, thus GPL+CPE ended up in the Category-X licenses.
> >>>
> >>> The following viable possibilities were brought up:
> >>>
> >>> 1. We may apply for an exception to the board  2. Use some download
> >>> logic in the installer.
> >>> 3. Leave the binary packaging and distribution to third parties.
> >>>
> >>> Regarding that there are interest from third parties to built on
> >>> Apache NetBeans, I'm going to recommend the PMC to select a few
> >>> distributor for creating installer packages and we limit/drop our
> >>> installer bundle creation in the future.
> >>>
> >>> Thank you,
> >>>
> >>> Laszlo Kishalmi
> >>>
> >>
> >> I do not think that after this discussion we would get the exception
> >> from the board Geertjan might try to bring it up there as well.
> >>
> >> As of me option 2 is questionable.
> >>
> >> Option 3. is a bit hard to say, but if we can't produce proper
> >> installation packages, it would probably better to not create those
> >> packages at all, leave that for others.
> >>
> >> How I imagine that:
> >>
> >> 1.  From 11.3 we remove the convenience binaries and installers from
> >>our download page
> >> 2. We would still create, sign and host our nbm-s.
> >> 3. On our download page we have the source 

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Geertjan Wielenga]

That’s what we’re trying to achieve, though it looks unlikely that we’ll
win this one.

And in some ways it is better that we are not and cannot bundle the JDK
because then the question would be “which JDK” and the answer is not so
obvious — it would have more impact for AdoptOpenJDK to provide its own
bundle with NetBeans (after all, what’s the point of a JDK without a tool
to use it out of the box), etc.

And if in addition some PMC members, e.g., Emilian and Neil, make their own
JDK+NetBeans available, then we have even more choice — and would be
following the Apache Way too.

Yes, there are downsides, very easy to enumerate. But every conceivable
solution has downsides.

Gj


On Thu, 28 Nov 2019 at 17:45, Kenneth Fogel 
wrote:

> I apologize if I misunderstood but the conversation appeared to me, likely
> incorrectly, to go beyond just bundling a Java JDK. The installers that are
> already there, are they downloading a JDK if one is not present? Requiring
> a separate install of Java is the status quo. If we could make that part of
> the NetBeans installer then we should an we should pursue an exemption to
> Apache policies if required.
>
> Ken
>
>
> -Original Message-
> From: Geertjan Wielenga 
> Sent: November 28, 2019 11:30 AM
> To: dev@netbeans.apache.org
> Subject: Re: [DISCUSS] Dropping Installers from the Release Process leave
> that work to Third Party Distributors
>
> You’re aware that we’re already distributing an installer, right? And that
> that is not what we’re talking about?
>
> We’re talking about the fact that we can’t bundle the JDK with that
> installer and then distribute that installer from Apache.
>
> A simple link on our download page to OpenBeans and AdoptOpenJDK and any
> other distributor is all we need, for the installers of NetBeans that
> bundle the JDK.
>
> Gj
>
>
> On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel 
> wrote:
>
> > This is a bad idea. I personally feel that an installer is mandatory.
> > Eclipse and IntelliJ have installers for all platforms. Leaving it to
> > third parties will mean that we have no oversight on the quality and
> > ease of use of the installer. Only distributing a zip file implies
> > that skills beyond learning to code with NetBeans will be required. We
> > can pretty much write off the education sector if there is no
> > installer. Sorry to be harsh but this is a line I believe we must not
> cross.
> >
> > It is unfortunates, as someone has pointed out, that Apache is not end
> > user friendly but that is no excuse. NetBeans is an end user program
> > and must be as easy to install as any other IDE and have an official
> installer.
> >
> > Ken
> >
> >
> > -Original Message-
> > From: Laszlo Kishalmi 
> > Sent: November 27, 2019 2:41 PM
> > To: Apache NetBeans 
> > Subject: [DISCUSS] Dropping Installers from the Release Process leave
> > that work to Third Party Distributors
> >
> > Dear all,
> >
> > It is a great burden to us to provide the best out-of-the-box install
> > experience with NetBeans. That would mean, providing an installer with
> > JDK, nb-javac probably javafx.
> >
> > See the threads:
> >
> >
> > https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
> > d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E
> >
> >
> > https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
> > a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E
> >
> > On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
> > >
> > > Dear all,
> > >
> > > I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
> > > with Apache NetBeans.
> > >
> > > There are mainly two readings of GPL+CPE:
> > >
> > >  1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
> > > distributed under Apache license, due to CPE  2. CPE only allows
> > > other product built on Java to be distributed
> > > under their own license.
> > >
> > > As I'm not a lawyer, I cannot answer which interpretation is correct
> > > (maybe none of them). ASF has every right to regard the second
> > > interpretation, thus GPL+CPE ended up in the Category-X licenses.
> > >
> > > The following viable possibilities were brought up:
> > >
> > >  1. We may apply for an exception to the board  2. Use some download
> > > logic in the installer.
> > >  3. Leave the binary packaging and distribution to third parties.
> > >
> > > Regarding that there are interest from third parties to built on
> > > Apache NetBeans, I'm going to recommend the PMC to select a few
> > > distributor for creating installer packages and we limit/drop our
> > > installer bundle creation in the future.
> > >
> > > Thank you,
> > >
> > > Laszlo Kishalmi
> > >
> >
> > I do not think that after this discussion we would get the exception
> > from the board Geertjan might try to bring it up there as well.
> >
> > As of me option 2 is questionable.
> >
> > Option 3. is a bit hard to say, but if we can't produce proper
> > installation packages, it would probably 

RE: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Kenneth Fogel]

I apologize if I misunderstood but the conversation appeared to me, likely 
incorrectly, to go beyond just bundling a Java JDK. The installers that are 
already there, are they downloading a JDK if one is not present? Requiring a 
separate install of Java is the status quo. If we could make that part of the 
NetBeans installer then we should an we should pursue an exemption to Apache 
policies if required.

Ken


-Original Message-
From: Geertjan Wielenga  
Sent: November 28, 2019 11:30 AM
To: dev@netbeans.apache.org
Subject: Re: [DISCUSS] Dropping Installers from the Release Process leave that 
work to Third Party Distributors

You’re aware that we’re already distributing an installer, right? And that that 
is not what we’re talking about?

We’re talking about the fact that we can’t bundle the JDK with that installer 
and then distribute that installer from Apache.

A simple link on our download page to OpenBeans and AdoptOpenJDK and any other 
distributor is all we need, for the installers of NetBeans that bundle the JDK.

Gj


On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel 
wrote:

> This is a bad idea. I personally feel that an installer is mandatory.
> Eclipse and IntelliJ have installers for all platforms. Leaving it to 
> third parties will mean that we have no oversight on the quality and 
> ease of use of the installer. Only distributing a zip file implies 
> that skills beyond learning to code with NetBeans will be required. We 
> can pretty much write off the education sector if there is no 
> installer. Sorry to be harsh but this is a line I believe we must not cross.
>
> It is unfortunates, as someone has pointed out, that Apache is not end 
> user friendly but that is no excuse. NetBeans is an end user program 
> and must be as easy to install as any other IDE and have an official 
> installer.
>
> Ken
>
>
> -Original Message-
> From: Laszlo Kishalmi 
> Sent: November 27, 2019 2:41 PM
> To: Apache NetBeans 
> Subject: [DISCUSS] Dropping Installers from the Release Process leave 
> that work to Third Party Distributors
>
> Dear all,
>
> It is a great burden to us to provide the best out-of-the-box install 
> experience with NetBeans. That would mean, providing an installer with 
> JDK, nb-javac probably javafx.
>
> See the threads:
>
>
> https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96
> d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E
>
>
> https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6
> a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E
>
> On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
> >
> > Dear all,
> >
> > I try to summary the lengthy threads about bundling OpenJDK GPL+CPE 
> > with Apache NetBeans.
> >
> > There are mainly two readings of GPL+CPE:
> >
> >  1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
> > distributed under Apache license, due to CPE  2. CPE only allows 
> > other product built on Java to be distributed
> > under their own license.
> >
> > As I'm not a lawyer, I cannot answer which interpretation is correct 
> > (maybe none of them). ASF has every right to regard the second 
> > interpretation, thus GPL+CPE ended up in the Category-X licenses.
> >
> > The following viable possibilities were brought up:
> >
> >  1. We may apply for an exception to the board  2. Use some download 
> > logic in the installer.
> >  3. Leave the binary packaging and distribution to third parties.
> >
> > Regarding that there are interest from third parties to built on 
> > Apache NetBeans, I'm going to recommend the PMC to select a few 
> > distributor for creating installer packages and we limit/drop our 
> > installer bundle creation in the future.
> >
> > Thank you,
> >
> > Laszlo Kishalmi
> >
>
> I do not think that after this discussion we would get the exception 
> from the board Geertjan might try to bring it up there as well.
>
> As of me option 2 is questionable.
>
> Option 3. is a bit hard to say, but if we can't produce proper 
> installation packages, it would probably better to not create those 
> packages at all, leave that for others.
>
> How I imagine that:
>
>  1.  From 11.3 we remove the convenience binaries and installers from
> our download page
>  2. We would still create, sign and host our nbm-s.
>  3. On our download page we have the source package and a section for
> third party distributors.
>
> Well of course this thread is just to start a discussion about this 
> matter. I know it would hurt the brand, but probably it is better than 
> produce some sub-optimal installers while other parties can come with 
> all the bells and whistles.
>
> Thank you,
>
> Laszlo Kishalmi
>

-
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:

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Neil C Smith]

On Thu, 28 Nov 2019, 16:20 Kenneth Fogel, 
wrote:

>
> It is unfortunates, as someone has pointed out, that Apache is not end
> user friendly but that is no excuse. NetBeans is an end user program and
> must be as easy to install as any other IDE and have an official installer.
>

What happens if those two things are mutually exclusive? We can, and are,
pushing for changes here. But if we cannot convince ASF of the need for
that, then surely a good Plan B beats giving up?!

Best wishes,

Neil

>

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Geertjan Wielenga]

You’re aware that we’re already distributing an installer, right? And that
that is not what we’re talking about?

We’re talking about the fact that we can’t bundle the JDK with that
installer and then distribute that installer from Apache.

A simple link on our download page to OpenBeans and AdoptOpenJDK and any
other distributor is all we need, for the installers of NetBeans that
bundle the JDK.

Gj


On Thu, 28 Nov 2019 at 17:20, Kenneth Fogel 
wrote:

> This is a bad idea. I personally feel that an installer is mandatory.
> Eclipse and IntelliJ have installers for all platforms. Leaving it to third
> parties will mean that we have no oversight on the quality and ease of use
> of the installer. Only distributing a zip file implies that skills beyond
> learning to code with NetBeans will be required. We can pretty much write
> off the education sector if there is no installer. Sorry to be harsh but
> this is a line I believe we must not cross.
>
> It is unfortunates, as someone has pointed out, that Apache is not end
> user friendly but that is no excuse. NetBeans is an end user program and
> must be as easy to install as any other IDE and have an official installer.
>
> Ken
>
>
> -Original Message-
> From: Laszlo Kishalmi 
> Sent: November 27, 2019 2:41 PM
> To: Apache NetBeans 
> Subject: [DISCUSS] Dropping Installers from the Release Process leave that
> work to Third Party Distributors
>
> Dear all,
>
> It is a great burden to us to provide the best out-of-the-box install
> experience with NetBeans. That would mean, providing an installer with JDK,
> nb-javac probably javafx.
>
> See the threads:
>
>
> https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E
>
>
> https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E
>
> On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
> >
> > Dear all,
> >
> > I try to summary the lengthy threads about bundling OpenJDK GPL+CPE
> > with Apache NetBeans.
> >
> > There are mainly two readings of GPL+CPE:
> >
> >  1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
> > distributed under Apache license, due to CPE  2. CPE only allows
> > other product built on Java to be distributed
> > under their own license.
> >
> > As I'm not a lawyer, I cannot answer which interpretation is correct
> > (maybe none of them). ASF has every right to regard the second
> > interpretation, thus GPL+CPE ended up in the Category-X licenses.
> >
> > The following viable possibilities were brought up:
> >
> >  1. We may apply for an exception to the board  2. Use some download
> > logic in the installer.
> >  3. Leave the binary packaging and distribution to third parties.
> >
> > Regarding that there are interest from third parties to built on
> > Apache NetBeans, I'm going to recommend the PMC to select a few
> > distributor for creating installer packages and we limit/drop our
> > installer bundle creation in the future.
> >
> > Thank you,
> >
> > Laszlo Kishalmi
> >
>
> I do not think that after this discussion we would get the exception from
> the board Geertjan might try to bring it up there as well.
>
> As of me option 2 is questionable.
>
> Option 3. is a bit hard to say, but if we can't produce proper
> installation packages, it would probably better to not create those
> packages at all, leave that for others.
>
> How I imagine that:
>
>  1.  From 11.3 we remove the convenience binaries and installers from
> our download page
>  2. We would still create, sign and host our nbm-s.
>  3. On our download page we have the source package and a section for
> third party distributors.
>
> Well of course this thread is just to start a discussion about this
> matter. I know it would hurt the brand, but probably it is better than
> produce some sub-optimal installers while other parties can come with all
> the bells and whistles.
>
> Thank you,
>
> Laszlo Kishalmi
>

RE: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Kenneth Fogel]

This is a bad idea. I personally feel that an installer is mandatory. Eclipse 
and IntelliJ have installers for all platforms. Leaving it to third parties 
will mean that we have no oversight on the quality and ease of use of the 
installer. Only distributing a zip file implies that skills beyond learning to 
code with NetBeans will be required. We can pretty much write off the education 
sector if there is no installer. Sorry to be harsh but this is a line I believe 
we must not cross.

It is unfortunates, as someone has pointed out, that Apache is not end user 
friendly but that is no excuse. NetBeans is an end user program and must be as 
easy to install as any other IDE and have an official installer.

Ken


-Original Message-
From: Laszlo Kishalmi  
Sent: November 27, 2019 2:41 PM
To: Apache NetBeans 
Subject: [DISCUSS] Dropping Installers from the Release Process leave that work 
to Third Party Distributors

Dear all,

It is a great burden to us to provide the best out-of-the-box install 
experience with NetBeans. That would mean, providing an installer with JDK, 
nb-javac probably javafx.

See the threads:

https://lists.apache.org/thread.html/a3e6051130e18aae3f7a81c562a63ac96d3a3a07d4bcbee074392d59@%3Clegal-discuss.apache.org%3E

https://lists.apache.org/thread.html/489f17e30d9125ee48e2d78dc36572db6a3f5d6474f492458e0db151@%3Clegal-discuss.apache.org%3E

On 11/26/19 9:29 PM, Laszlo Kishalmi wrote:
>
> Dear all,
>
> I try to summary the lengthy threads about bundling OpenJDK GPL+CPE 
> with Apache NetBeans.
>
> There are mainly two readings of GPL+CPE:
>
>  1. OpenJDK (GPL+CPE) + NetBeans (Apache) = Executable which can be
> distributed under Apache license, due to CPE  2. CPE only allows 
> other product built on Java to be distributed
> under their own license.
>
> As I'm not a lawyer, I cannot answer which interpretation is correct 
> (maybe none of them). ASF has every right to regard the second 
> interpretation, thus GPL+CPE ended up in the Category-X licenses.
>
> The following viable possibilities were brought up:
>
>  1. We may apply for an exception to the board  2. Use some download 
> logic in the installer.
>  3. Leave the binary packaging and distribution to third parties.
>
> Regarding that there are interest from third parties to built on 
> Apache NetBeans, I'm going to recommend the PMC to select a few 
> distributor for creating installer packages and we limit/drop our 
> installer bundle creation in the future.
>
> Thank you,
>
> Laszlo Kishalmi
>

I do not think that after this discussion we would get the exception from the 
board Geertjan might try to bring it up there as well.

As of me option 2 is questionable.

Option 3. is a bit hard to say, but if we can't produce proper installation 
packages, it would probably better to not create those packages at all, leave 
that for others.

How I imagine that:

 1.  From 11.3 we remove the convenience binaries and installers from
our download page
 2. We would still create, sign and host our nbm-s.
 3. On our download page we have the source package and a section for
third party distributors.

Well of course this thread is just to start a discussion about this matter. I 
know it would hurt the brand, but probably it is better than produce some 
sub-optimal installers while other parties can come with all the bells and 
whistles.

Thank you,

Laszlo Kishalmi

Re: [DISCUSS] Dropping Installers from the Release Process leave that work to Third Party Distributors

[Geertjan Wielenga]

Awesome! How can we support this?

Gj

On Thu, 28 Nov 2019 at 16:06, Kirk Pepperdine  wrote:

> Hi,
>
> I believe adopt would very much like to host a NB download.
>
> Kirk
>
> On Wed, Nov 27, 2019 at 22:03 Emilian Bold  wrote:
>
> > Apache rules do not go well with end user applications such as NetBeans
> > IDE.
> >
> > The binary zip could be used as a baseline for building the installers
> > and this fact itself gives it more legitimacy / security.
> >
> > OpenBeans could also distribute 'vanilla' NetBeans installers bundling
> > AdoptOpenJDK. There's a small discussion about trademark here but I
> > think it's allowed per another thread.
> >
> > --emi
> >
> > On Wed, Nov 27, 2019 at 11:51 PM Neil C Smith 
> > wrote:
> > >
> > > On Wed, 27 Nov 2019 at 19:41, Laszlo Kishalmi <
> laszlo.kisha...@gmail.com>
> > wrote:
> > > > I do not think that after this discussion we would get the exception
> > > > from the board Geertjan might try to bring it up there as well.
> > >
> > > Well, we'll see.  I personally have serious misgivings about ASF's
> > > current position on "platform" dependencies when the world is changing
> > > and moving to bundling that platform.  And on the issue of binary
> > > releases not being "official" - I've just signed 5 NBMs with an ASF
> > > code certificate!  I think the current position on either of these
> > > things brings the sustainability of Java projects at ASF into
> > > question, and particularly our long-term viability.
> > >
> > > I would really like a more forward thinking approach closer to
> > > https://www.eclipse.org/org/documents/GPL_CE_Policy.php !
> > >
> > > > As of me option 2 is questionable.
> > >
> > > Maybe!  It's doable.  I did start looking at doing this in an
> > > InnoSetup based installer recently.
> > >
> > > > Option 3. is a bit hard to say, but if we can't produce proper
> > > > installation packages, it would probably better to not create those
> > > > packages at all, leave that for others.
> > > ...
> > > >  1.  From 11.3 we remove the convenience binaries and installers from
> > > > our download page
> > >
> > > If we go down that route, I don't think we should remove the binary
> > > zip.  In fact, that could be used as the basis for other people's
> > > installers.  eg. an AppImage build script could directly download and
> > > embed that.
> > >
> > > There was some conversation a while back about AdoptOpenJDK making
> > > bundled installers from our sources.  That might be a good option to
> > > follow up on again if we go down this route.  I'd prefer fostering a
> > > good relationship with a community focused distributor.
> > >
> > > Best wishes,
> > >
> > > Neil
> > >
> > > -
> > > 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
> > >
> > >
> > >
> >
> > -
> > 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
> >
> >
> >
> >
>

Re: Travis is failing on building hibernateweb

[Brad Walker]

I noticed that as well..

On Thu, Nov 28, 2019 at 2:09 AM Matthias Bläsing 
wrote:

> That is an old problem and the build works with it.  Yesterday the htmlui
> tests began to fail on Travis. Maybe the Xvfb server does not work?
>
>
> Am 28. November 2019 09:11:28 MEZ schrieb Laszlo Kishalmi <
> laszlo.kisha...@gmail.com>:
> >I see this one in the recent logs:
> >
> >Cannot find build prerequisite org.netbeans.modules.hibernate of
> >/home/travis/build/apache/netbeans/contrib/hibernateweb
> >/home/travis/build/apache/netbeans/nbbuild/netbeans
>
>

Re: Error when building from current git

[Peter Hull]

On Wed, 27 Nov 2019 at 14:31, Laszlo Kishalmi 
wrote:

> Actually I've seen that when I added the dark LAF to the build.
>
> But master builds fine for Travis and for me as well.
>
> I don't know what caused the problem but I have done an `ant clean` and
then `ant build`  which was successful.
Thanks for your help,
Peter

Re: [VOTE] Release Apache NetBeans 11.2-u1 update

[Neil C Smith]

On Thu, 28 Nov 2019 at 01:54, Ernie Rael  wrote:
> OFF TOPIC

Please start a separate thread for discussion rather than using the
voting thread - although, please do, I think it's worth looking into!

> to fetch the individual artifacts. I expected to see only the nbms
> directory. I was surprised to see

That doesn't surprise me - it wouldn't be browseable otherwise.  I've
done some changes to the voting emails we use to be clearer *what*
people need to do to vote - we could perhaps be a bit clearer on *how*
they do that though.

I look forward to your follow up thread! :-)

Best wishes,

Neil

-
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

Re: Travis is failing on building hibernateweb

[Matthias Bläsing]

That is an old problem and the build works with it.  Yesterday the htmlui tests 
began to fail on Travis. Maybe the Xvfb server does not work?


Am 28. November 2019 09:11:28 MEZ schrieb Laszlo Kishalmi 
:
>I see this one in the recent logs:
>
>Cannot find build prerequisite org.netbeans.modules.hibernate of
>/home/travis/build/apache/netbeans/contrib/hibernateweb
>/home/travis/build/apache/netbeans/nbbuild/netbeans

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.