Re: Packaging JRE in RCP installer

[Lars Bruun-Hansen]

Christian, the bitness of cleaner.exe makes absolutely no difference
to your aim of enforcing 64Bit. I do not plan to change anything
buildwise, only the C code, meaning it will still be a 32 bit
executable. In fact I dread if I would have to look into the build
system in Apache NetBeans of this thing. :-)


On Fri, Sep 13, 2019 at 6:41 AM Emilian Bold  wrote:
>
> > @Emilian Bold:  Where would I document? Please point me in right
> direction. Thanks.
>
> I see these pages https://netbeans.apache.org/wiki/index.asciidoc are
> on GitHub here 
> https://github.com/apache/netbeans-website/tree/master/netbeans.apache.org/src/content/wiki
>
> So you could make a PR against GitHub.
>
> > not that there should be any reason to be running a
> 32bit version of Windows in 2019
>
> I thought the same, but the brand new laptop I bought for codesigning
> CoolBeans came with a 32-bit Windows although it had a 64bit
> processor. I also had some vocal user complain about the lack of 32bit
> builds.
>
> There are very few downloads though... only 3% of the total.
>
> --emi
>
> On Fri, Sep 13, 2019 at 3:11 AM Christian Oyarzun  wrote:
> >
> > Lars,
> >
> > Is the plan to continue to keep the cleaner as a 32bit exe?
> >
> > $ file cleaner.exe
> > cleaner.exe: PE32 executable (GUI) Intel 80386, for MS Windows
> >
> > The nlw.exe executable was built as a 64bit exe, which used to be 32bit in
> > previous NetBeans releases. This would prevent using the NBI to create a
> > package that
> > runs on 32bit Windows (not that there should be any reason to be running a
> > 32bit version of Windows in 2019).
> >
> > $ file nlw.exe
> > nlw.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS
> > Windows
> >
> > This is actually what lead me down the path of embedding the JVM in the
> > installer since 64bit installer will not find a JRE if there is only a
> > 32bit JVM installed on Windows.
> > It could be worked around by using the --javahome command line option, but
> > embedding it provides a better user experience.
> >
> > --Christian
> >
> >
> >
> > On Thu, Sep 12, 2019 at 4:05 PM Lars Bruun-Hansen 
> > wrote:
> >
> > > I've filed a Jira ticket :
> > > https://issues.apache.org/jira/browse/NETBEANS-3094
> > > with the aim to change the C code for the cleaner.exe to be able to
> > > delete read-only files too. It is rather trivial. I've assigned it to
> > > myself.
> > >
> > > @Emilian Bold:  Where would I document? Please point me in right
> > > direction. Thanks.
> > >
> > > On Thu, Sep 12, 2019 at 9:46 PM Christian Oyarzun  
> > > wrote:
> > > >
> > > > Oliver, it is just a question of changing the permissions on the files
> > > > before zipping the JRE.
> > > >
> > > > I'm using a modified version (JRE instead of JDK) of
> > > > jMonkeyEngine's script to create the JRE unzipsfx files.
> > > >
> > > > It's a question of adding the following to
> > > >
> > > https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146
> > > >
> > > > find . -exec chmod u+w {} \; # Make all file writable to allow
> > > > uninstaller's cleaner to remove file
> > > >
> > > > I'll send them a PR.
> > > >
> > > > --Christian
> > > >
> > > >
> > > > On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig 
> > > wrote:
> > > >
> > > > > Hi,
> > > > > I remember on such problems also with Netbeans 8.2. It had todo with
> > > > > access rights. I am
> > > > > interested in if you can figure it out.
> > > > > best regards
> > > > > Oliver
> > > > > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > > > > > following these instructions?
> > > > > > https://dzone.com/articles/including-jre-in-nbi
> > > > > >
> > > > > > While this works fine under Linux , the Windows uninstaller does not
> > > > > delete
> > > > > > some of the JRE files.
> > > > > >
> > > > > > C:\Program Files\rcpapp>dir /s /b
> > > > > > C:\Program Files\rcpapp\jre
> > > > > > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > > > > > C:\Program Files\rcpapp\jre\lib
> > > > > > C:\Program Files\rcpapp\jre\LICENSE
> > > > > > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm
> > > > > > C:\Program Files\rcpapp\jre\lib\currency.data
> > > > > > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > > > > > C:\Program Files\rcpapp\jre\lib\management
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > > > > > C:\Program
> > > Files\rcpapp\jre\lib\management\jmxremote.password.template
> > > > > > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> > > > > >
> > > > > > Any ideas on why these files are not deleted? Could it be the
> > > > > INITIAL_DELAY
> > > > > > is too short in the cleaner.exe?
> > > > > >
> > > > > >
> > > > >

Re: Packaging JRE in RCP installer

[Emilian Bold]

> @Emilian Bold:  Where would I document? Please point me in right
direction. Thanks.

I see these pages https://netbeans.apache.org/wiki/index.asciidoc are
on GitHub here 
https://github.com/apache/netbeans-website/tree/master/netbeans.apache.org/src/content/wiki

So you could make a PR against GitHub.

> not that there should be any reason to be running a
32bit version of Windows in 2019

I thought the same, but the brand new laptop I bought for codesigning
CoolBeans came with a 32-bit Windows although it had a 64bit
processor. I also had some vocal user complain about the lack of 32bit
builds.

There are very few downloads though... only 3% of the total.

--emi

On Fri, Sep 13, 2019 at 3:11 AM Christian Oyarzun  wrote:
>
> Lars,
>
> Is the plan to continue to keep the cleaner as a 32bit exe?
>
> $ file cleaner.exe
> cleaner.exe: PE32 executable (GUI) Intel 80386, for MS Windows
>
> The nlw.exe executable was built as a 64bit exe, which used to be 32bit in
> previous NetBeans releases. This would prevent using the NBI to create a
> package that
> runs on 32bit Windows (not that there should be any reason to be running a
> 32bit version of Windows in 2019).
>
> $ file nlw.exe
> nlw.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS
> Windows
>
> This is actually what lead me down the path of embedding the JVM in the
> installer since 64bit installer will not find a JRE if there is only a
> 32bit JVM installed on Windows.
> It could be worked around by using the --javahome command line option, but
> embedding it provides a better user experience.
>
> --Christian
>
>
>
> On Thu, Sep 12, 2019 at 4:05 PM Lars Bruun-Hansen 
> wrote:
>
> > I've filed a Jira ticket :
> > https://issues.apache.org/jira/browse/NETBEANS-3094
> > with the aim to change the C code for the cleaner.exe to be able to
> > delete read-only files too. It is rather trivial. I've assigned it to
> > myself.
> >
> > @Emilian Bold:  Where would I document? Please point me in right
> > direction. Thanks.
> >
> > On Thu, Sep 12, 2019 at 9:46 PM Christian Oyarzun  wrote:
> > >
> > > Oliver, it is just a question of changing the permissions on the files
> > > before zipping the JRE.
> > >
> > > I'm using a modified version (JRE instead of JDK) of
> > > jMonkeyEngine's script to create the JRE unzipsfx files.
> > >
> > > It's a question of adding the following to
> > >
> > https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146
> > >
> > > find . -exec chmod u+w {} \; # Make all file writable to allow
> > > uninstaller's cleaner to remove file
> > >
> > > I'll send them a PR.
> > >
> > > --Christian
> > >
> > >
> > > On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig 
> > wrote:
> > >
> > > > Hi,
> > > > I remember on such problems also with Netbeans 8.2. It had todo with
> > > > access rights. I am
> > > > interested in if you can figure it out.
> > > > best regards
> > > > Oliver
> > > > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > > > > following these instructions?
> > > > > https://dzone.com/articles/including-jre-in-nbi
> > > > >
> > > > > While this works fine under Linux , the Windows uninstaller does not
> > > > delete
> > > > > some of the JRE files.
> > > > >
> > > > > C:\Program Files\rcpapp>dir /s /b
> > > > > C:\Program Files\rcpapp\jre
> > > > > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > > > > C:\Program Files\rcpapp\jre\lib
> > > > > C:\Program Files\rcpapp\jre\LICENSE
> > > > > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > > > > C:\Program Files\rcpapp\jre\lib\cmm
> > > > > C:\Program Files\rcpapp\jre\lib\currency.data
> > > > > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > > > > C:\Program Files\rcpapp\jre\lib\management
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > > > > C:\Program
> > Files\rcpapp\jre\lib\management\jmxremote.password.template
> > > > > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> > > > >
> > > > > Any ideas on why these files are not deleted? Could it be the
> > > > INITIAL_DELAY
> > > > > is too short in the cleaner.exe?
> > > > >
> > > > >
> > > >
> > https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff
> > > > > dab8/nbi/engine/native/cleaner/windows/src/main.c#L28
> > > > >
> > > > > Thanks,
> > > > > Christian
> > > >
> > > >
> > > >
> >
> > -
> > 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: Packaging JRE in RCP installer

[Christian Oyarzun]

Lars,

Is the plan to continue to keep the cleaner as a 32bit exe?

$ file cleaner.exe
cleaner.exe: PE32 executable (GUI) Intel 80386, for MS Windows

The nlw.exe executable was built as a 64bit exe, which used to be 32bit in
previous NetBeans releases. This would prevent using the NBI to create a
package that
runs on 32bit Windows (not that there should be any reason to be running a
32bit version of Windows in 2019).

$ file nlw.exe
nlw.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS
Windows

This is actually what lead me down the path of embedding the JVM in the
installer since 64bit installer will not find a JRE if there is only a
32bit JVM installed on Windows.
It could be worked around by using the --javahome command line option, but
embedding it provides a better user experience.

--Christian



On Thu, Sep 12, 2019 at 4:05 PM Lars Bruun-Hansen 
wrote:

> I've filed a Jira ticket :
> https://issues.apache.org/jira/browse/NETBEANS-3094
> with the aim to change the C code for the cleaner.exe to be able to
> delete read-only files too. It is rather trivial. I've assigned it to
> myself.
>
> @Emilian Bold:  Where would I document? Please point me in right
> direction. Thanks.
>
> On Thu, Sep 12, 2019 at 9:46 PM Christian Oyarzun  wrote:
> >
> > Oliver, it is just a question of changing the permissions on the files
> > before zipping the JRE.
> >
> > I'm using a modified version (JRE instead of JDK) of
> > jMonkeyEngine's script to create the JRE unzipsfx files.
> >
> > It's a question of adding the following to
> >
> https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146
> >
> > find . -exec chmod u+w {} \; # Make all file writable to allow
> > uninstaller's cleaner to remove file
> >
> > I'll send them a PR.
> >
> > --Christian
> >
> >
> > On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig 
> wrote:
> >
> > > Hi,
> > > I remember on such problems also with Netbeans 8.2. It had todo with
> > > access rights. I am
> > > interested in if you can figure it out.
> > > best regards
> > > Oliver
> > > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > > > following these instructions?
> > > > https://dzone.com/articles/including-jre-in-nbi
> > > >
> > > > While this works fine under Linux , the Windows uninstaller does not
> > > delete
> > > > some of the JRE files.
> > > >
> > > > C:\Program Files\rcpapp>dir /s /b
> > > > C:\Program Files\rcpapp\jre
> > > > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > > > C:\Program Files\rcpapp\jre\lib
> > > > C:\Program Files\rcpapp\jre\LICENSE
> > > > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > > > C:\Program Files\rcpapp\jre\lib\cmm
> > > > C:\Program Files\rcpapp\jre\lib\currency.data
> > > > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > > > C:\Program Files\rcpapp\jre\lib\management
> > > > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > > > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > > > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > > > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > > > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > > > C:\Program
> Files\rcpapp\jre\lib\management\jmxremote.password.template
> > > > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> > > >
> > > > Any ideas on why these files are not deleted? Could it be the
> > > INITIAL_DELAY
> > > > is too short in the cleaner.exe?
> > > >
> > > >
> > >
> https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff
> > > > dab8/nbi/engine/native/cleaner/windows/src/main.c#L28
> > > >
> > > > Thanks,
> > > > Christian
> > >
> > >
> > >
>
> -
> 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: Packaging JRE in RCP installer

[Lars Bruun-Hansen]

I've filed a Jira ticket : https://issues.apache.org/jira/browse/NETBEANS-3094
with the aim to change the C code for the cleaner.exe to be able to
delete read-only files too. It is rather trivial. I've assigned it to
myself.

@Emilian Bold:  Where would I document? Please point me in right
direction. Thanks.

On Thu, Sep 12, 2019 at 9:46 PM Christian Oyarzun  wrote:
>
> Oliver, it is just a question of changing the permissions on the files
> before zipping the JRE.
>
> I'm using a modified version (JRE instead of JDK) of
> jMonkeyEngine's script to create the JRE unzipsfx files.
>
> It's a question of adding the following to
> https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146
>
> find . -exec chmod u+w {} \; # Make all file writable to allow
> uninstaller's cleaner to remove file
>
> I'll send them a PR.
>
> --Christian
>
>
> On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig  wrote:
>
> > Hi,
> > I remember on such problems also with Netbeans 8.2. It had todo with
> > access rights. I am
> > interested in if you can figure it out.
> > best regards
> > Oliver
> > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > > following these instructions?
> > > https://dzone.com/articles/including-jre-in-nbi
> > >
> > > While this works fine under Linux , the Windows uninstaller does not
> > delete
> > > some of the JRE files.
> > >
> > > C:\Program Files\rcpapp>dir /s /b
> > > C:\Program Files\rcpapp\jre
> > > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > > C:\Program Files\rcpapp\jre\lib
> > > C:\Program Files\rcpapp\jre\LICENSE
> > > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > > C:\Program Files\rcpapp\jre\lib\cmm
> > > C:\Program Files\rcpapp\jre\lib\currency.data
> > > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > > C:\Program Files\rcpapp\jre\lib\management
> > > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > > C:\Program Files\rcpapp\jre\lib\management\jmxremote.password.template
> > > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> > >
> > > Any ideas on why these files are not deleted? Could it be the
> > INITIAL_DELAY
> > > is too short in the cleaner.exe?
> > >
> > >
> > https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff
> > > dab8/nbi/engine/native/cleaner/windows/src/main.c#L28
> > >
> > > Thanks,
> > > Christian
> >
> >
> >

-
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: Packaging JRE in RCP installer

[Christian Oyarzun]

Oliver, it is just a question of changing the permissions on the files
before zipping the JRE.

I'm using a modified version (JRE instead of JDK) of
jMonkeyEngine's script to create the JRE unzipsfx files.

It's a question of adding the following to
https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146

find . -exec chmod u+w {} \; # Make all file writable to allow
uninstaller's cleaner to remove file

I'll send them a PR.

--Christian


On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig  wrote:

> Hi,
> I remember on such problems also with Netbeans 8.2. It had todo with
> access rights. I am
> interested in if you can figure it out.
> best regards
> Oliver
> > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > following these instructions?
> > https://dzone.com/articles/including-jre-in-nbi
> >
> > While this works fine under Linux , the Windows uninstaller does not
> delete
> > some of the JRE files.
> >
> > C:\Program Files\rcpapp>dir /s /b
> > C:\Program Files\rcpapp\jre
> > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > C:\Program Files\rcpapp\jre\lib
> > C:\Program Files\rcpapp\jre\LICENSE
> > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > C:\Program Files\rcpapp\jre\lib\cmm
> > C:\Program Files\rcpapp\jre\lib\currency.data
> > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > C:\Program Files\rcpapp\jre\lib\management
> > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > C:\Program Files\rcpapp\jre\lib\management\jmxremote.password.template
> > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> >
> > Any ideas on why these files are not deleted? Could it be the
> INITIAL_DELAY
> > is too short in the cleaner.exe?
> >
> >
> https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff
> > dab8/nbi/engine/native/cleaner/windows/src/main.c#L28
> >
> > Thanks,
> > Christian
>
>
>

Re: Packaging JRE in RCP installer

[Oliver Rettig]

Hi,
I remember on such problems also with Netbeans 8.2. It had todo with access 
rights. I am 
interested in if you can figure it out.
best regards
Oliver
> Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> following these instructions?
> https://dzone.com/articles/including-jre-in-nbi
> 
> While this works fine under Linux , the Windows uninstaller does not delete
> some of the JRE files.
> 
> C:\Program Files\rcpapp>dir /s /b
> C:\Program Files\rcpapp\jre
> C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> C:\Program Files\rcpapp\jre\lib
> C:\Program Files\rcpapp\jre\LICENSE
> C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> C:\Program Files\rcpapp\jre\lib\cmm
> C:\Program Files\rcpapp\jre\lib\currency.data
> C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> C:\Program Files\rcpapp\jre\lib\management
> C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> C:\Program Files\rcpapp\jre\lib\management\jmxremote.password.template
> C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> 
> Any ideas on why these files are not deleted? Could it be the INITIAL_DELAY
> is too short in the cleaner.exe?
> 
> https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff
> dab8/nbi/engine/native/cleaner/windows/src/main.c#L28
> 
> Thanks,
> Christian

Re: Packaging JRE in RCP installer

[Emilian Bold]

Lars, those notes do deserve a wiki page indeed.

--emi

joi, 12 sept. 2019, 20:45 Lars Bruun-Hansen  a
scris:

> Hi Christian
>
> I once wrote some notes on how the cleaner works. (yes, they are
> probably worthy of a Wiki page, but currently the only exist here). It
> was written about 5 years ago, but I doubt it has changed. The notes
> are below and I think they are worth the read because I'm guessing
> they implicitly tell you what your problem is. Here we go:
>
>
> --- Begin notes ---
>
> Background
> --
> The "cleaner" is a small native application which is part of the
> NetBeans Installer (NBI) infrastructure. The job of the cleaner is to
> delete files which the JVM process for some reason cannot delete
> itself. Java has its own deleteOnExit() method but that method is
> pretty useless as it cannot delete files that the JVM itself uses.
> Hence the idea of a cleaner.
>
> NBI has two cleaners: One for Linux/Mac which is a shell script and
> one for Windows (cleaner.exe) which is a native image. The cleaner
> gets launched from Java at the end of the NBI install/uninstall
> process (from a shutdown hook). It gets launched in such a clever way
> that it becomes detached from the JVM process itself, hence it will
> live on even when the JVM process closes. On Unices such a process
> would be known as a 'daemon' and is created by a technique called
> double-fork. On Windows this is known as a 'process without handles'.
> Java doesn't support spawning such a process so NBI has to rely on
> native OS calls in order to create such a detached process.
>
> The cleaner works off a list of files to delete. It gets passed this
> list of files as an argument on the command line. The list is in a
> temporary file. The cleaner deletes this file after it has read it.
> The list of files is supposed to be ordered so the delete happens in
> the right sequence (you cannot delete a directory before you've
> deleted all files in it). This ordering is done automatically by the
> NBI Engine (nbi-engine.jar) so this is not something anyone creating
> an installer should worry about.
>
> The cleaner can delete both files and directories ...if they are
> empty. The cleaner has no feature for recursing through a directory
> and deleting all files below it. Therefore, in order to delete a tree,
> the cleaner must be told explicitly which files to delete and in which
> order.
>
>
>
> How does the cleaner work on Windows ?
> --
>
> On Windows the cleaner is a very small C program. It is (at the
> moment) always 32-bit regardless of JVM or Windows version.
>
> After launch the cleaner will read the list of files to delete from a
> temporary file. The list of files to delete is read into memory and
> the cleaner can therefore delete the temporary file immediately after
> it has been read.
>
> After reading the file list the cleaner sleeps for 2 seconds. This is
> to allow the JVM process that has started it to close down. The 2 secs
> are hardcoded.
>
> The cleaner will then loop over the list of files to delete. Each
> file-delete operation is spawned into a thread of its own up to a
> maximum of 64 threads. Therefore the delete operations happens in
> parallel rather than in sequence. (Note: I find this design somewhat
> dangerous as the order of delete can be quite important.).
>
> For each delete operation the cleaner will do the following:
>
> - Checks to see if the file exists (by getting its attributes)
> - If file: delete file, if directory: delete directory (these are
> two different calls in the Win32 API).
> - Attempt to delete each file/dir up to 15 times sleeping for 200
> ms between each attempt.
>
> If there are no available threads (i.e. there more than 64 files to
> delete) then the cleaner process will wait until a there are less than
> 64 active threads. In other words: At any point in time there are
> never more than 64 active threads.
>
> The cleaner process has absolutely no logging features so it is pretty
> difficult so say what it does if something goes wrong.
>
>
> --- End notes ---
>
> Those were my notes.
>
> I'm guessing the problem you see is that the cleaner cannot delete a
> file with read-only attribute set. Or it is the somewhat dangerous
> design of deleting files in parallel which is causing probs. I'm
> leaning towards the first one. Your own guess - the two secs delay - I
> don't much believe is the problem since the cleaner will attempt to
> delete each file 15 times sleeping 200 ms between each attempt.
>
>
> /Lars
>
> On Thu, Sep 12, 2019 at 3:48 PM Christian Oyarzun  wrote:
> >
> > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > following these instructions?
> > https://dzone.com/articles/including-jre-in-nbi
> >
> > While this works fine under Linux , the Windows uninstaller does not
> delete
> > some of the JRE files.
> >
> > C:\Program Files\rcpapp>dir /s /b
> > C:\Program Files\rcpapp\jre
> > C:\Program Files\rcpapp\j

Re: Packaging JRE in RCP installer

[Christian Oyarzun]

Hi Lars,

Thanks for the information. Your guess was correct, those files had the
read-only attribute set. Unsetting those attributes allowed the clearer to
remove
the files and top-level directory.

Thanks,
Christian

On Thu, Sep 12, 2019 at 1:45 PM Lars Bruun-Hansen 
wrote:

> Hi Christian
>
> I once wrote some notes on how the cleaner works. (yes, they are
> probably worthy of a Wiki page, but currently the only exist here). It
> was written about 5 years ago, but I doubt it has changed. The notes
> are below and I think they are worth the read because I'm guessing
> they implicitly tell you what your problem is. Here we go:
>
>
> --- Begin notes ---
>
> Background
> --
> The "cleaner" is a small native application which is part of the
> NetBeans Installer (NBI) infrastructure. The job of the cleaner is to
> delete files which the JVM process for some reason cannot delete
> itself. Java has its own deleteOnExit() method but that method is
> pretty useless as it cannot delete files that the JVM itself uses.
> Hence the idea of a cleaner.
>
> NBI has two cleaners: One for Linux/Mac which is a shell script and
> one for Windows (cleaner.exe) which is a native image. The cleaner
> gets launched from Java at the end of the NBI install/uninstall
> process (from a shutdown hook). It gets launched in such a clever way
> that it becomes detached from the JVM process itself, hence it will
> live on even when the JVM process closes. On Unices such a process
> would be known as a 'daemon' and is created by a technique called
> double-fork. On Windows this is known as a 'process without handles'.
> Java doesn't support spawning such a process so NBI has to rely on
> native OS calls in order to create such a detached process.
>
> The cleaner works off a list of files to delete. It gets passed this
> list of files as an argument on the command line. The list is in a
> temporary file. The cleaner deletes this file after it has read it.
> The list of files is supposed to be ordered so the delete happens in
> the right sequence (you cannot delete a directory before you've
> deleted all files in it). This ordering is done automatically by the
> NBI Engine (nbi-engine.jar) so this is not something anyone creating
> an installer should worry about.
>
> The cleaner can delete both files and directories ...if they are
> empty. The cleaner has no feature for recursing through a directory
> and deleting all files below it. Therefore, in order to delete a tree,
> the cleaner must be told explicitly which files to delete and in which
> order.
>
>
>
> How does the cleaner work on Windows ?
> --
>
> On Windows the cleaner is a very small C program. It is (at the
> moment) always 32-bit regardless of JVM or Windows version.
>
> After launch the cleaner will read the list of files to delete from a
> temporary file. The list of files to delete is read into memory and
> the cleaner can therefore delete the temporary file immediately after
> it has been read.
>
> After reading the file list the cleaner sleeps for 2 seconds. This is
> to allow the JVM process that has started it to close down. The 2 secs
> are hardcoded.
>
> The cleaner will then loop over the list of files to delete. Each
> file-delete operation is spawned into a thread of its own up to a
> maximum of 64 threads. Therefore the delete operations happens in
> parallel rather than in sequence. (Note: I find this design somewhat
> dangerous as the order of delete can be quite important.).
>
> For each delete operation the cleaner will do the following:
>
> - Checks to see if the file exists (by getting its attributes)
> - If file: delete file, if directory: delete directory (these are
> two different calls in the Win32 API).
> - Attempt to delete each file/dir up to 15 times sleeping for 200
> ms between each attempt.
>
> If there are no available threads (i.e. there more than 64 files to
> delete) then the cleaner process will wait until a there are less than
> 64 active threads. In other words: At any point in time there are
> never more than 64 active threads.
>
> The cleaner process has absolutely no logging features so it is pretty
> difficult so say what it does if something goes wrong.
>
>
> --- End notes ---
>
> Those were my notes.
>
> I'm guessing the problem you see is that the cleaner cannot delete a
> file with read-only attribute set. Or it is the somewhat dangerous
> design of deleting files in parallel which is causing probs. I'm
> leaning towards the first one. Your own guess - the two secs delay - I
> don't much believe is the problem since the cleaner will attempt to
> delete each file 15 times sleeping 200 ms between each attempt.
>
>
> /Lars
>
> On Thu, Sep 12, 2019 at 3:48 PM Christian Oyarzun  wrote:
> >
> > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > following these instructions?
> > https://dzone.com/articles/including-jre-in-nbi
> >
> > While this works fine under Linux , the Wi

Re: updating the interface for a module or java file..

[Matthias Bläsing]

Hi Brad,

Am Mittwoch, den 11.09.2019, 13:46 -0600 schrieb Brad Walker:
> Let's say that I've cleaned up all references to a deprecated method.
> 
> Now I want to remove the deprecated method since no one is using it.
> 
> Don't I have to update the interface definition? And if so, how does one go
> about doing this?

as in all important cases: It depends.

If the module does not export the class that holds the method, there
could be modules, that have an implementation depedency on the module.
Grepping through the codebase should give you a feeling, whether or not
the class is imported somewhere.

If the module exports the class, don't remove the method if it works.
Deprecated methods don't need to be removed if there is no reason to. A
reason would be, that method is broken or the module is going through a
API break anyway.

>From your PM to me you are describing a different case:

   I'm tyring to cleanup some old code that deals with Generics..

   For example, in the following file
   ./profiler/lib.profiler/src/org/netbeans/lib/profiler/heap/ClassDump.java

   You will find the following method..
   public List /**/ getFields() {

   Since this method is public, if I change it there will be an interface 
update needed, correct?

   Can you tell me what I need to do to implement a change like this?

_That_ is a different matter and there is only one try to get it right.
Adding generics to method signatures in java is generally save,
changing them is not.

So once you can just add the generic, increase the module spec version
and be done.

In the above sample however it looks as if there was a good reason to
have it, maybe Jan Lahoda can help with the reasoning.

HTH

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://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: bits.netbeans.org vs netbeans.apache.org

[Geertjan Wielenga]

Fair enough, whatever works. :-)

Gj

On Thu, 12 Sep 2019 at 19:34, Matthias Bläsing 
wrote:

> Hi Geertjan,
>
> Am Donnerstag, den 12.09.2019, 18:54 +0200 schrieb Geertjan Wielenga:
> > Amount of data is a question of downloading the bits you want and then
> > seeing how large that is.
>
> don't take this wrong, but that approach is the worst way to determine
> the amount of data. Someone with access to the server could do it in
> minutes (invocation of `du -sh` on the CLI are trivial), you don't need
> to transfer GBs of data just to throw them away.
>
> Greetings
>
> Matthias, who remembers times when ISDN (64kbit/s) was blazing fast
>
>
> -
> 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: Packaging JRE in RCP installer

[Lars Bruun-Hansen]

Hi Christian

I once wrote some notes on how the cleaner works. (yes, they are
probably worthy of a Wiki page, but currently the only exist here). It
was written about 5 years ago, but I doubt it has changed. The notes
are below and I think they are worth the read because I'm guessing
they implicitly tell you what your problem is. Here we go:


--- Begin notes ---

Background
--
The "cleaner" is a small native application which is part of the
NetBeans Installer (NBI) infrastructure. The job of the cleaner is to
delete files which the JVM process for some reason cannot delete
itself. Java has its own deleteOnExit() method but that method is
pretty useless as it cannot delete files that the JVM itself uses.
Hence the idea of a cleaner.

NBI has two cleaners: One for Linux/Mac which is a shell script and
one for Windows (cleaner.exe) which is a native image. The cleaner
gets launched from Java at the end of the NBI install/uninstall
process (from a shutdown hook). It gets launched in such a clever way
that it becomes detached from the JVM process itself, hence it will
live on even when the JVM process closes. On Unices such a process
would be known as a 'daemon' and is created by a technique called
double-fork. On Windows this is known as a 'process without handles'.
Java doesn't support spawning such a process so NBI has to rely on
native OS calls in order to create such a detached process.

The cleaner works off a list of files to delete. It gets passed this
list of files as an argument on the command line. The list is in a
temporary file. The cleaner deletes this file after it has read it.
The list of files is supposed to be ordered so the delete happens in
the right sequence (you cannot delete a directory before you've
deleted all files in it). This ordering is done automatically by the
NBI Engine (nbi-engine.jar) so this is not something anyone creating
an installer should worry about.

The cleaner can delete both files and directories ...if they are
empty. The cleaner has no feature for recursing through a directory
and deleting all files below it. Therefore, in order to delete a tree,
the cleaner must be told explicitly which files to delete and in which
order.



How does the cleaner work on Windows ?
--

On Windows the cleaner is a very small C program. It is (at the
moment) always 32-bit regardless of JVM or Windows version.

After launch the cleaner will read the list of files to delete from a
temporary file. The list of files to delete is read into memory and
the cleaner can therefore delete the temporary file immediately after
it has been read.

After reading the file list the cleaner sleeps for 2 seconds. This is
to allow the JVM process that has started it to close down. The 2 secs
are hardcoded.

The cleaner will then loop over the list of files to delete. Each
file-delete operation is spawned into a thread of its own up to a
maximum of 64 threads. Therefore the delete operations happens in
parallel rather than in sequence. (Note: I find this design somewhat
dangerous as the order of delete can be quite important.).

For each delete operation the cleaner will do the following:

- Checks to see if the file exists (by getting its attributes)
- If file: delete file, if directory: delete directory (these are
two different calls in the Win32 API).
- Attempt to delete each file/dir up to 15 times sleeping for 200
ms between each attempt.

If there are no available threads (i.e. there more than 64 files to
delete) then the cleaner process will wait until a there are less than
64 active threads. In other words: At any point in time there are
never more than 64 active threads.

The cleaner process has absolutely no logging features so it is pretty
difficult so say what it does if something goes wrong.


--- End notes ---

Those were my notes.

I'm guessing the problem you see is that the cleaner cannot delete a
file with read-only attribute set. Or it is the somewhat dangerous
design of deleting files in parallel which is causing probs. I'm
leaning towards the first one. Your own guess - the two secs delay - I
don't much believe is the problem since the cleaner will attempt to
delete each file 15 times sleeping 200 ms between each attempt.


/Lars

On Thu, Sep 12, 2019 at 3:48 PM Christian Oyarzun  wrote:
>
> Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> following these instructions?
> https://dzone.com/articles/including-jre-in-nbi
>
> While this works fine under Linux , the Windows uninstaller does not delete
> some of the JRE files.
>
> C:\Program Files\rcpapp>dir /s /b
> C:\Program Files\rcpapp\jre
> C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> C:\Program Files\rcpapp\jre\lib
> C:\Program Files\rcpapp\jre\LICENSE
> C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> C:\Program Files\rcpapp\jre\lib\cmm
> C:\Program Files\rcpapp\jre\lib\currency.data
> C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> C:\Program Files\rcpapp\jre\lib\m

Re: bits.netbeans.org vs netbeans.apache.org

[Matthias Bläsing]

Hi Geertjan,

Am Donnerstag, den 12.09.2019, 18:54 +0200 schrieb Geertjan Wielenga:
> Amount of data is a question of downloading the bits you want and then
> seeing how large that is.

don't take this wrong, but that approach is the worst way to determine
the amount of data. Someone with access to the server could do it in
minutes (invocation of `du -sh` on the CLI are trivial), you don't need
to transfer GBs of data just to throw them away.

Greetings

Matthias, who remembers times when ISDN (64kbit/s) was blazing fast


-
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: bits.netbeans.org vs netbeans.apache.org

[Geertjan Wielenga]

Amount of data is a question of downloading the bits you want and then
seeing how large that is.

I don’t see anyone asking about anything other than 8.2 so far.

Gj

On Thu, 12 Sep 2019 at 17:19, Matthias Bläsing 
wrote:

> Hi,
>
> Am Donnerstag, den 12.09.2019, 17:12 +0200 schrieb Geertjan Wielenga:
> > Sure, everything. But indeed let's start with what we need most, i.e.,
> 8.2
> > related artefacts.
> >
> > You're the one who set up the OSUOSL storage, would be happy to help, but
> > if you suggest some kind of structure and a process with steps for
> getting
> > artefacts up there, I'd be happy to do it or be involved in doing it.
> >
>
> should we give OSUOSL a heads-up about the inflow of data (planned
> timeframe and amount of data)?
>
> 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://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Current state of Oracle donation of NetBeans to Apache

[Laszlo Kishalmi]

It seems I've skimmed that part. Wasn't expecting it that early. Good 
news! Thank you!


On 9/11/19 9:33 PM, Geertjan Wielenga wrote:

See the initial post here about the 4th donation re the dark look and feel.

Gj

On Thu, 12 Sep 2019 at 05:13, Laszlo Kishalmi 
wrote:


Hi Geertjan,

I know it is a minor point, but were you successful to schedule the dark
theme support ahead from the last donation?

Darcula is kind of depending on that one, though maybe one or two
classes form them.

On 9/11/19 1:02 AM, Geertjan Wielenga wrote:

Hi all,

Long-ish e-mail on current status, with helpful headers in between.

*4th Donation*

The 4th donation, focused primarily on C/C++ support has gone through
auditing and we're satisfied that what we're donating to Apache from

Oracle

really is Oracle's to donate. The source code is now in a ZIP file at
Oracle Legal, after which documents need to be signed, and then the 4th
donation will be complete and the code handed over to Apache.
The o.n.swing.laf.dark mlodule is also included in the 4th donation.

This will be done soon but not soon enough to be included in the 11.2
release -- since aside from donating the code, there'll be quite some

work

of relicensing everything to Apache and getting everything to work
correctly within Apache NetBeans. It looks to me like the 11.3 release,
scheduled for January[1] should be able to include the C/C++ features,
assuming the donation and integration is complete in that timeframe.

*5th Donation*

After that is the 5th donation, which will focus on the clusters
nb.cluster.dlight and nb.cluster.extra. The C/C++ modules have a

build-time

dependency on nb.cluster.dlight so until the 5th donation is done, we'll
need to depend on a binary at build time of the relevant parts of that
cluster. Included in this donation will be the source code of the Jira
module, as requested on this mailing list.

*Contrib Repository*

In parallel, there's the question of the 'contrib' cluster. Some of the
modules in there were experimental plugins written by Oracle employees
while others are under the OCA (Oracle Contributor Agreement) by external
third party contributors. The latter should probably simply be able to
donate their modules to Apache NetBeans, without Oracle needing to be
involved in any way. However, we're getting Oracle Legal opinion on this,
just to be sure. And we probably don't want all of the contrib repository
anyway, some clear guidance from the community here would help.

*And then...*

After the above have been handled, the question is what to deal with

next,

if anything.

We have these listed for donation but the question is whether anyone is
waiting for these or actually going to be working on them:

nb.cluster.javacard
nb.cluster.mobility
community-ruby
community-soa
community-uml
community-visualweb

What is the level of interest in the above areas of NetBeans? If you're
going to write in response "we must really have this in Apache NetBeans"
will you also be the one driving that code forward, adding new features,
and fixing related bugs yourself?

The transition page[2] has been updated to reflect the above.

[1]

https://cwiki.apache.org/confluence/display/NETBEANS/Release+Schedule

[2]

https://cwiki.apache.org/confluence/display/NETBEANS/Apache+Transition

Thanks,

Gj


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists






-
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: bits.netbeans.org vs netbeans.apache.org

[Matthias Bläsing]

Hi,

Am Donnerstag, den 12.09.2019, 17:12 +0200 schrieb Geertjan Wielenga:
> Sure, everything. But indeed let's start with what we need most, i.e., 8.2
> related artefacts.
> 
> You're the one who set up the OSUOSL storage, would be happy to help, but
> if you suggest some kind of structure and a process with steps for getting
> artefacts up there, I'd be happy to do it or be involved in doing it.
> 

should we give OSUOSL a heads-up about the inflow of data (planned
timeframe and amount of data)?

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://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: bits.netbeans.org vs netbeans.apache.org

[Geertjan Wielenga]

Sure, everything. But indeed let's start with what we need most, i.e., 8.2
related artefacts.

You're the one who set up the OSUOSL storage, would be happy to help, but
if you suggest some kind of structure and a process with steps for getting
artefacts up there, I'd be happy to do it or be involved in doing it.

Gj

On Thu, Sep 12, 2019 at 5:06 PM Emilian Bold  wrote:

> I would move *everything* public facing that's on bits.netbeans.org.
> No need to purge anything if it's under an open-source license and
> OSUOSL can redistribute it.
>
> Older builds, older Maven repositories, maybe even Javadocs?
>
> On top of my list would be NetBeans 8.2 and the 8.2 maven repo.
>
> --emi
>
> On Thu, Sep 12, 2019 at 5:57 PM Geertjan Wielenga 
> wrote:
> >
> > Sure, let's do it, but for me the question is what precisely we want to
> > move to OSUOSL storage, if we can have a list or start putting one
> > together, we'll have a clear starting point.
> >
> > Gj
> >
> > On Thu, Sep 12, 2019 at 4:53 PM Emilian Bold 
> wrote:
> >
> > > Doesn't sound silly at all. I was also very concerned about such
> > > matters. Now that we have the OSUOSL storage we have a place to save
> > > historical artifacts, it's just a matter of somebody (from the PMC, I
> > > guess) doing it.
> > >
> > > Besides the bits, you will find that bugzill is quite referenced in
> > > commits, etc and needs preserving.
> > >
> > > As is probably Geertjan's blog :-)
> > >
> > > --emi
> > >
> > > On Thu, Sep 12, 2019 at 4:23 PM Jean-Marc Borer 
> wrote:
> > > >
> > > > Hmm ok.
> > > >
> > > > Does it sound silly that I am concerned about the disappearance of
> the
> > > > legacy artefacts?
> > > >
> > > > What is you opinion and shall we invest any effort to save those
> > > artefacts?
> > > >
> > > > JMB
> > > >
> > > > On Thu, Sep 12, 2019 at 11:59 AM Emilian Bold <
> emilian.b...@gmail.com>
> > > > wrote:
> > > >
> > > > > I doubt it will be live a few more years. Another year max under
> Oracle
> > > > > IMHO. Under Apache it won't serve those old bits from Apache infra
> but
> > > > > could use OSUOSL.
> > > > >
> > > > > --emi
> > > > >
> > > > > joi, 12 sept. 2019, 14:46 Jean-Marc Borer  a
> scris:
> > > > >
> > > > > > Sure, I understand all those points, but does anyone know how
> long
> > > > > > bits.netbeans.org will still be online? Last week, there was an
> > > outage
> > > > > > and,
> > > > > > of course, exactly when I was testing our new artifactory. That
> is
> > > why I
> > > > > > started wondering.
> > > > > >
> > > > > > If the bits.netbeans.org will remain live during a few years,
> then
> > > it is
> > > > > > not an issue we should spend time on. So does anyone know what
> the
> > > plans
> > > > > > are for bits.netbeans.org?
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > >
> > > > > > On Thu, Sep 12, 2019 at 9:50 AM Neil C Smith <
> neilcsm...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > On Thu, 12 Sep 2019, 09:48 Eric Barboni, 
> wrote:
> > > > > > >
> > > > > > > >  We could not move the artefacts to central because of the
> > > licence
> > > > > and
> > > > > > > the
> > > > > > > > groupid that are now for Apache NetBeans.
> > > > > > > >
> > > > > > >
> > > > > > > I'm not sure this is correct. At least, I remember us getting
> some
> > > > > advice
> > > > > > > about pre-Apache release artefacts that might allow for this.
> We
> > > should
> > > > > > at
> > > > > > > least clarify this point and not make extra work unnecessarily.
> > > > > > >
> > > > > > > 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: bits.netbeans.org vs netbeans.apache.org

[Emilian Bold]

I would move *everything* public facing that's on bits.netbeans.org.
No need to purge anything if it's under an open-source license and
OSUOSL can redistribute it.

Older builds, older Maven repositories, maybe even Javadocs?

On top of my list would be NetBeans 8.2 and the 8.2 maven repo.

--emi

On Thu, Sep 12, 2019 at 5:57 PM Geertjan Wielenga  wrote:
>
> Sure, let's do it, but for me the question is what precisely we want to
> move to OSUOSL storage, if we can have a list or start putting one
> together, we'll have a clear starting point.
>
> Gj
>
> On Thu, Sep 12, 2019 at 4:53 PM Emilian Bold  wrote:
>
> > Doesn't sound silly at all. I was also very concerned about such
> > matters. Now that we have the OSUOSL storage we have a place to save
> > historical artifacts, it's just a matter of somebody (from the PMC, I
> > guess) doing it.
> >
> > Besides the bits, you will find that bugzill is quite referenced in
> > commits, etc and needs preserving.
> >
> > As is probably Geertjan's blog :-)
> >
> > --emi
> >
> > On Thu, Sep 12, 2019 at 4:23 PM Jean-Marc Borer  wrote:
> > >
> > > Hmm ok.
> > >
> > > Does it sound silly that I am concerned about the disappearance of the
> > > legacy artefacts?
> > >
> > > What is you opinion and shall we invest any effort to save those
> > artefacts?
> > >
> > > JMB
> > >
> > > On Thu, Sep 12, 2019 at 11:59 AM Emilian Bold 
> > > wrote:
> > >
> > > > I doubt it will be live a few more years. Another year max under Oracle
> > > > IMHO. Under Apache it won't serve those old bits from Apache infra but
> > > > could use OSUOSL.
> > > >
> > > > --emi
> > > >
> > > > joi, 12 sept. 2019, 14:46 Jean-Marc Borer  a scris:
> > > >
> > > > > Sure, I understand all those points, but does anyone know how long
> > > > > bits.netbeans.org will still be online? Last week, there was an
> > outage
> > > > > and,
> > > > > of course, exactly when I was testing our new artifactory. That is
> > why I
> > > > > started wondering.
> > > > >
> > > > > If the bits.netbeans.org will remain live during a few years, then
> > it is
> > > > > not an issue we should spend time on. So does anyone know what the
> > plans
> > > > > are for bits.netbeans.org?
> > > > >
> > > > > Cheers,
> > > > >
> > > > >
> > > > > On Thu, Sep 12, 2019 at 9:50 AM Neil C Smith 
> > > > > wrote:
> > > > >
> > > > > > On Thu, 12 Sep 2019, 09:48 Eric Barboni,  wrote:
> > > > > >
> > > > > > >  We could not move the artefacts to central because of the
> > licence
> > > > and
> > > > > > the
> > > > > > > groupid that are now for Apache NetBeans.
> > > > > > >
> > > > > >
> > > > > > I'm not sure this is correct. At least, I remember us getting some
> > > > advice
> > > > > > about pre-Apache release artefacts that might allow for this. We
> > should
> > > > > at
> > > > > > least clarify this point and not make extra work unnecessarily.
> > > > > >
> > > > > > 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: bits.netbeans.org vs netbeans.apache.org

[Geertjan Wielenga]

Sure, let's do it, but for me the question is what precisely we want to
move to OSUOSL storage, if we can have a list or start putting one
together, we'll have a clear starting point.

Gj

On Thu, Sep 12, 2019 at 4:53 PM Emilian Bold  wrote:

> Doesn't sound silly at all. I was also very concerned about such
> matters. Now that we have the OSUOSL storage we have a place to save
> historical artifacts, it's just a matter of somebody (from the PMC, I
> guess) doing it.
>
> Besides the bits, you will find that bugzill is quite referenced in
> commits, etc and needs preserving.
>
> As is probably Geertjan's blog :-)
>
> --emi
>
> On Thu, Sep 12, 2019 at 4:23 PM Jean-Marc Borer  wrote:
> >
> > Hmm ok.
> >
> > Does it sound silly that I am concerned about the disappearance of the
> > legacy artefacts?
> >
> > What is you opinion and shall we invest any effort to save those
> artefacts?
> >
> > JMB
> >
> > On Thu, Sep 12, 2019 at 11:59 AM Emilian Bold 
> > wrote:
> >
> > > I doubt it will be live a few more years. Another year max under Oracle
> > > IMHO. Under Apache it won't serve those old bits from Apache infra but
> > > could use OSUOSL.
> > >
> > > --emi
> > >
> > > joi, 12 sept. 2019, 14:46 Jean-Marc Borer  a scris:
> > >
> > > > Sure, I understand all those points, but does anyone know how long
> > > > bits.netbeans.org will still be online? Last week, there was an
> outage
> > > > and,
> > > > of course, exactly when I was testing our new artifactory. That is
> why I
> > > > started wondering.
> > > >
> > > > If the bits.netbeans.org will remain live during a few years, then
> it is
> > > > not an issue we should spend time on. So does anyone know what the
> plans
> > > > are for bits.netbeans.org?
> > > >
> > > > Cheers,
> > > >
> > > >
> > > > On Thu, Sep 12, 2019 at 9:50 AM Neil C Smith 
> > > > wrote:
> > > >
> > > > > On Thu, 12 Sep 2019, 09:48 Eric Barboni,  wrote:
> > > > >
> > > > > >  We could not move the artefacts to central because of the
> licence
> > > and
> > > > > the
> > > > > > groupid that are now for Apache NetBeans.
> > > > > >
> > > > >
> > > > > I'm not sure this is correct. At least, I remember us getting some
> > > advice
> > > > > about pre-Apache release artefacts that might allow for this. We
> should
> > > > at
> > > > > least clarify this point and not make extra work unnecessarily.
> > > > >
> > > > > 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: bits.netbeans.org vs netbeans.apache.org

[Emilian Bold]

Doesn't sound silly at all. I was also very concerned about such
matters. Now that we have the OSUOSL storage we have a place to save
historical artifacts, it's just a matter of somebody (from the PMC, I
guess) doing it.

Besides the bits, you will find that bugzill is quite referenced in
commits, etc and needs preserving.

As is probably Geertjan's blog :-)

--emi

On Thu, Sep 12, 2019 at 4:23 PM Jean-Marc Borer  wrote:
>
> Hmm ok.
>
> Does it sound silly that I am concerned about the disappearance of the
> legacy artefacts?
>
> What is you opinion and shall we invest any effort to save those artefacts?
>
> JMB
>
> On Thu, Sep 12, 2019 at 11:59 AM Emilian Bold 
> wrote:
>
> > I doubt it will be live a few more years. Another year max under Oracle
> > IMHO. Under Apache it won't serve those old bits from Apache infra but
> > could use OSUOSL.
> >
> > --emi
> >
> > joi, 12 sept. 2019, 14:46 Jean-Marc Borer  a scris:
> >
> > > Sure, I understand all those points, but does anyone know how long
> > > bits.netbeans.org will still be online? Last week, there was an outage
> > > and,
> > > of course, exactly when I was testing our new artifactory. That is why I
> > > started wondering.
> > >
> > > If the bits.netbeans.org will remain live during a few years, then it is
> > > not an issue we should spend time on. So does anyone know what the plans
> > > are for bits.netbeans.org?
> > >
> > > Cheers,
> > >
> > >
> > > On Thu, Sep 12, 2019 at 9:50 AM Neil C Smith 
> > > wrote:
> > >
> > > > On Thu, 12 Sep 2019, 09:48 Eric Barboni,  wrote:
> > > >
> > > > >  We could not move the artefacts to central because of the licence
> > and
> > > > the
> > > > > groupid that are now for Apache NetBeans.
> > > > >
> > > >
> > > > I'm not sure this is correct. At least, I remember us getting some
> > advice
> > > > about pre-Apache release artefacts that might allow for this. We should
> > > at
> > > > least clarify this point and not make extra work unnecessarily.
> > > >
> > > > 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: bits.netbeans.org vs netbeans.apache.org

[Geertjan Wielenga]

On Thu, Sep 12, 2019 at 1:46 PM Jean-Marc Borer  wrote:

> Sure, I understand all those points, but does anyone know how long
> bits.netbeans.org will still be online? Last week, there was an outage


An outage of bits.netbeans.org?

Or do you specifically mean http://bits.netbeans.org/maven2?

Whenever you encounter an outage of anything NetBeans related, can you send
me a quick mail so it can be fixed?

Gj




> and,
> of course, exactly when I was testing our new artifactory. That is why I
> started wondering.
>
> If the bits.netbeans.org will remain live during a few years, then it is
> not an issue we should spend time on. So does anyone know what the plans
> are for bits.netbeans.org?
>
> Cheers,
>
>
> On Thu, Sep 12, 2019 at 9:50 AM Neil C Smith 
> wrote:
>
> > On Thu, 12 Sep 2019, 09:48 Eric Barboni,  wrote:
> >
> > >  We could not move the artefacts to central because of the licence and
> > the
> > > groupid that are now for Apache NetBeans.
> > >
> >
> > I'm not sure this is correct. At least, I remember us getting some advice
> > about pre-Apache release artefacts that might allow for this. We should
> at
> > least clarify this point and not make extra work unnecessarily.
> >
> > Best wishes,
> >
> > Neil
> >
>

Re: bits.netbeans.org vs netbeans.apache.org

[Geertjan Wielenga]

Which artefacts are we talking about?

Gj

On Thu, Sep 12, 2019 at 3:23 PM Jean-Marc Borer  wrote:

> Hmm ok.
>
> Does it sound silly that I am concerned about the disappearance of the
> legacy artefacts?
>
> What is you opinion and shall we invest any effort to save those artefacts?
>
> JMB
>
> On Thu, Sep 12, 2019 at 11:59 AM Emilian Bold 
> wrote:
>
> > I doubt it will be live a few more years. Another year max under Oracle
> > IMHO. Under Apache it won't serve those old bits from Apache infra but
> > could use OSUOSL.
> >
> > --emi
> >
> > joi, 12 sept. 2019, 14:46 Jean-Marc Borer  a scris:
> >
> > > Sure, I understand all those points, but does anyone know how long
> > > bits.netbeans.org will still be online? Last week, there was an outage
> > > and,
> > > of course, exactly when I was testing our new artifactory. That is why
> I
> > > started wondering.
> > >
> > > If the bits.netbeans.org will remain live during a few years, then it
> is
> > > not an issue we should spend time on. So does anyone know what the
> plans
> > > are for bits.netbeans.org?
> > >
> > > Cheers,
> > >
> > >
> > > On Thu, Sep 12, 2019 at 9:50 AM Neil C Smith 
> > > wrote:
> > >
> > > > On Thu, 12 Sep 2019, 09:48 Eric Barboni,  wrote:
> > > >
> > > > >  We could not move the artefacts to central because of the licence
> > and
> > > > the
> > > > > groupid that are now for Apache NetBeans.
> > > > >
> > > >
> > > > I'm not sure this is correct. At least, I remember us getting some
> > advice
> > > > about pre-Apache release artefacts that might allow for this. We
> should
> > > at
> > > > least clarify this point and not make extra work unnecessarily.
> > > >
> > > > Best wishes,
> > > >
> > > > Neil
> > > >
> > >
> >
>

Packaging JRE in RCP installer

[Christian Oyarzun]

Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
following these instructions?
https://dzone.com/articles/including-jre-in-nbi

While this works fine under Linux , the Windows uninstaller does not delete
some of the JRE files.

C:\Program Files\rcpapp>dir /s /b
C:\Program Files\rcpapp\jre
C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
C:\Program Files\rcpapp\jre\lib
C:\Program Files\rcpapp\jre\LICENSE
C:\Program Files\rcpapp\jre\THIRD_PARTY_README
C:\Program Files\rcpapp\jre\lib\cmm
C:\Program Files\rcpapp\jre\lib\currency.data
C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
C:\Program Files\rcpapp\jre\lib\management
C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
C:\Program Files\rcpapp\jre\lib\management\jmxremote.password.template
C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template

Any ideas on why these files are not deleted? Could it be the INITIAL_DELAY
is too short in the cleaner.exe?

https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561affdab8/nbi/engine/native/cleaner/windows/src/main.c#L28

Thanks,
Christian

Re: Have we got any *runtime* performance tests?

[Jean-Marc Borer]

Hi Tim,

If file access is improved that may also improve indexing and by
consequence symbol finding or refactoring. Did you try such operations to
check the difference in speed?

Cheers,

JMB

On Sun, Aug 18, 2019 at 8:47 AM Tim Boudreau  wrote:

> I've been playing with some tweaks to masterfs - specifically, I had a
> library i wrote for a completely different purpose, which keeps a cache of
> open NIO FileChannels.  Partly out of curiosity, and partly because I've
> wondered for a while what using NIO more for File IO in NetBeans might
> accomplish, I dropped it into masterfs.
>
> Basically, opening a file opens a file channel (the cache key includes the
> read/write/truncate options), which is cached, and closed after 60 seconds
> if it has not been touched.  Input and output streams just take a lock on
> the stream, set its state back to what it was when they last touched it,
> and then release the lock.
>
> Subjective impression, after running with these patches for about a week is
> that my machine is quieter and the IDE snappier - which makes some sense,
> since simply editing a file can trigger a bunch of reads of related file,
> so this is dramatically reducing interaction with the OS (in the back of my
> mind, I'm wondering if some of the Windows file-stat performance problems
> could be bypassed by checking if an open channel exists for some file -
> thought you might need to at least try to position the channel to trigger
> the IDE noticing if it had been deleted and the channel was invalid).
>
> What would be useful to actually measure if my perception matches reality
> would be some performance tests (not startup performance!!) that open a
> large number of projects and files, perform edits, switch between things,
> and take timings for those operations.  I have the vague sense that such
> might exist from one or another round of performance tuning years ago, but
> I have no idea where.
>
> Any ideas?
>
> If anyone wants to play with this stuff, it's on the nio-mfs branch of my
> fork here:
> https://github.com/timboudreau/incubator-netbeans/tree/nio-mfs
>
> (for the time being I just copied the code from three libraries of mine
> that live elsewhere;  ideally they would be used as libraries instead, but
> it was a quick bit of patching to see if it was even useful to try this)
>
> -Tim
>
> --
> http://timboudreau.com
>

Re: bits.netbeans.org vs netbeans.apache.org

[Jean-Marc Borer]

Hmm ok.

Does it sound silly that I am concerned about the disappearance of the
legacy artefacts?

What is you opinion and shall we invest any effort to save those artefacts?

JMB

On Thu, Sep 12, 2019 at 11:59 AM Emilian Bold 
wrote:

> I doubt it will be live a few more years. Another year max under Oracle
> IMHO. Under Apache it won't serve those old bits from Apache infra but
> could use OSUOSL.
>
> --emi
>
> joi, 12 sept. 2019, 14:46 Jean-Marc Borer  a scris:
>
> > Sure, I understand all those points, but does anyone know how long
> > bits.netbeans.org will still be online? Last week, there was an outage
> > and,
> > of course, exactly when I was testing our new artifactory. That is why I
> > started wondering.
> >
> > If the bits.netbeans.org will remain live during a few years, then it is
> > not an issue we should spend time on. So does anyone know what the plans
> > are for bits.netbeans.org?
> >
> > Cheers,
> >
> >
> > On Thu, Sep 12, 2019 at 9:50 AM Neil C Smith 
> > wrote:
> >
> > > On Thu, 12 Sep 2019, 09:48 Eric Barboni,  wrote:
> > >
> > > >  We could not move the artefacts to central because of the licence
> and
> > > the
> > > > groupid that are now for Apache NetBeans.
> > > >
> > >
> > > I'm not sure this is correct. At least, I remember us getting some
> advice
> > > about pre-Apache release artefacts that might allow for this. We should
> > at
> > > least clarify this point and not make extra work unnecessarily.
> > >
> > > Best wishes,
> > >
> > > Neil
> > >
> >
>

Re: James Gosling on NetBeans at ApacheCon today

[Zoran Sevarac]

Huge recognition for Apache NetBeans

On Thu, Sep 12, 2019 at 2:59 AM Kai Uwe Pel  wrote:

> Wow, that's amazing news!
> Thanks for the update.
>
> Regards,
> Kai
>
> On 9/11/2019 11:11 PM, Geertjan Wielenga wrote:
> > Hi all,
> >
> > I’d like to highlight the fact that one of our PMC members and
> committers,
> > none other than James Gosling, did a keynote today at ApacheCon where he
> > praised and thanked the Apache Incubator, and all the infrastructure
> around
> > it (e.g., our amazing mentors) for our progress in becoming a top level
> > project over the past months.
> >
> > See:
> >
> > https://mobile.twitter.com/TheASF/status/1171824558971637761
> >
> > Thanks James for always saying it like it is and for being such an
> > authentic ambassador for Apache NetBeans.
> >
> > Gj
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

-- 
Zoran Sevarac, PhD, Associate Professor
Department of Software Engineering
University of Belgrade, Faculty of Organisational Sciences

Deep Netts   Co-founder & CEO  | Oracle
Groundbreaker Ambassador | Java Champion

Open source: Neuroph founder, Apache Net
Beans  contributor
Homepage: http://www.zoransevarac.com

Re: Current state of Oracle donation of NetBeans to Apache

[Jean-Marc Borer]

Ruby support shall be kept.

>
> > community-soa
> >
>
> Misguided junk to sell to managers who don't understand technology, so they
> can torture their employees with it.
>

😂

That is so true! Send it to /dev/null, but: I am still obliged use SoapUI
on a regular base. This tool is so a nightmare to use that I often think to
rewrite something similar (but simpler) in NB IDE. Are there useful modules
then in the SOA stack that I could reuse?

UML, well, it is still required sometimes and there are no good free
alternatives. So I vote to keep it.

My 2 cents

Re: bits.netbeans.org vs netbeans.apache.org

[Emilian Bold]

I doubt it will be live a few more years. Another year max under Oracle
IMHO. Under Apache it won't serve those old bits from Apache infra but
could use OSUOSL.

--emi

joi, 12 sept. 2019, 14:46 Jean-Marc Borer  a scris:

> Sure, I understand all those points, but does anyone know how long
> bits.netbeans.org will still be online? Last week, there was an outage
> and,
> of course, exactly when I was testing our new artifactory. That is why I
> started wondering.
>
> If the bits.netbeans.org will remain live during a few years, then it is
> not an issue we should spend time on. So does anyone know what the plans
> are for bits.netbeans.org?
>
> Cheers,
>
>
> On Thu, Sep 12, 2019 at 9:50 AM Neil C Smith 
> wrote:
>
> > On Thu, 12 Sep 2019, 09:48 Eric Barboni,  wrote:
> >
> > >  We could not move the artefacts to central because of the licence and
> > the
> > > groupid that are now for Apache NetBeans.
> > >
> >
> > I'm not sure this is correct. At least, I remember us getting some advice
> > about pre-Apache release artefacts that might allow for this. We should
> at
> > least clarify this point and not make extra work unnecessarily.
> >
> > Best wishes,
> >
> > Neil
> >
>

Re: bits.netbeans.org vs netbeans.apache.org

[Jean-Marc Borer]

Sure, I understand all those points, but does anyone know how long
bits.netbeans.org will still be online? Last week, there was an outage and,
of course, exactly when I was testing our new artifactory. That is why I
started wondering.

If the bits.netbeans.org will remain live during a few years, then it is
not an issue we should spend time on. So does anyone know what the plans
are for bits.netbeans.org?

Cheers,


On Thu, Sep 12, 2019 at 9:50 AM Neil C Smith  wrote:

> On Thu, 12 Sep 2019, 09:48 Eric Barboni,  wrote:
>
> >  We could not move the artefacts to central because of the licence and
> the
> > groupid that are now for Apache NetBeans.
> >
>
> I'm not sure this is correct. At least, I remember us getting some advice
> about pre-Apache release artefacts that might allow for this. We should at
> least clarify this point and not make extra work unnecessarily.
>
> Best wishes,
>
> Neil
>

Re: bits.netbeans.org vs netbeans.apache.org

[Neil C Smith]

On Thu, 12 Sep 2019, 09:48 Eric Barboni,  wrote:

>  We could not move the artefacts to central because of the licence and the
> groupid that are now for Apache NetBeans.
>

I'm not sure this is correct. At least, I remember us getting some advice
about pre-Apache release artefacts that might allow for this. We should at
least clarify this point and not make extra work unnecessarily.

Best wishes,

Neil

Re: bits.netbeans.org vs netbeans.apache.org

[Emilian Bold]

bits.netbeans.org  could easily be migrated to netbeans.osuosl.org

Not sure if there are any plans about that, etc.

--emi

On Thu, Sep 12, 2019 at 11:48 AM Eric Barboni  wrote:
>
> Hi,
>  I was also stressed ;D.
>  We could not move the artefacts to central because of the licence and the 
> groupid that are now for Apache NetBeans.
>  It means another repository should be set up. I'm not sure we can do that 
> only seeing artefacts from a frontend.
>  It may also be locally repopulated by getting old source from mercurial repo 
> of Oracle NetBeans.
>
>   Not sure it worth the effort.
>
> Regards
> Eric
>
>
>
> -Message d'origine-
> De : Jean-Marc Borer 
> Envoyé : mercredi 11 septembre 2019 13:34
> À : dev@netbeans.apache.org
> Objet : Re: bits.netbeans.org vs netbeans.apache.org
>
> Well, I was wondering how long one could rely on legacy NB Maven artifacts 
> such as NETBEANS72 or such hosted on bits.netbeans.org?
>
> I don't mind directly since we have finally migrated to NBP 11, but during a 
> long time after the donation, we were still bound to NETBEANS82 and so do 
> some plugins that need to be "ported". So if bits.netbeans.org would have 
> been shutdown during this period, I would have been in trouble.
>
> I know, NB foundations (modules) are pretty stable between the versions.
> However each time we plan to move our applications to a new version, I must 
> admit that I am little bit stressed the first time I compile them. We had 
> some surprises in the past that could hopefully be easily fixed (some API 
> classes had moved to other modules). You never know...
>
>
>
> On Wed, Sep 11, 2019 at 11:09 AM Geertjan Wielenga 
> wrote:
>
> > What is it exactly that you need, as specifically as possible?
> >
> > Gj
> >
> > On Wed, 11 Sep 2019 at 13:00, Jean-Marc Borer  wrote:
> >
> > > And how long will bits.netbeans.org be maintained? Any input here?
> > >
> > > On Wed, Sep 11, 2019 at 10:32 AM Geertjan Wielenga
> > > 
> > > wrote:
> > >
> > > > Only source code is being donated by Oracle to Apache and only the
> > > > tip
> > of
> > > > the source code it donates.
> > > >
> > > > Gj
> > > >
> > > > On Wed, Sep 11, 2019 at 12:29 PM Jean-Marc Borer
> > > > 
> > > > wrote:
> > > >
> > > > > Hi list members,
> > > > >
> > > > > How long is bits.netbeans.org supposed to be maintained and is
> > > > > there
> > > any
> > > > > plan to migrate the legacy artifacts (dependencies up to 6.5!!)
> > > > > to
> > the
> > > > new
> > > > > netbeans.apache.org repo?
> > > > >
> > > > > Cheers,
> > > > >
> > > > > JMB
> > > > >
> > > >
> > >
> >
>
>
> -
> 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: bits.netbeans.org vs netbeans.apache.org

[Eric Barboni]

Hi, 
 I was also stressed ;D. 
 We could not move the artefacts to central because of the licence and the 
groupid that are now for Apache NetBeans. 
 It means another repository should be set up. I'm not sure we can do that only 
seeing artefacts from a frontend.
 It may also be locally repopulated by getting old source from mercurial repo 
of Oracle NetBeans.

  Not sure it worth the effort.

Regards
Eric
  
  

-Message d'origine-
De : Jean-Marc Borer  
Envoyé : mercredi 11 septembre 2019 13:34
À : dev@netbeans.apache.org
Objet : Re: bits.netbeans.org vs netbeans.apache.org

Well, I was wondering how long one could rely on legacy NB Maven artifacts such 
as NETBEANS72 or such hosted on bits.netbeans.org?

I don't mind directly since we have finally migrated to NBP 11, but during a 
long time after the donation, we were still bound to NETBEANS82 and so do some 
plugins that need to be "ported". So if bits.netbeans.org would have been 
shutdown during this period, I would have been in trouble.

I know, NB foundations (modules) are pretty stable between the versions.
However each time we plan to move our applications to a new version, I must 
admit that I am little bit stressed the first time I compile them. We had some 
surprises in the past that could hopefully be easily fixed (some API classes 
had moved to other modules). You never know...



On Wed, Sep 11, 2019 at 11:09 AM Geertjan Wielenga 
wrote:

> What is it exactly that you need, as specifically as possible?
>
> Gj
>
> On Wed, 11 Sep 2019 at 13:00, Jean-Marc Borer  wrote:
>
> > And how long will bits.netbeans.org be maintained? Any input here?
> >
> > On Wed, Sep 11, 2019 at 10:32 AM Geertjan Wielenga 
> > 
> > wrote:
> >
> > > Only source code is being donated by Oracle to Apache and only the 
> > > tip
> of
> > > the source code it donates.
> > >
> > > Gj
> > >
> > > On Wed, Sep 11, 2019 at 12:29 PM Jean-Marc Borer 
> > > 
> > > wrote:
> > >
> > > > Hi list members,
> > > >
> > > > How long is bits.netbeans.org supposed to be maintained and is 
> > > > there
> > any
> > > > plan to migrate the legacy artifacts (dependencies up to 6.5!!) 
> > > > to
> the
> > > new
> > > > netbeans.apache.org repo?
> > > >
> > > > Cheers,
> > > >
> > > > JMB
> > > >
> > >
> >
>


-
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