Re: Profiling on 64bit Windows

[Lars Bruun-Hansen]

Ernie, my comments were indeed very specific to the case at hand: the
fix to the native binary for the Profiler Launch for Windows 64 bit
and how to get that fix into the NetBeans distribution.

It just happens to be exactly the same challenge in the other cases I mention.

I wrote my piece because I looked into if I could contribute for this
specific problem (NETBEANS-1428, PR-2021).
Let's recap:

1. Pedro's PR-2021 needs to be further reviewed and then - if approved - merged.
2. Then a new binary needs to be build for Windows 64 bit, the file
profilerinterface.dll, based on the new Apache code, i.e. the code
which was just merged. It is not as such difficult to build the new
DLL locally, I can do it. Pedro has already done it (#1). No sweat.
3. The new binary then needs to become part of
https://netbeans.osuosl.org/binaries/-profiler-external-binaries-8.2.zip
(#2) in order to be picked up by the NetBeans build pipeline. However,
we cannot just replace that single DLL in that ZIP because then the
ZIP file would become a mix of CDDL licensed binaries and AL2 licensed
binaries and from two different source code repos. Ouch!. So there's
some complexity there. As a quick fix we want to avoid rebuilding for
all those other platforms and only re-build for Windows, perhaps even
only for Windows 64bit, right? We can maybe change the Java code for
lib.profiler so that there's a external binaries ZIP for Windows and
another for the rest of the platforms but that is a somewhat involved
task and it adds complexity. Again, this specific design, the common
ZIP, is shared with the other use cases I mention and the issue about
integrating a new binary is exactly similar.

This is why I struggle to see an easy quick fix for the problem at
hand, integrating the new binary for the Profiler Launcher solely for
Windows 64 bit. You very quickly end up in a situation where you need
to rebuild binaries for MacOS and Linux too.

I understand your frustration but I think this explains why people
keep "hijacking" or digressing to the bigger picture as you mention
and then the specific issue stalls. How annoying. The reason is it is
just not that easy to see a path to a quick fix. From my analysis my
conclusion is that we might as well tackle the bigger picture, i.e.
creating an ASF build pipeline for those binaries. And I'm normally
all for quick fixes  :-)


Peace.

/Lars

Ref #1:  https://github.com/pedro-w/netbeans/releases/tag/v2
Ref #2:  Currently
https://netbeans.osuosl.org/binaries/45225DCFC94A9782419E95C70957822A0C44612D-profiler-external-binaries-8.2.zip
as per the file
https://github.com/apache/netbeans/blob/master/profiler/lib.profiler/external/binaries-list.

On Wed, Jan 13, 2021 at 3:00 AM Ernie Rael  wrote:
>
> This thread is about /Profiling on 64bit Windows/. With hopes to find a
> short term solution; quick and dirty if nothing more general is available.
>
> This subject has been avoided for years often time by hijacking and
> starting to talk about the big picture issue. Which of course is
> important and includes important issues and information. Some of this
> may have been in various discussions over the past years. (I don't know)
> Maybe there's an issue open about it somewhere, where you could
> contribute; or start a new thread.
>
> Where relevant, it would be great to reference those big picture here.
> But not avoid the issue at hand.
>
> Apologies (and thanks for the space) for blowing off steam.
> -ernie
>
> On 1/12/2021 12:13 AM, Lars Bruun-Hansen wrote:
> > I think we as a community need to fix the "native builds" issue very
> > soon. PRs are piling up.
> >
> > This current email thread is not the only one. Over the past 2 years
> > fixes have been made (PRs merged) to native binaries code in the areas
> > of
> >
> > * Native Launchers
> > * NBI  (installers)
> > * Profiler launcher
> >
> > The problem is the same in all cases: The´source code is fixed but
> > there's never a new binary being build hence nothing really happens.
> >
> > These binaries were never re-build in an Apache NetBeans setting. They
> > were simply copied from their old Oracle-era location to
> > https://netbeans.osuosl.org/binaries from where they are picked up by
> > the Apache NetBeans build process but labelled as something which has
> > a CDDL license. This is legally correct but is a limbo state: The
> > source code is (now) owned by ASF but for reason of lack of time we
> > are still using the pre-ASF binaries. I can 100% understand why such
> > "shortcut" was made and salute those who made it happen.
> >
> > However, obviously it is sub-optimal that parts of the NetBeans
> > Platform and IDE distribution effectively cannot be bug-fixed.
> >
> > The right solution IMHO is that those parts of the Apache NetBeans
> > universe would be a first-class citizen in the general Jenkins build
> > pipeline for the Platform and IDE distribution. By first-class I mean
> > that the binary is automatically re-build whenever the source 

Re: Help Needed: nb-javac upgrade for 12.0-u2

[Laszlo Kishalmi]

Thanks to Akshay Gupta, who helped make the PR at least acceptable for 
our CI.


This would mean to upgrade nb-javac to Java 14 in NetBeans 12.0 (which 
shall support Java 14 anyway)


How do we remember nb-javac 14 with NetBeans 12.1? Does it worth to 
include this one?



On 1/11/21 9:05 AM, Laszlo Kishalmi wrote:

Dear all,

I have a PR upgrading nb-javac for 12.0-u2: 
https://github.com/apache/netbeans/pull/2672


If we can figure out in one day what needs to be done with it, and get 
pass the CI, then I'd include it, otherwise I'm going to skip it from 
12.0-u2


BTW here is the list of the PR-s which got included:

https://github.com/apache/netbeans/pulls?q=is%3Aclosed+milestone%3A12.0-u2 





-
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: Profiling on 64bit Windows

[Ernie Rael]

This thread is about /Profiling on 64bit Windows/. With hopes to find a 
short term solution; quick and dirty if nothing more general is available.


This subject has been avoided for years often time by hijacking and 
starting to talk about the big picture issue. Which of course is 
important and includes important issues and information. Some of this 
may have been in various discussions over the past years. (I don't know) 
Maybe there's an issue open about it somewhere, where you could 
contribute; or start a new thread.


Where relevant, it would be great to reference those big picture here. 
But not avoid the issue at hand.


Apologies (and thanks for the space) for blowing off steam.
-ernie

On 1/12/2021 12:13 AM, Lars Bruun-Hansen wrote:

I think we as a community need to fix the "native builds" issue very
soon. PRs are piling up.

This current email thread is not the only one. Over the past 2 years
fixes have been made (PRs merged) to native binaries code in the areas
of

* Native Launchers
* NBI  (installers)
* Profiler launcher

The problem is the same in all cases: The´source code is fixed but
there's never a new binary being build hence nothing really happens.

These binaries were never re-build in an Apache NetBeans setting. They
were simply copied from their old Oracle-era location to
https://netbeans.osuosl.org/binaries from where they are picked up by
the Apache NetBeans build process but labelled as something which has
a CDDL license. This is legally correct but is a limbo state: The
source code is (now) owned by ASF but for reason of lack of time we
are still using the pre-ASF binaries. I can 100% understand why such
"shortcut" was made and salute those who made it happen.

However, obviously it is sub-optimal that parts of the NetBeans
Platform and IDE distribution effectively cannot be bug-fixed.

The right solution IMHO is that those parts of the Apache NetBeans
universe would be a first-class citizen in the general Jenkins build
pipeline for the Platform and IDE distribution. By first-class I mean
that the binary is automatically re-build whenever the source code
changes. This would require Jenkins build slaves for Linux, MacOS and
Windows (which I understand that ASF indeed has) and it would probably
require quite a bit of setup work to get right. Apache NetBeans is a
Java-oriented community so knowledge about building C/C++ binaries is
limited which is probably why nobody so far is stepping forward. As
Ernie suggests there may be a short term solution too which is more
quick-and-dirty i.e. someone would re-build locally, verify the
binaries and then upload as one-shot fix. However it is not always
that simple. The binaries are distributed as one ZIP. If one decides
to only re-build the binary for the Windows platform then this current
packaging breaks down because then you have one binary in the ZIP
which is ASF and the others which are CCDL and no longer build from
the same revision in the VCS. It would be a mess. Therefore, in many
ways, I'm not sure the quick-and-dirty solution really exists.

Is this a correct status ?

Lars







On Tue, Jan 12, 2021 at 2:07 AM Eirik Bakke  wrote:

Build issues aside, I think the code in the PR actually needs at least a 
cursory review from someone else than the original author. Others, like myself, 
have passed by and tested the fix or left other comments, but I'm not sure 
anyone sat down and reviewed it all in one sitting.

( https://github.com/apache/netbeans/pull/2021 )

-- Eirik

-Original Message-
From: Ernie Rael 
Sent: Monday, January 11, 2021 12:34 PM
To: dev@netbeans.apache.org
Subject: Re: Profiling on 64bit Windows

On 1/11/2021 6:53 AM, Geertjan Wielenga wrote:

What needs to be done? Can you provide a PR?

Sadly no. I suspect that someone who knows their way around a distribution 
would have that knowledge. I could be wrong, but I suspect it's simple.

If it is simple and it hasn't been done in two years, I'd guess it's more a 
lack of will or willingness to just check in the binaries.

-ernie



Gj

On Mon, 11 Jan 2021 at 15:33, Ernie Rael  wrote:


Hi all,

There's been a fix for the 64 bit windows profiling problem for over
two years.

  https://github.com/pedro-w/netbeans/releases/tag/v0.1-alpha
  https://issues.apache.org/jira/browse/NETBEANS-1428

AFAICT, it hasn't been integrated. There's some discussion every few
months or so on how to get the binaries to be automatically built as
part of the general build. An answer hasn't been found, so the
problem remains. These binaries have been around and in use for quite a while.

This issue seems stuck in the /Perfectionism is the enemy of
progress/ trap.

Can't the binaries be checked in and included, while the
investigation for a solution proceeds?

-ernie


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

For further 

Re: [VOTE] Release Apache NetBeans 12.2 u1 VSCode Extension

[Jaroslav Tulach]

+1 (binding)

Verified GPG on another machine:

$ curl https://downloads.apache.org/netbeans/KEYS | gpg --import
$ gpg --verify netbeans-12.2.1-source.zip.asc
$ gpg --verify apache-netbeans-java-12.2.1.vsix.asc

Built without problems with JDK8:

$ unzip netbeans-12.2.1-source.zip
$ ant build
$ ant -f java/java.lsp.server/ build-vscode-ext

Executed just fine:

$ code --extensionDevelopmentPath=`pwd`/java/java.lsp.server/vscode/


po 11. 1. 2021 v 12:35 odesílatel Jaroslav Tulach 
napsal:
>
> Dear community,
> many improvements have been made to [VSNetBeans](https://cwiki.apache.org/
>
confluence/display/NETBEANS/Apache+NetBeans+extension+for+Visual+Studio+Code)
> during last few weeks. The fixes include stability improvements as well
as many
> new refactoring features and infrastructure enhancements[1].
>
> To follow the gold open source rule to "release early, release offten"
I've
> just packed what has been done and I am calling for a vote on sources for
> Apache NetBeans 12.2 u1:
>
>
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip
>
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.asc
>
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.sha512
>
> As well as associated convenience binary containing the VSCode extension
file
> for Apache NetBeans Language Server 12.2.1 extension:
>
>
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix
>
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.asc
>
https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.sha512
>
> The source ZIP as well as the `.vsix` file come from tag 12.2.1 in our
> repository: https://github.com/apache/netbeans/tree/12.2.1 - e.g. from
commit
> 7220262.
>
+1 (binding)

Verified GPG on another machine:

$ curl https://downloads.apache.org/netbeans/KEYS | gpg --import
$ gpg --verify netbeans-12.2.1-source.zip.asc
$ gpg --verify apache-netbeans-java-12.2.1.vsix.asc

Built without problems:

$ unzip netbeans-12.2.1-source.zip
$ ant build
$ ant -f java/java.lsp.server/ build-vscode-ext

Executed just fine:

$ code --extensionDevelopmentPath=`pwd`/java/java.lsp.server/vscode/


po 11. 1. 2021 v 12:35 odesílatel Jaroslav Tulach 
napsal:

> Dear community,
> many improvements have been made to [VSNetBeans](https://cwiki.apache.org/
>
> confluence/display/NETBEANS/Apache+NetBeans+extension+for+Visual+Studio+Code
> )
>
> during last few weeks. The fixes include stability improvements as well as
> many
> new refactoring features and infrastructure enhancements[1].
>
> To follow the gold open source rule to "release early, release offten"
> I've
> just packed what has been done and I am calling for a vote on sources for
> Apache NetBeans 12.2 u1:
>
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.asc
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.sha512
>
> As well as associated convenience binary containing the VSCode extension
> file
> for Apache NetBeans Language Server 12.2.1 extension:
>
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.asc
>
> https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.sha512
>
> The source ZIP as well as the `.vsix` file come from tag 12.2.1 in our
> repository: https://github.com/apache/netbeans/tree/12.2.1 - e.g. from
> commit
> 7220262.
>
> The source ZIP has been produced by TLP job (I've just renamed it to
> contain
> 12.2.1 version):
>
> https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/
> release122/28/artifact/dist/netbeans/
> 
>
> The `.vsix` file has been produced by https://ci-builds.apache.org/job/
> Netbeans/job/netbeans-vscode/257/
>  job
> run.
>
> I've signed both files with my new GPG key (lost previous one during hard
> drive
> crash) which can be found at the end of
> 

Re: [VOTE] Release Apache NetBeans 12.2 u1 VSCode Extension

[Dusan Balek]

+1 (binding)

Features tested on Linux.

Dusan

On 1/11/21 12:35 PM, Jaroslav Tulach wrote:

Dear community,
many improvements have been made to 
[VSNetBeans](https://urldefense.com/v3/__https://cwiki.apache.org/__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwvaTRa1U$
confluence/display/NETBEANS/Apache+NetBeans+extension+for+Visual+Studio+Code)
during last few weeks. The fixes include stability improvements as well as many
new refactoring features and infrastructure enhancements[1].

To follow the gold open source rule to "release early, release offten" I've
just packed what has been done and I am calling for a vote on sources for
Apache NetBeans 12.2 u1:

https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwqn4pPJf$
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.asc__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwtjwofeD$
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/netbeans-12.2.1-source.zip.sha512__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwsQJ4nbK$

As well as associated convenience binary containing the VSCode extension file
for Apache NetBeans Language Server 12.2.1 extension:

https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwvQC8mV4$
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.asc__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwouwToqH$
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/netbeans/netbeans-vscode-ext/netbeans-vscode-ext-12.2.1/apache-netbeans-java-12.2.1.vsix.sha512__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwjvR7Dmg$

The source ZIP as well as the `.vsix` file come from tag 12.2.1 in our
repository: 
https://urldefense.com/v3/__https://github.com/apache/netbeans/tree/12.2.1__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwgcg2huZ$
  - e.g. from commit
7220262.

The source ZIP has been produced by TLP job (I've just renamed it to contain
12.2.1 version):
https://urldefense.com/v3/__https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwkOeZoAZ$
release122/28/artifact/dist/netbeans/

The `.vsix` file has been produced by 
https://urldefense.com/v3/__https://ci-builds.apache.org/job/__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwhzDOKm0$
Netbeans/job/netbeans-vscode/257/ job run.

I've signed both files with my new GPG key (lost previous one during hard drive
crash) which can be found at the end of 
https://urldefense.com/v3/__https://downloads.apache.org/netbeans/__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwixiibq_$
KEYS - hopefully the signing went OK.

To build the Apache NetBeans Language Server extension please follow the
instruction in 
[java/java.lsp.server/vscode/BUILD.md](https://urldefense.com/v3/__https://github.com/__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwgzteQd6$
apache/netbeans/blob/c8e0cec5edcbfbd61f22e07eb92fcdbad17f345b/java/
java.lsp.server/vscode/BUILD.md), e.g.:

```bash
netbeans$ ant build
netbeans$ cd java/java.lsp.server
java.lsp.server$ ant build-vscode-ext
```

To test the resulting or convenience `.vsix` file, please follow the [wiki
page](https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NETBEANS/__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwpMQsYjx$
Apache+NetBeans+extension+for+Visual+Studio+Code) instructions that describe
the typical scenarios the extension is supposed to support.


Let's give us 72h for testing and voting. Thanks everyone who contributed and
everyone who supported this exceptional irregular 12.2 u1 release.

-jt

[1] Changelog is available 
https://urldefense.com/v3/__https://github.com/apache/netbeans/blob/__;!!GqivPVa7Brio!M7KQ5ADPXEkEnrR4NLc8v867KUR6x7uci_heijWEs96x007Gb26jGCNJwuMSizJj$
c8e0cec5edcbfbd61f22e07eb92fcdbad17f345b/java/java.lsp.server/vscode/
CHANGELOG.md





-
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: Profiling on 64bit Windows

[Lars Bruun-Hansen]

@John. You are right. I missed that. But cloud providers now support
MacOS instances (ref AWS) so it wouldn't be totally impossible if the
desire is for ASF still to have control and insist on using Jenkins.

Another avenue would be to use GitHub Actions. (ref:
https://github.com/features/actions). They are free of cost for Open
Source projects and support Linux X86, Linux ARM, Windows, MacOS.
Another possibility is Travis which is already used by Apache NetBeans
albeit not for release binaries. But none of these is Jenkins.



/Lars

On Tue, Jan 12, 2021 at 9:17 AM John Mc  wrote:
>
> "This would require Jenkins build slaves for Linux, MacOS and
> Windows (which I understand that ASF indeed has) "
>
> This is incorrect, the ASF doesn't have MacOS build slaves for Jenkins,
> which is one of the reasons why the MacOS Installer is still manually built
> following a successful vote of the VC.
>
> Regards
>
> John
>
>
>
> On Tue, 12 Jan 2021 at 08:13, Lars Bruun-Hansen 
> wrote:
>
> > I think we as a community need to fix the "native builds" issue very
> > soon. PRs are piling up.
> >
> > This current email thread is not the only one. Over the past 2 years
> > fixes have been made (PRs merged) to native binaries code in the areas
> > of
> >
> > * Native Launchers
> > * NBI  (installers)
> > * Profiler launcher
> >
> > The problem is the same in all cases: The´source code is fixed but
> > there's never a new binary being build hence nothing really happens.
> >
> > These binaries were never re-build in an Apache NetBeans setting. They
> > were simply copied from their old Oracle-era location to
> > https://netbeans.osuosl.org/binaries from where they are picked up by
> > the Apache NetBeans build process but labelled as something which has
> > a CDDL license. This is legally correct but is a limbo state: The
> > source code is (now) owned by ASF but for reason of lack of time we
> > are still using the pre-ASF binaries. I can 100% understand why such
> > "shortcut" was made and salute those who made it happen.
> >
> > However, obviously it is sub-optimal that parts of the NetBeans
> > Platform and IDE distribution effectively cannot be bug-fixed.
> >
> > The right solution IMHO is that those parts of the Apache NetBeans
> > universe would be a first-class citizen in the general Jenkins build
> > pipeline for the Platform and IDE distribution. By first-class I mean
> > that the binary is automatically re-build whenever the source code
> > changes. This would require Jenkins build slaves for Linux, MacOS and
> > Windows (which I understand that ASF indeed has) and it would probably
> > require quite a bit of setup work to get right. Apache NetBeans is a
> > Java-oriented community so knowledge about building C/C++ binaries is
> > limited which is probably why nobody so far is stepping forward. As
> > Ernie suggests there may be a short term solution too which is more
> > quick-and-dirty i.e. someone would re-build locally, verify the
> > binaries and then upload as one-shot fix. However it is not always
> > that simple. The binaries are distributed as one ZIP. If one decides
> > to only re-build the binary for the Windows platform then this current
> > packaging breaks down because then you have one binary in the ZIP
> > which is ASF and the others which are CCDL and no longer build from
> > the same revision in the VCS. It would be a mess. Therefore, in many
> > ways, I'm not sure the quick-and-dirty solution really exists.
> >
> > Is this a correct status ?
> >
> > Lars
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jan 12, 2021 at 2:07 AM Eirik Bakke  wrote:
> > >
> > > Build issues aside, I think the code in the PR actually needs at least a
> > cursory review from someone else than the original author. Others, like
> > myself, have passed by and tested the fix or left other comments, but I'm
> > not sure anyone sat down and reviewed it all in one sitting.
> > >
> > > ( https://github.com/apache/netbeans/pull/2021 )
> > >
> > > -- Eirik
> > >
> > > -Original Message-
> > > From: Ernie Rael 
> > > Sent: Monday, January 11, 2021 12:34 PM
> > > To: dev@netbeans.apache.org
> > > Subject: Re: Profiling on 64bit Windows
> > >
> > > On 1/11/2021 6:53 AM, Geertjan Wielenga wrote:
> > > > What needs to be done? Can you provide a PR?
> > >
> > > Sadly no. I suspect that someone who knows their way around a
> > distribution would have that knowledge. I could be wrong, but I suspect
> > it's simple.
> > >
> > > If it is simple and it hasn't been done in two years, I'd guess it's
> > more a lack of will or willingness to just check in the binaries.
> > >
> > > -ernie
> > >
> > >
> > > >
> > > > Gj
> > > >
> > > > On Mon, 11 Jan 2021 at 15:33, Ernie Rael  wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> There's been a fix for the 64 bit windows profiling problem for over
> > > >> two years.
> > > >>
> > > >>  https://github.com/pedro-w/netbeans/releases/tag/v0.1-alpha
> > > >>  

Re: Profiling on 64bit Windows

[John Mc]

"This would require Jenkins build slaves for Linux, MacOS and
Windows (which I understand that ASF indeed has) "

This is incorrect, the ASF doesn't have MacOS build slaves for Jenkins,
which is one of the reasons why the MacOS Installer is still manually built
following a successful vote of the VC.

Regards

John



On Tue, 12 Jan 2021 at 08:13, Lars Bruun-Hansen 
wrote:

> I think we as a community need to fix the "native builds" issue very
> soon. PRs are piling up.
>
> This current email thread is not the only one. Over the past 2 years
> fixes have been made (PRs merged) to native binaries code in the areas
> of
>
> * Native Launchers
> * NBI  (installers)
> * Profiler launcher
>
> The problem is the same in all cases: The´source code is fixed but
> there's never a new binary being build hence nothing really happens.
>
> These binaries were never re-build in an Apache NetBeans setting. They
> were simply copied from their old Oracle-era location to
> https://netbeans.osuosl.org/binaries from where they are picked up by
> the Apache NetBeans build process but labelled as something which has
> a CDDL license. This is legally correct but is a limbo state: The
> source code is (now) owned by ASF but for reason of lack of time we
> are still using the pre-ASF binaries. I can 100% understand why such
> "shortcut" was made and salute those who made it happen.
>
> However, obviously it is sub-optimal that parts of the NetBeans
> Platform and IDE distribution effectively cannot be bug-fixed.
>
> The right solution IMHO is that those parts of the Apache NetBeans
> universe would be a first-class citizen in the general Jenkins build
> pipeline for the Platform and IDE distribution. By first-class I mean
> that the binary is automatically re-build whenever the source code
> changes. This would require Jenkins build slaves for Linux, MacOS and
> Windows (which I understand that ASF indeed has) and it would probably
> require quite a bit of setup work to get right. Apache NetBeans is a
> Java-oriented community so knowledge about building C/C++ binaries is
> limited which is probably why nobody so far is stepping forward. As
> Ernie suggests there may be a short term solution too which is more
> quick-and-dirty i.e. someone would re-build locally, verify the
> binaries and then upload as one-shot fix. However it is not always
> that simple. The binaries are distributed as one ZIP. If one decides
> to only re-build the binary for the Windows platform then this current
> packaging breaks down because then you have one binary in the ZIP
> which is ASF and the others which are CCDL and no longer build from
> the same revision in the VCS. It would be a mess. Therefore, in many
> ways, I'm not sure the quick-and-dirty solution really exists.
>
> Is this a correct status ?
>
> Lars
>
>
>
>
>
>
>
> On Tue, Jan 12, 2021 at 2:07 AM Eirik Bakke  wrote:
> >
> > Build issues aside, I think the code in the PR actually needs at least a
> cursory review from someone else than the original author. Others, like
> myself, have passed by and tested the fix or left other comments, but I'm
> not sure anyone sat down and reviewed it all in one sitting.
> >
> > ( https://github.com/apache/netbeans/pull/2021 )
> >
> > -- Eirik
> >
> > -Original Message-
> > From: Ernie Rael 
> > Sent: Monday, January 11, 2021 12:34 PM
> > To: dev@netbeans.apache.org
> > Subject: Re: Profiling on 64bit Windows
> >
> > On 1/11/2021 6:53 AM, Geertjan Wielenga wrote:
> > > What needs to be done? Can you provide a PR?
> >
> > Sadly no. I suspect that someone who knows their way around a
> distribution would have that knowledge. I could be wrong, but I suspect
> it's simple.
> >
> > If it is simple and it hasn't been done in two years, I'd guess it's
> more a lack of will or willingness to just check in the binaries.
> >
> > -ernie
> >
> >
> > >
> > > Gj
> > >
> > > On Mon, 11 Jan 2021 at 15:33, Ernie Rael  wrote:
> > >
> > >> Hi all,
> > >>
> > >> There's been a fix for the 64 bit windows profiling problem for over
> > >> two years.
> > >>
> > >>  https://github.com/pedro-w/netbeans/releases/tag/v0.1-alpha
> > >>  https://issues.apache.org/jira/browse/NETBEANS-1428
> > >>
> > >> AFAICT, it hasn't been integrated. There's some discussion every few
> > >> months or so on how to get the binaries to be automatically built as
> > >> part of the general build. An answer hasn't been found, so the
> > >> problem remains. These binaries have been around and in use for quite
> a while.
> > >>
> > >> This issue seems stuck in the /Perfectionism is the enemy of
> > >> progress/ trap.
> > >>
> > >> Can't the binaries be checked in and included, while the
> > >> investigation for a solution proceeds?
> > >>
> > >> -ernie
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > >> For additional commands, e-mail: dev-h...@netbeans.apache.org
> > >>
> > >> 

Re: Profiling on 64bit Windows

[Lars Bruun-Hansen]

I think we as a community need to fix the "native builds" issue very
soon. PRs are piling up.

This current email thread is not the only one. Over the past 2 years
fixes have been made (PRs merged) to native binaries code in the areas
of

* Native Launchers
* NBI  (installers)
* Profiler launcher

The problem is the same in all cases: The´source code is fixed but
there's never a new binary being build hence nothing really happens.

These binaries were never re-build in an Apache NetBeans setting. They
were simply copied from their old Oracle-era location to
https://netbeans.osuosl.org/binaries from where they are picked up by
the Apache NetBeans build process but labelled as something which has
a CDDL license. This is legally correct but is a limbo state: The
source code is (now) owned by ASF but for reason of lack of time we
are still using the pre-ASF binaries. I can 100% understand why such
"shortcut" was made and salute those who made it happen.

However, obviously it is sub-optimal that parts of the NetBeans
Platform and IDE distribution effectively cannot be bug-fixed.

The right solution IMHO is that those parts of the Apache NetBeans
universe would be a first-class citizen in the general Jenkins build
pipeline for the Platform and IDE distribution. By first-class I mean
that the binary is automatically re-build whenever the source code
changes. This would require Jenkins build slaves for Linux, MacOS and
Windows (which I understand that ASF indeed has) and it would probably
require quite a bit of setup work to get right. Apache NetBeans is a
Java-oriented community so knowledge about building C/C++ binaries is
limited which is probably why nobody so far is stepping forward. As
Ernie suggests there may be a short term solution too which is more
quick-and-dirty i.e. someone would re-build locally, verify the
binaries and then upload as one-shot fix. However it is not always
that simple. The binaries are distributed as one ZIP. If one decides
to only re-build the binary for the Windows platform then this current
packaging breaks down because then you have one binary in the ZIP
which is ASF and the others which are CCDL and no longer build from
the same revision in the VCS. It would be a mess. Therefore, in many
ways, I'm not sure the quick-and-dirty solution really exists.

Is this a correct status ?

Lars







On Tue, Jan 12, 2021 at 2:07 AM Eirik Bakke  wrote:
>
> Build issues aside, I think the code in the PR actually needs at least a 
> cursory review from someone else than the original author. Others, like 
> myself, have passed by and tested the fix or left other comments, but I'm not 
> sure anyone sat down and reviewed it all in one sitting.
>
> ( https://github.com/apache/netbeans/pull/2021 )
>
> -- Eirik
>
> -Original Message-
> From: Ernie Rael 
> Sent: Monday, January 11, 2021 12:34 PM
> To: dev@netbeans.apache.org
> Subject: Re: Profiling on 64bit Windows
>
> On 1/11/2021 6:53 AM, Geertjan Wielenga wrote:
> > What needs to be done? Can you provide a PR?
>
> Sadly no. I suspect that someone who knows their way around a distribution 
> would have that knowledge. I could be wrong, but I suspect it's simple.
>
> If it is simple and it hasn't been done in two years, I'd guess it's more a 
> lack of will or willingness to just check in the binaries.
>
> -ernie
>
>
> >
> > Gj
> >
> > On Mon, 11 Jan 2021 at 15:33, Ernie Rael  wrote:
> >
> >> Hi all,
> >>
> >> There's been a fix for the 64 bit windows profiling problem for over
> >> two years.
> >>
> >>  https://github.com/pedro-w/netbeans/releases/tag/v0.1-alpha
> >>  https://issues.apache.org/jira/browse/NETBEANS-1428
> >>
> >> AFAICT, it hasn't been integrated. There's some discussion every few
> >> months or so on how to get the binaries to be automatically built as
> >> part of the general build. An answer hasn't been found, so the
> >> problem remains. These binaries have been around and in use for quite a 
> >> while.
> >>
> >> This issue seems stuck in the /Perfectionism is the enemy of
> >> progress/ trap.
> >>
> >> Can't the binaries be checked in and included, while the
> >> investigation for a solution proceeds?
> >>
> >> -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
>
>
>

-
To