Investigate why Polymer build needs 3GB to run (node, windows, workaround in place)

[planetf1]

Building on windows 10 (very current) with adoptopenjdk 11 openj9 the polymer build fails with:

[INFO]
[INFO] --- exec-maven-plugin:1.6.0:exec (Polymer build) @ ui-chassis-spring ---
info:   Clearing build\ directory...
info:   (dev) Building...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF63BB3ACB5
 2: 00007FF63BB144E6
 3: 00007FF63BB14EF0
 4: 00007FF63BDA47FE
 5: 00007FF63BDA472F
 6: 00007FF63C2D8964
 7: 00007FF63C2CF0F2
 8: 00007FF63C2CD68C
 9: 00007FF63C2D65B7
10: 00007FF63C2D6636
11: 00007FF63BE81677
12: 00007FF63BF189D2
13: 000002DDCBFDC5C1
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 134 (Exit value: 134)
    at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:404)
    at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
    at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:804)
    at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:751)

A google search suggests this isn't uncommon... and may need changes to the build scripts.

As an aside: Seeing a few platform specific issues - may be worth extending our automated builds to include windows. OR to explicitly state we are not supporting/working with. Or somewhat inbetween, only support WSL2 See #1307

[planetf1]

Raised whilst debugging #2350

[planetf1]

Some tips at:

• Angular 7/8 FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory angular/angular-cli#13734

[planetf1]

When the 'Polymer build' execution occurs I see 'node' consuming lots of memory before crashing.
As per the linked articles it's possible to increase the memory for node by a command line parm, or setting NODE_OPTIONS

So for example one can include this in the maven exec plugin definition for Polymer build (within the configuration tag)

                                    <environmentVariables>
                                        <NODE_OPTIONS>--max_old_space_size=4096</NODE_OPTIONS>
                                    </environmentVariables>

When this is done node happily takes more memory (default is 512) - in fact by observing it appears this step of the process requires 3GB of memory, even with the latest versions of node/NPM

This is not a effective build process, but it's worth including the parm for now as a) it's just a max and b) It always fails on windows leaving egeria unbuildable. I will raise as a PR

I will then leave this open and update the title so that we can come back and try and figure out WHY > 3GB is needed on windows where the default seems ok on macOS.

Note the PR bumps versions as per #1108 which has not attracted further discussion but does represent a security issue as well as being one of the recommendations found when researching this issue

[planetf1]

With the change in place a WIndows build succeeds, and the UI launches correctly,

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[planetf1]

Since this relates to build reliability will keep it open to investigate

[planetf1]

still need investigation

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[planetf1]

ui has now been moved out and defaults working ok so closing