Re: Maven DIstribution

[Alex Harui]

FWIW, I added -DdistributionTargetFolder= and still the same failure.

On 5/5/20, 4:29 PM, "Alex Harui"  wrote:

Maybe. I can't find how to do that in the instructions.  I assumed it would 
end up in a "target" folder.

On 5/5/20, 3:09 PM, "Piotr Zarzycki"  wrote:

Shouldn't you add path where distribution will be saved?

On Tue, May 5, 2020, 7:25 PM Alex Harui  
wrote:

> It may be too early in the morning for me, but I switched to the
> release/0.9.7 branch in all 3 repos, did a "mvn clean install" all of 
them,
> then back in royale-asjs I ran
> "mvn -Pwith-distribution clean install" and got an error:
>
> Failed to create assembly: Error adding file to archive:
> 
/Users/aharui/git/royale/maven/royale-asjs/distribution/jars/compiler-mxmljsc/target/compiler-mxmljsc-0.9.7.jar
>
> Interestingly, maybe related, the output on the CI server says things 
like
> " Skipping the assembly in this project because it's not the Execution
> Root" which may be why it gets past this point.  So I think we're 
missing
> something somewhere.  I thought it would be as simple as selecting 
that
> profile.
>
> Thoughts?
> -Alex
>
>

Build failed in Jenkins: royale-compiler-integration-tests #871

[apacheroyaleci]

See 


Changes:


--
[...truncated 47.00 KB...]
[junit] 
[junit] May 06, 2020 5:17:20 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:332: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.removeEventListener = function(
[junit] 
[junit] 
[junit] May 06, 2020 5:17:20 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:340: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.dispatchEvent = function(evt) {};
[junit] 
[junit] 
[junit] May 06, 2020 5:17:20 AM 
com.google.javascript.jscomp.LoggerErrorManager printSummary
[junit] WARNING: 0 error(s), 3 warning(s)
[junit] Math parameters not found!  0
[junit] 

[junit] May 06, 2020 5:17:20 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:322: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.addEventListener = function(type, 
listener, opt_options) {
[junit] 
[junit] 
[junit] May 06, 2020 5:17:20 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:332: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.removeEventListener = function(
[junit] 
[junit] 
[junit] May 06, 2020 5:17:20 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:340: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.dispatchEvent = function(evt) {};
[junit] 
[junit] 
[junit] May 06, 2020 5:17:20 AM 
com.google.javascript.jscomp.LoggerErrorManager printSummary
[junit] WARNING: 0 error(s), 3 warning(s)
[junit] Math parameters not found!  0
[junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.636 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestPackageNamespace
[junit] foo parameters not found!  0
[junit] bar parameters not found!  0
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.009 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestReferenceModel
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 
0.004 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestTypeTypedefs
[junit] foo parameters not found!  0
[junit] bar parameters not found!  0
[junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.02 sec
[junit] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

main:

jar-test:
 [echo] using externc.jar from 
C:/jenkins/workspace/royale-compiler-integration-tests/compiler-jx/lib
 [java] Math parameters not found!  0
 [java] Reflect parameters not found!  0
 [java] Atomics parameters not found!  0
 [java] Intl parameters not found!  0
 [java] 11.1520993 seconds
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

download:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is ${ROYALE_COMPILER_HOME}
 [echo] ROYALE_COMPILER_HOME is 


prepare:
 [echo] Making lib directory 


all:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:
 [echo] checking for 


download-dependency:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

RE: Maven DIstribution

[Yishay Weiss]

I’m close to starting a vote on rc4. I need to know whether or not to hold up 
the release for this. Is this something we need in 0.9.7 or can it wait for 
0.9.8 ?

Thanks.


From: Alex Harui 
Sent: Wednesday, May 6, 2020 2:29:19 AM
To: dev@royale.apache.org 
Subject: Re: Maven DIstribution

Maybe. I can't find how to do that in the instructions.  I assumed it would end 
up in a "target" folder.

On 5/5/20, 3:09 PM, "Piotr Zarzycki"  wrote:

Shouldn't you add path where distribution will be saved?

On Tue, May 5, 2020, 7:25 PM Alex Harui  wrote:

> It may be too early in the morning for me, but I switched to the
> release/0.9.7 branch in all 3 repos, did a "mvn clean install" all of 
them,
> then back in royale-asjs I ran
> "mvn -Pwith-distribution clean install" and got an error:
>
> Failed to create assembly: Error adding file to archive:
> 
/Users/aharui/git/royale/maven/royale-asjs/distribution/jars/compiler-mxmljsc/target/compiler-mxmljsc-0.9.7.jar
>
> Interestingly, maybe related, the output on the CI server says things like
> " Skipping the assembly in this project because it's not the Execution
> Root" which may be why it gets past this point.  So I think we're missing
> something somewhere.  I thought it would be as simple as selecting that
> profile.
>
> Thoughts?
> -Alex
>
>

Build failed in Jenkins: royale-asjs-agent2 #69

[apacheroyaleci]

See 


Changes:


--
[...truncated 2.05 MB...]

tweak-for-jsonly:

ide:

post-build:
[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 1 file to 

 [copy] Copying 1 file to 

[touch] Creating 

[touch] Creating 

[touch] Creating 


last-message-if-airsdk:

main:
 [echo] ant main target completed on 05/06/2020 04:42:54 AM

sample-themes:

check-runtime-env:

runtime-setup:

mustella-setup:

clean:
   [delete] Deleting: 


check-compiler-home:

check-compiler:

compile:
 [echo] Compiling mustella.swc
 [echo] ROYALE_HOME: 

 [echo] ROYALE_COMPILER_HOME: 

 [java] args:
 [java] 
+royalelib=
 [java] +playerglobal.version=11.7
 [java] +env.PLAYERGLOBAL_HOME=C:\adobe\flash
 [java] +env.AIR_HOME=C:\adobe\air\4.0\AdobeAIRSDK
 [java] -compiler.strict-xml=true
 [java] -compiler.targets=SWF,JSRoyale
 [java] 
-output=
 [java] 
-load-config=
 [java] 
-js-load-config=
 [java] 
-js-load-config+=
 [java] target:SWF
 [java] target:JSRoyale
 [java] COMPC
 [java] Loading configuration: 

 [java] 
 [java] 58086 bytes written to 

 in 2.079 seconds
 [java] COMPCJSCRoyale
 [java] 3.3456592 seconds
 [java] 
:
 col: 8 No definitions matching flash.net.* could be found.
 [java] 
 [java] import flash.net.*;
 [java]^
 [java] 
 [java] 
:
 col: 8 Definition flash.events.Event could not be found.
 [java] 
 [java] import flash.events.Event;
 [java]^
 [java] 
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m 
-Xmx1024m
 [java] Java Result: 2

compile-js:

main:

load-task:

marmotinni-setup:

prepare:
 [echo] Making lib directory 
:\jenkins\workspace\royale-asjs-agent2\marmotinni\java/lib
[mkdir] Created dir: 


selenium3-jar-check:

selenium3-jar:
[mkdir] Created dir: 


download-zip:
[mkdir] Created dir: 

  [get] Getting: https://bit.ly/2zm3ZzF
  [get] To: 

Release Step 013 Succeeded

[apacheroyaleci]

Note: before running these steps make sure that PLAYERGLOBAL_HOME is set and 
that you have PlayerGlobal installed under 
/11.7/playerglobal.swc

>From the royale-asjs repo
1. Run ant -f releasesteps.xml Release_Step_013 -Drelease.version=0.9.7 
-Droyale.swc-date="06/05/20 9:06 -0800" -Dplayerglobal.version=11.7 
-Dflat.donot.ask=true -Drc=4 -DskipTests=true
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_013_Sign 
-Drelease.version=0.9.7
This will PGP sign the source and convenience binary packages
4. Then run ant -f releasesteps.xml Release_Step_013_Upload 
-Drelease.version=0.9.7 -Drc=4
This will upload the signed artifacts to dist.apache.org.

Build failed in Jenkins: royale-asjs-agent2 #68

[apacheroyaleci]

See 


Changes:


--
[...truncated 2.05 MB...]

tweak-for-jsonly:

ide:

post-build:
[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 1 file to 

 [copy] Copying 1 file to 

[touch] Creating 

[touch] Creating 

[touch] Creating 


last-message-if-airsdk:

main:
 [echo] ant main target completed on 05/06/2020 03:15:59 AM

sample-themes:

check-runtime-env:

runtime-setup:

mustella-setup:

clean:
   [delete] Deleting: 


check-compiler-home:

check-compiler:

compile:
 [echo] Compiling mustella.swc
 [echo] ROYALE_HOME: 

 [echo] ROYALE_COMPILER_HOME: 

 [java] args:
 [java] 
+royalelib=
 [java] +playerglobal.version=11.7
 [java] +env.PLAYERGLOBAL_HOME=C:\adobe\flash
 [java] +env.AIR_HOME=C:\adobe\air\4.0\AdobeAIRSDK
 [java] -compiler.strict-xml=true
 [java] -compiler.targets=SWF,JSRoyale
 [java] 
-output=
 [java] 
-load-config=
 [java] 
-js-load-config=
 [java] 
-js-load-config+=
 [java] target:SWF
 [java] target:JSRoyale
 [java] COMPC
 [java] Loading configuration: 

 [java] 
 [java] 58086 bytes written to 

 in 2.241 seconds
 [java] COMPCJSCRoyale
 [java] 3.5020935 seconds
 [java] 
:
 col: 8 No definitions matching flash.net.* could be found.
 [java] 
 [java] import flash.net.*;
 [java]^
 [java] 
 [java] 
:
 col: 8 Definition flash.events.Event could not be found.
 [java] 
 [java] import flash.events.Event;
 [java]^
 [java] 
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m 
-Xmx1024m
 [java] Java Result: 2

compile-js:

main:

load-task:

marmotinni-setup:

prepare:
 [echo] Making lib directory 
:\jenkins\workspace\royale-asjs-agent2\marmotinni\java/lib
[mkdir] Created dir: 


selenium3-jar-check:

selenium3-jar:
[mkdir] Created dir: 


download-zip:
[mkdir] Created dir: 

  [get] Getting: https://bit.ly/2zm3ZzF
  [get] To: 

Re: Maven DIstribution

[Alex Harui]

Maybe. I can't find how to do that in the instructions.  I assumed it would end 
up in a "target" folder.

On 5/5/20, 3:09 PM, "Piotr Zarzycki"  wrote:

Shouldn't you add path where distribution will be saved?

On Tue, May 5, 2020, 7:25 PM Alex Harui  wrote:

> It may be too early in the morning for me, but I switched to the
> release/0.9.7 branch in all 3 repos, did a "mvn clean install" all of 
them,
> then back in royale-asjs I ran
> "mvn -Pwith-distribution clean install" and got an error:
>
> Failed to create assembly: Error adding file to archive:
> 
/Users/aharui/git/royale/maven/royale-asjs/distribution/jars/compiler-mxmljsc/target/compiler-mxmljsc-0.9.7.jar
>
> Interestingly, maybe related, the output on the CI server says things like
> " Skipping the assembly in this project because it's not the Execution
> Root" which may be why it gets past this point.  So I think we're missing
> something somewhere.  I thought it would be as simple as selecting that
> profile.
>
> Thoughts?
> -Alex
>
>

Re: Maven DIstribution

[Piotr Zarzycki]

Shouldn't you add path where distribution will be saved?

On Tue, May 5, 2020, 7:25 PM Alex Harui  wrote:

> It may be too early in the morning for me, but I switched to the
> release/0.9.7 branch in all 3 repos, did a "mvn clean install" all of them,
> then back in royale-asjs I ran
> "mvn -Pwith-distribution clean install" and got an error:
>
> Failed to create assembly: Error adding file to archive:
> /Users/aharui/git/royale/maven/royale-asjs/distribution/jars/compiler-mxmljsc/target/compiler-mxmljsc-0.9.7.jar
>
> Interestingly, maybe related, the output on the CI server says things like
> " Skipping the assembly in this project because it's not the Execution
> Root" which may be why it gets past this point.  So I think we're missing
> something somewhere.  I thought it would be as simple as selecting that
> profile.
>
> Thoughts?
> -Alex
>
>

Build failed in Jenkins: royale-asjs-agent2 #67

[apacheroyaleci]

See 


Changes:

[greg.dove] Add another test that relates to the location of the 'replacement'


--
[...truncated 2.05 MB...]

tweak-for-jsonly:

ide:

post-build:
[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 1 file to 

 [copy] Copying 1 file to 

[touch] Creating 

[touch] Creating 

[touch] Creating 


last-message-if-airsdk:

main:
 [echo] ant main target completed on 05/05/2020 09:16:31 PM

sample-themes:

check-runtime-env:

runtime-setup:

mustella-setup:

clean:
   [delete] Deleting: 


check-compiler-home:

check-compiler:

compile:
 [echo] Compiling mustella.swc
 [echo] ROYALE_HOME: 

 [echo] ROYALE_COMPILER_HOME: 

 [java] args:
 [java] 
+royalelib=
 [java] +playerglobal.version=11.7
 [java] +env.PLAYERGLOBAL_HOME=C:\adobe\flash
 [java] +env.AIR_HOME=C:\adobe\air\4.0\AdobeAIRSDK
 [java] -compiler.strict-xml=true
 [java] -compiler.targets=SWF,JSRoyale
 [java] 
-output=
 [java] 
-load-config=
 [java] 
-js-load-config=
 [java] 
-js-load-config+=
 [java] target:SWF
 [java] target:JSRoyale
 [java] COMPC
 [java] Loading configuration: 

 [java] 
 [java] 58086 bytes written to 

 in 2.147 seconds
 [java] COMPCJSCRoyale
 [java] 3.3933833 seconds
 [java] 
:
 col: 8 No definitions matching flash.net.* could be found.
 [java] 
 [java] import flash.net.*;
 [java]^
 [java] 
 [java] 
:
 col: 8 Definition flash.events.Event could not be found.
 [java] 
 [java] import flash.events.Event;
 [java]^
 [java] 
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m 
-Xmx1024m
 [java] Java Result: 2

compile-js:

main:

load-task:

marmotinni-setup:

prepare:
 [echo] Making lib directory 
:\jenkins\workspace\royale-asjs-agent2\marmotinni\java/lib
[mkdir] Created dir: 


selenium3-jar-check:

selenium3-jar:
[mkdir] Created dir: 


download-zip:
[mkdir] Created dir: 

  [get] Getting: https://bit.ly/2zm3ZzF
  [get] To: 

Build failed in Jenkins: royale-compiler-integration-tests #870

[apacheroyaleci]

See 


Changes:


--
[...truncated 46.09 KB...]
[junit] 

[junit] Math parameters not found!  0
[junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.309 sec
[junit] May 05, 2020 8:37:18 PM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:322: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.addEventListener = function(type, 
listener, opt_options) {
[junit] 
[junit] 
[junit] May 05, 2020 8:37:18 PM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:332: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.removeEventListener = function(
[junit] 
[junit] 
[junit] May 05, 2020 8:37:18 PM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:340: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.dispatchEvent = function(evt) {};
[junit] 
[junit] 
[junit] May 05, 2020 8:37:18 PM 
com.google.javascript.jscomp.LoggerErrorManager printSummary
[junit] WARNING: 0 error(s), 3 warning(s)
[junit] May 05, 2020 8:37:18 PM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:322: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.addEventListener = function(type, 
listener, opt_options) {
[junit] 
[junit] 
[junit] May 05, 2020 8:37:18 PM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:332: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.removeEventListener = function(
[junit] 
[junit] 
[junit] May 05, 2020 8:37:18 PM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:340: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.dispatchEvent = function(evt) {};
[junit] 
[junit] 
[junit] May 05, 2020 8:37:18 PM 
com.google.javascript.jscomp.LoggerErrorManager printSummary
[junit] WARNING: 0 error(s), 3 warning(s)
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestPackageNamespace
[junit] foo parameters not found!  0
[junit] bar parameters not found!  0
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.023 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestReferenceModel
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 
0.002 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestTypeTypedefs
[junit] foo parameters not found!  0
[junit] bar parameters not found!  0
[junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.024 sec
[junit] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

main:

jar-test:
 [echo] using externc.jar from 
C:/jenkins/workspace/royale-compiler-integration-tests/compiler-jx/lib
 [java] Math parameters not found!  0
 [java] Reflect parameters not found!  0
 [java] Atomics parameters not found!  0
 [java] Intl parameters not found!  0
 [java] 4.2526951 seconds
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

download:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is ${ROYALE_COMPILER_HOME}
 [echo] ROYALE_COMPILER_HOME is 


prepare:
 [echo] Making lib directory 


all:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is 

 [echo] ROYALE_COMPILER_HOME is 


check-dependency:
 [echo] checking for 

Jenkins build is back to normal : royale-asjs #1159

[apacheroyaleci]

See 

Build failed in Jenkins: royale-asjs-agent2 #66

[apacheroyaleci]

See 


Changes:

[greg.dove] Fix empty XMLList assignment to XML, added 2 tests

[greg.dove] More tests and fix for other variations of XMLList assignment.


--
[...truncated 2.05 MB...]

tweak-for-jsonly:

ide:

post-build:
[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 1 file to 

 [copy] Copying 1 file to 

[touch] Creating 

[touch] Creating 

[touch] Creating 


last-message-if-airsdk:

main:
 [echo] ant main target completed on 05/05/2020 08:15:23 PM

sample-themes:

check-runtime-env:

runtime-setup:

mustella-setup:

clean:
   [delete] Deleting: 


check-compiler-home:

check-compiler:

compile:
 [echo] Compiling mustella.swc
 [echo] ROYALE_HOME: 

 [echo] ROYALE_COMPILER_HOME: 

 [java] args:
 [java] 
+royalelib=
 [java] +playerglobal.version=11.7
 [java] +env.PLAYERGLOBAL_HOME=C:\adobe\flash
 [java] +env.AIR_HOME=C:\adobe\air\4.0\AdobeAIRSDK
 [java] -compiler.strict-xml=true
 [java] -compiler.targets=SWF,JSRoyale
 [java] 
-output=
 [java] 
-load-config=
 [java] 
-js-load-config=
 [java] 
-js-load-config+=
 [java] target:SWF
 [java] target:JSRoyale
 [java] COMPC
 [java] Loading configuration: 

 [java] 
 [java] 58086 bytes written to 

 in 2.422 seconds
 [java] COMPCJSCRoyale
 [java] 3.7223665 seconds
 [java] 
:
 col: 8 No definitions matching flash.net.* could be found.
 [java] 
 [java] import flash.net.*;
 [java]^
 [java] 
 [java] 
:
 col: 8 Definition flash.events.Event could not be found.
 [java] 
 [java] import flash.events.Event;
 [java]^
 [java] 
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m 
-Xmx1024m
 [java] Java Result: 2

compile-js:

main:

load-task:

marmotinni-setup:

prepare:
 [echo] Making lib directory 
:\jenkins\workspace\royale-asjs-agent2\marmotinni\java/lib
[mkdir] Created dir: 


selenium3-jar-check:

selenium3-jar:
[mkdir] Created dir: 


download-zip:
[mkdir] Created dir: 

  [get] Getting: 

Build failed in Jenkins: royale-asjs #1158

[apacheroyaleci]

See 


Changes:

[carlosrovira] rat-check: exclude src/assets/** like *.afdesign or other files 
that

[carlosrovira] jewel-datagrid: solve focus issue between column and listArea

[carlosrovira] jewel-combobox: add "popUpOpened" and "popUpClosed"


--
[...truncated 272.35 KB...]
 [copy] Copying 1 file to 
C:\jenkins\workspace\royale-compiler\compiler\lib\external
 [copy] Copying 
C:\jenkins\workspace\royale-compiler\compiler\in\temp\jflex-1.6.0\lib\jflex-1.6.0.jar
 to C:\jenkins\workspace\royale-compiler\compiler\lib\external\jflex.jar
 [copy] Copying 1 file to 
C:\jenkins\workspace\royale-compiler\compiler\lib\external
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

check-dependency:
 [echo] checking for 
C:\jenkins\workspace\royale-compiler\compiler/lib/external//lzma-sdk.jar

download-dependency:
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

echo-project-jar:
   [delete] Deleting: 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources\project.properties
 [echo] ${INFO_DOWNLOADING_FILE_FROM}
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

download-apache-license:
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

download-other-license:
  [get] Getting: https://www.7-zip.org/sdk.html
  [get] To: 
C:\jenkins\workspace\royale-compiler\compiler\lib\external\lzma-sdk-LICENSE.html
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

fail-if-not-found:
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

download-dependency-jar:
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

check-cache:

download-jar:
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

get-if-not-cached:
  [get] Getting: 
https://repo1.maven.org/maven2/org/b1/pack/lzma-sdk-4j/9.22.0/lzma-sdk-4j-9.22.0.jar
  [get] To: 
C:\jenkins\workspace\royale-compiler\compiler\lib\external\lzma-sdk.jar
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

double-check-file:
 [echo] ${env.ROYALE_DOWNLOAD_CACHE}
 [echo] Need file: ${still_no_file}

get-from-cache-if-needed:
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

fail-if-not-found:
 [echo] basedir is 
C:\jenkins\workspace\royale-compiler\compiler\src\main\resources
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler
 [echo] ROYALE_COMPILER_HOME is 
C:\jenkins\workspace\royale-compiler\compiler

check-sum:
 [echo] basedir is 

Jenkins build is back to normal : royale-asjs_jsonly #1432

[apacheroyaleci]

See 

Release Step 011 Succeeded

[apacheroyaleci]

Warning: this step requires a secret key, so it should not be performed on the 
CI server. It's probably best to perform it on your PC.

>From the royale-asjs repo:
1. Run ant -f releasesteps.xml Release_Step_011 -Drelease.version=0.9.7 
-DskipTests=true
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_011_Sign 
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_011_Upload 
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging.  Verify that 
the compiler and typedefs artifacts are there along with the asjs artifacts, 
then hit the close to close the staging repo. (https://repository.apache.org/)

Maven DIstribution

[Alex Harui]

It may be too early in the morning for me, but I switched to the release/0.9.7 
branch in all 3 repos, did a "mvn clean install" all of them, then back in 
royale-asjs I ran
"mvn -Pwith-distribution clean install" and got an error:

Failed to create assembly: Error adding file to archive: 
/Users/aharui/git/royale/maven/royale-asjs/distribution/jars/compiler-mxmljsc/target/compiler-mxmljsc-0.9.7.jar

Interestingly, maybe related, the output on the CI server says things like " 
Skipping the assembly in this project because it's not the Execution Root" 
which may be why it gets past this point.  So I think we're missing something 
somewhere.  I thought it would be as simple as selecting that profile.

Thoughts?
-Alex

Release Step 010 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_010 and run the following commands:
git push
git push origin org.apache.royale.framework-0.9.7-rc4

You will need your Apache/Github username and 2FA token.

Release Step 007 Succeeded

[apacheroyaleci]

>From the royale-typedefs repo:
1. Run ant -f releasesteps.xml Release_Step_007 -Drelease.version=0.9.7 
-DskipTests=true
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_007_Sign 
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_007_Upload 
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging. Do not "Close" 
the staging repository until the other repos have been added.

Release Step 006 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_006 and run the following commands:
git push
git push origin org.apache.royale.typedefs-0.9.7-rc4

You will need your Apache/Github username and 2FA token.

Re: Issue with rowHeight and big amount of data in cells

[Piotr Zarzycki]

Carlos,

In "1" are you saying that each row would be a HeaderList type of object ?
- This is your idea?

wt., 5 maj 2020 o 17:04 Carlos Rovira  napisał(a):

> Hi Piotr,
>
> I was trying to expose a plan to do and I see mainly two routes:
>
> 1 List/VirtualList
> 2 Table (will need VirtualTable too)
>
> If we go 1 (List/VirtualList), then will have a HeaderList that is
> basically a DG without more implications (sorting, editing, column
> reordering), and I think that solve your inmediate problem with
> variable row heights. So next thing could be DataGrid extending HeaderList.
> The 3-4 points at the end are the complciated things to solve if we go that
> route, and maybe we can think on some bead infrastructure (like
> initializers on renderers) to solve it.
>
> For 2 (Table route), the main problem I see is to solve scrolling for body
> part. but other things will probably be easier.
>
> Hope that will be more clear.
>
> Carlos
>
>
>
>
>
>
>
> El mar., 5 may. 2020 a las 16:13, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>)
> escribió:
>
> > Carlos,
> >
> > Unfortunately I don't understand which of your points resolve issue from
> > this email thread.
> >
> > Thanks,
> > Piotr
> >
> > wt., 5 maj 2020 o 14:47 Carlos Rovira 
> > napisał(a):
> >
> > > Hi,
> > >
> > > thinking about this a bit more:
> > >
> > > * Basic components are List and VirtualList
> > > * Then a HeaderList could be next step by just incorporating a Header
> > > (There will be a Virtual version too)
> > > * Next DataGrid could be a HeaderList that implements sorting. Maybe
> this
> > > will not be that hard since it implies order the complete Row. Again
> > > Virtual version should be considered
> > >
> > > Things to consider:
> > > - There's no "Cell" or CellRenderer considered
> > > - No editing capabilities since there's no cell concept
> > > - Switch column will be hard too
> > > - more DG things to consider?...
> > >
> > > These latest points maybe could be rethinked to add some bead
> > > infrastructure that support it.
> > >
> > > Another thing: Jewel Table could be as well other way to deal with
> this.
> > If
> > > we add scrolling support for rows to maintain header on its own. Or
> > someone
> > > see some problems with this approach?
> > >
> > > Thanks
> > >
> > >
> > > El mar., 5 may. 2020 a las 12:34, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>)
> > > escribió:
> > >
> > > > Hi Carlos,
> > > >
> > > > Thanks for your thoughts. I believe you are right that we may have a
> > > > headache in case of column reordering and sorting later on. However
> I'm
> > > > wondering whether this problems wouldn't be less painful than current
> > > one.
> > > > To me DG in current state is unusable fully for bigger amount of data
> > and
> > > > I'm saying about data where you have more than 50 or 100 rows, not
> > > > necessary hundreds of rows.
> > > >
> > > > If there will be at least 1 cell among those 100 rows which expands
> > over
> > > > height of  the row - it would be unreadable. - Here we go DataGrid is
> > > > unusable.
> > > >
> > > > Greg any thoughts about Carlos's potential sorting problems ?
> > > >
> > > > Thanks,
> > > > Piotr
> > > >
> > > > wt., 5 maj 2020 o 12:21 Carlos Rovira 
> > > > napisał(a):
> > > >
> > > > > Hi,
> > > > >
> > > > > sorry for my late response here. flooded these days with lots of
> > > things.
> > > > >
> > > > > I think the manage of row height is a problem since it needs to
> sync
> > > with
> > > > > the rest of columns, maybe this could be big problem.
> > > > >
> > > > > About to go rows instead columns, I think that will work better for
> > > that
> > > > > case, but in that case I think we will have a problem with
> reordering
> > > of
> > > > > columns and order data in a column (asc, desc).
> > > > >
> > > > > Another point to take into account. I think many people in flex use
> > to
> > > > see
> > > > > multi column data list as DataGrid. While working on Flex I end
> using
> > > > more
> > > > > List that DataGrid with renders that represent various pieces of
> > > > > information (instead of DG cells). That worked very well. The
> problem
> > > in
> > > > > this approach is to handle a Header in an easy way. For this reason
> > I'm
> > > > > working this days in a "HeaderList" that is just that a List with a
> > top
> > > > > header. This will be more efficient and also have a look and feel
> > more
> > > > > closer to modern apps nowadays [1] (I search quickly for something
> > that
> > > > > shows a bit like what I want to expose)
> > > > >
> > > > > I think DG is needed when you need sorting columns or reordering,
> but
> > > if
> > > > > that's not the case, I think we're overusing it since we come from
> a
> > > Flex
> > > > > background and this days list based solutions are simpler,
> beautiful
> > > and
> > > > > better.
> > > > >
> > > > > That doesn't mean we don't have the problems stated here for
> > DataGrid,
> > > > just
> > > > > saying that many of us 

Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

[Carlos Rovira]

Hi Ysihay,

to be as short as possible, for me is like if we are making build systems
suffer due to release needs (that I at least do not see as a real need), or
at least is what I understand. I think build is over release. At the end
release is a need to put some concrete bytes for public consume, but
building from source is daily work tool.

HTH

Carlos

El mar., 5 may. 2020 a las 16:47, Yishay Weiss ()
escribió:

>
> >And Alex, considering the intensity of you insisting everything to be
> reproducible on Ant and Maven and all sorts of >additional hoops Apache is
> not even asking for, it puzzles me how you could even consider releasing
> something >that doesn't build with one of the two equally supported
> build-systems.
>
> Hi Chris,
> For what it’s worth, I’m the RM for this release and it is my decision
> whether or not to start an new RC (which I am). Alex has one vote, just
> like everyone else. I appreciate your technical input, but I don’t think
> it’s helpful to drag this thread into past arguments. To me, that creates
> an atmosphere where people think too much about whether or not they will
> want to express their opinions, and that’s not helpful.
> Thanks,
> Yishay
>
>
>
> Am 05.05.20, 07:48 schrieb "Yishay Weiss" :
>
> Hi All,
>
> It’s starting to look like the cleanest solution is to start an RC4. I
> intend to start working on that in 10 hours or so. In the meantime, I’d
> appreciate it if people took time to look at RC3, so we don’t end up with
> an RC5.
>
> Thanks,
> Yishay
>
> From: Alex Harui
> Sent: Tuesday, May 5, 2020 12:22 AM
> To: dev@royale.apache.org
> Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7
>
> The Ant packages only contain things we know we want to release.
> Top-level folders are not whitelisted in because you never know what might
> be in them.  We've never released the manualtests folder for example, so we
> don't have to spend time certifying it for code quality and build-ability,
> license, etc.  We've never shipped the top-level src folder because it used
> to only contain a site folder that wasn't going to be of use to our users.
> So when the groovy scripts were added to the src folder, they were not
> included in the Ant packaging.
>
> We also have never voted on and released the 3 top-level Maven source
> packages, mainly to reduce the amount of work the voters need to do.  The
> Maven source packages are "tested" by the Maven release plugin, and the 3
> packages are unpacked and repacked into the Ant package.  So far, we've
> found that two new files were missed.
>
> How many of our users build the source package is one factor and I
> think the answer for Royale is that few people do it.  Apache release are
> supposed to "build" and the Ant source package will build with Ant.
>
> IMO, the best next thing for PMC members to do is to download the RC
> and try it with Ant, and/or use Maven to point to the staging repos and
> test the artifacts that have been staged up there and see if we see any
> other big issues.  Maybe we'll find something else and make RC4 an obvious
> choice.
>
> Other choices are:
> A) Release RC3 with documenting all of the problems in the online
> release notes
> B) Also certifying and voting on the 3 Maven source packages.
>
> IMO, what we don't want to see happen is for folks to not test RC3 and
> find out some big issue later.
>
> My 2 cents,
> -Alex
>
> On 5/4/20, 12:24 PM, "Christofer Dutz" 
> wrote:
>
> The more I think about it  it's actually not good that the
> groovy script isn't in there as this way you will not be able to download,
> unpack and build anything with maven.
> As maven calls this script as the first thing in every maven build
> to ensure everything is setup.
>
> Without this, you will never get past the Maven validate phase ...
> so if I had a vote, I would probably vote -1 on that.
>
> When ere these files getting lost? In the initial source bundles
> built by maven they should be in there ... so probably you only have to
> re-do some of the last steps.
>
> Chris
>
>
>
> Am 04.05.20, 20:13 schrieb "Yishay Weiss"  >:
>
> Ok, I just verified that copying the script to the right
> location makes the groovy plugin happy, so it doesn’t seem to be a windows
> or backslash issue after all.
>
> I need an explanation on when Maven will be used to build the
> Ant sources to decide if it’s worth an RC4.
>
> From: Alex Harui
> Sent: Monday, May 4, 2020 7:14 PM
> To: dev@royale.apache.org
> Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7
>
> The groovy script is not in the ant packages on dist.  My
> earlier email tried to explain that.   Not every file in the repo ends 

Re: Issue with rowHeight and big amount of data in cells

[Carlos Rovira]

Hi Piotr,

I was trying to expose a plan to do and I see mainly two routes:

1 List/VirtualList
2 Table (will need VirtualTable too)

If we go 1 (List/VirtualList), then will have a HeaderList that is
basically a DG without more implications (sorting, editing, column
reordering), and I think that solve your inmediate problem with
variable row heights. So next thing could be DataGrid extending HeaderList.
The 3-4 points at the end are the complciated things to solve if we go that
route, and maybe we can think on some bead infrastructure (like
initializers on renderers) to solve it.

For 2 (Table route), the main problem I see is to solve scrolling for body
part. but other things will probably be easier.

Hope that will be more clear.

Carlos







El mar., 5 may. 2020 a las 16:13, Piotr Zarzycki ()
escribió:

> Carlos,
>
> Unfortunately I don't understand which of your points resolve issue from
> this email thread.
>
> Thanks,
> Piotr
>
> wt., 5 maj 2020 o 14:47 Carlos Rovira 
> napisał(a):
>
> > Hi,
> >
> > thinking about this a bit more:
> >
> > * Basic components are List and VirtualList
> > * Then a HeaderList could be next step by just incorporating a Header
> > (There will be a Virtual version too)
> > * Next DataGrid could be a HeaderList that implements sorting. Maybe this
> > will not be that hard since it implies order the complete Row. Again
> > Virtual version should be considered
> >
> > Things to consider:
> > - There's no "Cell" or CellRenderer considered
> > - No editing capabilities since there's no cell concept
> > - Switch column will be hard too
> > - more DG things to consider?...
> >
> > These latest points maybe could be rethinked to add some bead
> > infrastructure that support it.
> >
> > Another thing: Jewel Table could be as well other way to deal with this.
> If
> > we add scrolling support for rows to maintain header on its own. Or
> someone
> > see some problems with this approach?
> >
> > Thanks
> >
> >
> > El mar., 5 may. 2020 a las 12:34, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>)
> > escribió:
> >
> > > Hi Carlos,
> > >
> > > Thanks for your thoughts. I believe you are right that we may have a
> > > headache in case of column reordering and sorting later on. However I'm
> > > wondering whether this problems wouldn't be less painful than current
> > one.
> > > To me DG in current state is unusable fully for bigger amount of data
> and
> > > I'm saying about data where you have more than 50 or 100 rows, not
> > > necessary hundreds of rows.
> > >
> > > If there will be at least 1 cell among those 100 rows which expands
> over
> > > height of  the row - it would be unreadable. - Here we go DataGrid is
> > > unusable.
> > >
> > > Greg any thoughts about Carlos's potential sorting problems ?
> > >
> > > Thanks,
> > > Piotr
> > >
> > > wt., 5 maj 2020 o 12:21 Carlos Rovira 
> > > napisał(a):
> > >
> > > > Hi,
> > > >
> > > > sorry for my late response here. flooded these days with lots of
> > things.
> > > >
> > > > I think the manage of row height is a problem since it needs to sync
> > with
> > > > the rest of columns, maybe this could be big problem.
> > > >
> > > > About to go rows instead columns, I think that will work better for
> > that
> > > > case, but in that case I think we will have a problem with reordering
> > of
> > > > columns and order data in a column (asc, desc).
> > > >
> > > > Another point to take into account. I think many people in flex use
> to
> > > see
> > > > multi column data list as DataGrid. While working on Flex I end using
> > > more
> > > > List that DataGrid with renders that represent various pieces of
> > > > information (instead of DG cells). That worked very well. The problem
> > in
> > > > this approach is to handle a Header in an easy way. For this reason
> I'm
> > > > working this days in a "HeaderList" that is just that a List with a
> top
> > > > header. This will be more efficient and also have a look and feel
> more
> > > > closer to modern apps nowadays [1] (I search quickly for something
> that
> > > > shows a bit like what I want to expose)
> > > >
> > > > I think DG is needed when you need sorting columns or reordering, but
> > if
> > > > that's not the case, I think we're overusing it since we come from a
> > Flex
> > > > background and this days list based solutions are simpler, beautiful
> > and
> > > > better.
> > > >
> > > > That doesn't mean we don't have the problems stated here for
> DataGrid,
> > > just
> > > > saying that many of us should rethink where DG is worth it or not.
> > > >
> > > > Piotr, about my time. I need to work on HeaderList since a client
> > request
> > > > me. If you need DG solutions, maybe you can start working on new
> beads
> > > that
> > > > will be a total replace of the actual ones so we can try it and see
> if
> > > that
> > > > way is a better approach or not (rows against columns). If not I'll
> try
> > > to
> > > > reach to it later.
> > > >
> > > > Thanks
> > > >
> > > >
> > 

Release Step 003 Succeeded

[apacheroyaleci]

>From the royale-compiler repo:
1. Run:
  ant -f releasesteps.xml Release_Step_003 -Drelease.version=0.9.7
This will download the artifacts then unzip and compile the source artifact.
2. Validate that the compiled artifacts match the downloaded artifacts.
3. If they do, then run ant -f releasesteps.xml Release_Step_003_Sign 
-Drelease.version=0.9.7
This will PGP sign the source ZIP and compiled JARs
4. Then run ant -f releasesteps.xml Release_Step_003_Upload 
-Drelease.version=0.9.7
This will upload the signed artifacts to Maven Release Staging. If you are 
getting 401 responses from Nexus (permission denied) please be sure to have 
your apache creedentials configured in your .m2/settings.xml file. 

Feel free to use this template if you haven't got a settings.xml yet:


http://maven.apache.org/SETTINGS/1.1.0 
http://maven.apache.org/xsd/settings-1.1.0.xsd; 
xmlns="http://maven.apache.org/SETTINGS/1.1.0;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
  


  apache.releases.https
  {your apache user id}
  {your apache user password}

  


(Be sure to replace the placeholders with your actual apache committer id and 
your Apache password)

If you already have a settings.xml, just be sure the "server" block containing 
your credentials is added to a servers block in that file.

Do not "Close" the staging repository until the other repos have been added.

RE: [DISCUSS] Discuss Release Apache Royale 0.9.7

[Yishay Weiss]

>And Alex, considering the intensity of you insisting everything to be 
>reproducible on Ant and Maven and all sorts of >additional hoops Apache is not 
>even asking for, it puzzles me how you could even consider releasing something 
>>that doesn't build with one of the two equally supported build-systems.

Hi Chris,
For what it’s worth, I’m the RM for this release and it is my decision whether 
or not to start an new RC (which I am). Alex has one vote, just like everyone 
else. I appreciate your technical input, but I don’t think it’s helpful to drag 
this thread into past arguments. To me, that creates an atmosphere where people 
think too much about whether or not they will want to express their opinions, 
and that’s not helpful.
Thanks,
Yishay



Am 05.05.20, 07:48 schrieb "Yishay Weiss" :

Hi All,

It’s starting to look like the cleanest solution is to start an RC4. I 
intend to start working on that in 10 hours or so. In the meantime, I’d 
appreciate it if people took time to look at RC3, so we don’t end up with an 
RC5.

Thanks,
Yishay

From: Alex Harui
Sent: Tuesday, May 5, 2020 12:22 AM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The Ant packages only contain things we know we want to release.  Top-level 
folders are not whitelisted in because you never know what might be in them.  
We've never released the manualtests folder for example, so we don't have to 
spend time certifying it for code quality and build-ability, license, etc.  
We've never shipped the top-level src folder because it used to only contain a 
site folder that wasn't going to be of use to our users.  So when the groovy 
scripts were added to the src folder, they were not included in the Ant 
packaging.

We also have never voted on and released the 3 top-level Maven source 
packages, mainly to reduce the amount of work the voters need to do.  The Maven 
source packages are "tested" by the Maven release plugin, and the 3 packages 
are unpacked and repacked into the Ant package.  So far, we've found that two 
new files were missed.

How many of our users build the source package is one factor and I think 
the answer for Royale is that few people do it.  Apache release are supposed to 
"build" and the Ant source package will build with Ant.

IMO, the best next thing for PMC members to do is to download the RC and 
try it with Ant, and/or use Maven to point to the staging repos and test the 
artifacts that have been staged up there and see if we see any other big 
issues.  Maybe we'll find something else and make RC4 an obvious choice.

Other choices are:
A) Release RC3 with documenting all of the problems in the online release 
notes
B) Also certifying and voting on the 3 Maven source packages.

IMO, what we don't want to see happen is for folks to not test RC3 and find 
out some big issue later.

My 2 cents,
-Alex

On 5/4/20, 12:24 PM, "Christofer Dutz"  wrote:

The more I think about it  it's actually not good that the groovy 
script isn't in there as this way you will not be able to download, unpack and 
build anything with maven.
As maven calls this script as the first thing in every maven build to 
ensure everything is setup.

Without this, you will never get past the Maven validate phase ... so 
if I had a vote, I would probably vote -1 on that.

When ere these files getting lost? In the initial source bundles built 
by maven they should be in there ... so probably you only have to re-do some of 
the last steps.

Chris



Am 04.05.20, 20:13 schrieb "Yishay Weiss" :

Ok, I just verified that copying the script to the right location 
makes the groovy plugin happy, so it doesn’t seem to be a windows or backslash 
issue after all.

I need an explanation on when Maven will be used to build the Ant 
sources to decide if it’s worth an RC4.

From: Alex Harui
Sent: Monday, May 4, 2020 7:14 PM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The groovy script is not in the ant packages on dist.  My earlier 
email tried to explain that.   Not every file in the repo ends up in the ant 
packages on purpose.   If we do an RC4, hopefully the changes I made will pick 
those two files.

-Alex

On 5/4/20, 8:54 AM, "Yishay Weiss"  wrote:

.mvn folder exists in GitHub but not in SVN. Could that be 
related?

From: Yishay Weiss
Sent: Monday, May 4, 2020 6:40 PM
To: dev@royale.apache.org
Subject: RE: [DISCUSS] Discuss Release Apache Royale 0.9.7

Look 

Release Step 002 Succeeded

[apacheroyaleci]

Log in to the server, open a command prompt, change directory to 
C:\jenkins\workspace\Royale_Release_Step_002 and run the following commands:
git push
git push origin org.apache.royale.compiler-0.9.7-rc4

You will need your Apache/Github username and 2FA token.

Re: Issue with rowHeight and big amount of data in cells

[Piotr Zarzycki]

Carlos,

Unfortunately I don't understand which of your points resolve issue from
this email thread.

Thanks,
Piotr

wt., 5 maj 2020 o 14:47 Carlos Rovira  napisał(a):

> Hi,
>
> thinking about this a bit more:
>
> * Basic components are List and VirtualList
> * Then a HeaderList could be next step by just incorporating a Header
> (There will be a Virtual version too)
> * Next DataGrid could be a HeaderList that implements sorting. Maybe this
> will not be that hard since it implies order the complete Row. Again
> Virtual version should be considered
>
> Things to consider:
> - There's no "Cell" or CellRenderer considered
> - No editing capabilities since there's no cell concept
> - Switch column will be hard too
> - more DG things to consider?...
>
> These latest points maybe could be rethinked to add some bead
> infrastructure that support it.
>
> Another thing: Jewel Table could be as well other way to deal with this. If
> we add scrolling support for rows to maintain header on its own. Or someone
> see some problems with this approach?
>
> Thanks
>
>
> El mar., 5 may. 2020 a las 12:34, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>)
> escribió:
>
> > Hi Carlos,
> >
> > Thanks for your thoughts. I believe you are right that we may have a
> > headache in case of column reordering and sorting later on. However I'm
> > wondering whether this problems wouldn't be less painful than current
> one.
> > To me DG in current state is unusable fully for bigger amount of data and
> > I'm saying about data where you have more than 50 or 100 rows, not
> > necessary hundreds of rows.
> >
> > If there will be at least 1 cell among those 100 rows which expands over
> > height of  the row - it would be unreadable. - Here we go DataGrid is
> > unusable.
> >
> > Greg any thoughts about Carlos's potential sorting problems ?
> >
> > Thanks,
> > Piotr
> >
> > wt., 5 maj 2020 o 12:21 Carlos Rovira 
> > napisał(a):
> >
> > > Hi,
> > >
> > > sorry for my late response here. flooded these days with lots of
> things.
> > >
> > > I think the manage of row height is a problem since it needs to sync
> with
> > > the rest of columns, maybe this could be big problem.
> > >
> > > About to go rows instead columns, I think that will work better for
> that
> > > case, but in that case I think we will have a problem with reordering
> of
> > > columns and order data in a column (asc, desc).
> > >
> > > Another point to take into account. I think many people in flex use to
> > see
> > > multi column data list as DataGrid. While working on Flex I end using
> > more
> > > List that DataGrid with renders that represent various pieces of
> > > information (instead of DG cells). That worked very well. The problem
> in
> > > this approach is to handle a Header in an easy way. For this reason I'm
> > > working this days in a "HeaderList" that is just that a List with a top
> > > header. This will be more efficient and also have a look and feel more
> > > closer to modern apps nowadays [1] (I search quickly for something that
> > > shows a bit like what I want to expose)
> > >
> > > I think DG is needed when you need sorting columns or reordering, but
> if
> > > that's not the case, I think we're overusing it since we come from a
> Flex
> > > background and this days list based solutions are simpler, beautiful
> and
> > > better.
> > >
> > > That doesn't mean we don't have the problems stated here for DataGrid,
> > just
> > > saying that many of us should rethink where DG is worth it or not.
> > >
> > > Piotr, about my time. I need to work on HeaderList since a client
> request
> > > me. If you need DG solutions, maybe you can start working on new beads
> > that
> > > will be a total replace of the actual ones so we can try it and see if
> > that
> > > way is a better approach or not (rows against columns). If not I'll try
> > to
> > > reach to it later.
> > >
> > > Thanks
> > >
> > >
> > > [1] https://ps.w.org/wpforo/assets/screenshot-1.png?rev=2121401
> > >
> > > El sáb., 2 may. 2020 a las 16:32, Alex Harui ( > >)
> > > escribió:
> > >
> > > > I don't think there is one perfect implementation.  And that's why we
> > > have
> > > > beads.  I think locked columns and individual cell selection are much
> > > > easier with the current implementation, but I agree that variable row
> > > > height will probably be easier if all cells are in a row container.
> > > >
> > > > We just need volunteers to create the other implementations.
> > > >
> > > > -Alex
> > > >
> > > > On 5/2/20, 12:17 AM, "Piotr Zarzycki" 
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > I absolutely agree with Greg. In fact before I read his email I
> was
> > > > digging
> > > > into DataGrid and my initial thought was - when I set rowHeight =
> > NaN
> > > > - My
> > > > rows should be adjusted automatically by the browser - why it
> does
> > > not
> > > > happen? This is exactly because of that:
> > > >
> > > > In browser I think things would be a lot easier 

Re: Issue with rowHeight and big amount of data in cells

[Carlos Rovira]

Hi,

thinking about this a bit more:

* Basic components are List and VirtualList
* Then a HeaderList could be next step by just incorporating a Header
(There will be a Virtual version too)
* Next DataGrid could be a HeaderList that implements sorting. Maybe this
will not be that hard since it implies order the complete Row. Again
Virtual version should be considered

Things to consider:
- There's no "Cell" or CellRenderer considered
- No editing capabilities since there's no cell concept
- Switch column will be hard too
- more DG things to consider?...

These latest points maybe could be rethinked to add some bead
infrastructure that support it.

Another thing: Jewel Table could be as well other way to deal with this. If
we add scrolling support for rows to maintain header on its own. Or someone
see some problems with this approach?

Thanks


El mar., 5 may. 2020 a las 12:34, Piotr Zarzycki ()
escribió:

> Hi Carlos,
>
> Thanks for your thoughts. I believe you are right that we may have a
> headache in case of column reordering and sorting later on. However I'm
> wondering whether this problems wouldn't be less painful than current one.
> To me DG in current state is unusable fully for bigger amount of data and
> I'm saying about data where you have more than 50 or 100 rows, not
> necessary hundreds of rows.
>
> If there will be at least 1 cell among those 100 rows which expands over
> height of  the row - it would be unreadable. - Here we go DataGrid is
> unusable.
>
> Greg any thoughts about Carlos's potential sorting problems ?
>
> Thanks,
> Piotr
>
> wt., 5 maj 2020 o 12:21 Carlos Rovira 
> napisał(a):
>
> > Hi,
> >
> > sorry for my late response here. flooded these days with lots of things.
> >
> > I think the manage of row height is a problem since it needs to sync with
> > the rest of columns, maybe this could be big problem.
> >
> > About to go rows instead columns, I think that will work better for that
> > case, but in that case I think we will have a problem with reordering of
> > columns and order data in a column (asc, desc).
> >
> > Another point to take into account. I think many people in flex use to
> see
> > multi column data list as DataGrid. While working on Flex I end using
> more
> > List that DataGrid with renders that represent various pieces of
> > information (instead of DG cells). That worked very well. The problem in
> > this approach is to handle a Header in an easy way. For this reason I'm
> > working this days in a "HeaderList" that is just that a List with a top
> > header. This will be more efficient and also have a look and feel more
> > closer to modern apps nowadays [1] (I search quickly for something that
> > shows a bit like what I want to expose)
> >
> > I think DG is needed when you need sorting columns or reordering, but if
> > that's not the case, I think we're overusing it since we come from a Flex
> > background and this days list based solutions are simpler, beautiful and
> > better.
> >
> > That doesn't mean we don't have the problems stated here for DataGrid,
> just
> > saying that many of us should rethink where DG is worth it or not.
> >
> > Piotr, about my time. I need to work on HeaderList since a client request
> > me. If you need DG solutions, maybe you can start working on new beads
> that
> > will be a total replace of the actual ones so we can try it and see if
> that
> > way is a better approach or not (rows against columns). If not I'll try
> to
> > reach to it later.
> >
> > Thanks
> >
> >
> > [1] https://ps.w.org/wpforo/assets/screenshot-1.png?rev=2121401
> >
> > El sáb., 2 may. 2020 a las 16:32, Alex Harui ( >)
> > escribió:
> >
> > > I don't think there is one perfect implementation.  And that's why we
> > have
> > > beads.  I think locked columns and individual cell selection are much
> > > easier with the current implementation, but I agree that variable row
> > > height will probably be easier if all cells are in a row container.
> > >
> > > We just need volunteers to create the other implementations.
> > >
> > > -Alex
> > >
> > > On 5/2/20, 12:17 AM, "Piotr Zarzycki" 
> > wrote:
> > >
> > > Hi,
> > >
> > > I absolutely agree with Greg. In fact before I read his email I was
> > > digging
> > > into DataGrid and my initial thought was - when I set rowHeight =
> NaN
> > > - My
> > > rows should be adjusted automatically by the browser - why it does
> > not
> > > happen? This is exactly because of that:
> > >
> > > In browser I think things would be a lot easier if the
> > > > internal 'lists' were managed as a single list of native rows
> > > instead of
> > > > composed columns of lists for DataGrids (specifically in the
> > > browser).
> > >
> > >
> > > Carlos do you think it would be good to change that implementation
> in
> > > the
> > > way as Greg is proposing ? Do you have time to work on that ?
> > >
> > > Thanks,
> > > Piotr
> > >
> > > czw., 30 kwi 2020 o 20:48 Greg Dove 
> > 

Build failed in Jenkins: royale-compiler #393

[apacheroyaleci]

See 


Changes:


--
Started by timer
Running as SYSTEM
[EnvInject] - Loading node environment variables.
FATAL: java.nio.channels.ClosedChannelException
java.nio.channels.ClosedChannelException
Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
JNLP4-connect connection from 52.251.60.60/52.251.60.60:52767
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at hudson.remoting.Request.call(Request.java:202)
at hudson.remoting.Channel.call(Channel.java:956)
at hudson.FilePath.act(FilePath.java:1162)
at 
org.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvVarsForNode(EnvironmentVariablesNodeLoader.java:61)
at 
org.jenkinsci.plugins.envinject.EnvInjectListener.loadEnvironmentVariablesNode(EnvInjectListener.java:78)
at 
org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:42)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:542)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:462)
at hudson.model.Run.execute(Run.java:1815)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused: hudson.remoting.RequestAbortedException
at hudson.remoting.Request.abort(Request.java:340)
at hudson.remoting.Channel.terminate(Channel.java:1040)
at 
org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer.onReadClosed(ChannelApplicationLayer.java:209)
at 
org.jenkinsci.remoting.protocol.ApplicationLayer.onRecvClosed(ApplicationLayer.java:222)
at 
org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:816)
at 
org.jenkinsci.remoting.protocol.FilterLayer.onRecvClosed(FilterLayer.java:287)
at 
org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed(SSLEngineFilterLayer.java:172)
at 
org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:816)
at 
org.jenkinsci.remoting.protocol.NetworkLayer.onRecvClosed(NetworkLayer.java:154)
at 
org.jenkinsci.remoting.protocol.impl.NIONetworkLayer.ready(NIONetworkLayer.java:179)
at org.jenkinsci.remoting.protocol.IOHub$OnReady.run(IOHub.java:795)
at 
jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at 
jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for 
royale-compiler #393
ERROR: agent2 is offline; cannot locate Java 8 (201)

Re: Issue with rowHeight and big amount of data in cells

[Piotr Zarzycki]

Hi Carlos,

Thanks for your thoughts. I believe you are right that we may have a
headache in case of column reordering and sorting later on. However I'm
wondering whether this problems wouldn't be less painful than current one.
To me DG in current state is unusable fully for bigger amount of data and
I'm saying about data where you have more than 50 or 100 rows, not
necessary hundreds of rows.

If there will be at least 1 cell among those 100 rows which expands over
height of  the row - it would be unreadable. - Here we go DataGrid is
unusable.

Greg any thoughts about Carlos's potential sorting problems ?

Thanks,
Piotr

wt., 5 maj 2020 o 12:21 Carlos Rovira  napisał(a):

> Hi,
>
> sorry for my late response here. flooded these days with lots of things.
>
> I think the manage of row height is a problem since it needs to sync with
> the rest of columns, maybe this could be big problem.
>
> About to go rows instead columns, I think that will work better for that
> case, but in that case I think we will have a problem with reordering of
> columns and order data in a column (asc, desc).
>
> Another point to take into account. I think many people in flex use to see
> multi column data list as DataGrid. While working on Flex I end using more
> List that DataGrid with renders that represent various pieces of
> information (instead of DG cells). That worked very well. The problem in
> this approach is to handle a Header in an easy way. For this reason I'm
> working this days in a "HeaderList" that is just that a List with a top
> header. This will be more efficient and also have a look and feel more
> closer to modern apps nowadays [1] (I search quickly for something that
> shows a bit like what I want to expose)
>
> I think DG is needed when you need sorting columns or reordering, but if
> that's not the case, I think we're overusing it since we come from a Flex
> background and this days list based solutions are simpler, beautiful and
> better.
>
> That doesn't mean we don't have the problems stated here for DataGrid, just
> saying that many of us should rethink where DG is worth it or not.
>
> Piotr, about my time. I need to work on HeaderList since a client request
> me. If you need DG solutions, maybe you can start working on new beads that
> will be a total replace of the actual ones so we can try it and see if that
> way is a better approach or not (rows against columns). If not I'll try to
> reach to it later.
>
> Thanks
>
>
> [1] https://ps.w.org/wpforo/assets/screenshot-1.png?rev=2121401
>
> El sáb., 2 may. 2020 a las 16:32, Alex Harui ()
> escribió:
>
> > I don't think there is one perfect implementation.  And that's why we
> have
> > beads.  I think locked columns and individual cell selection are much
> > easier with the current implementation, but I agree that variable row
> > height will probably be easier if all cells are in a row container.
> >
> > We just need volunteers to create the other implementations.
> >
> > -Alex
> >
> > On 5/2/20, 12:17 AM, "Piotr Zarzycki" 
> wrote:
> >
> > Hi,
> >
> > I absolutely agree with Greg. In fact before I read his email I was
> > digging
> > into DataGrid and my initial thought was - when I set rowHeight = NaN
> > - My
> > rows should be adjusted automatically by the browser - why it does
> not
> > happen? This is exactly because of that:
> >
> > In browser I think things would be a lot easier if the
> > > internal 'lists' were managed as a single list of native rows
> > instead of
> > > composed columns of lists for DataGrids (specifically in the
> > browser).
> >
> >
> > Carlos do you think it would be good to change that implementation in
> > the
> > way as Greg is proposing ? Do you have time to work on that ?
> >
> > Thanks,
> > Piotr
> >
> > czw., 30 kwi 2020 o 20:48 Greg Dove 
> napisał(a):
> >
> > > For the variable rowHeight - that works fine for individual lists,
> > but for
> > > datagrid that needs to match across the corresponding renderers for
> > each
> > > item in the other columns, I did not check to see how that part
> > works.
> > >
> > > I haven't looked at the current Jewel implementation of DataGrid
> > yet, but I
> > > do think that in general we have a lot of 'Flex'/swf thinking in
> the
> > way
> > > things work for DataGrid support, and I am not sure it is the best
> > way for
> > > browsers. I understand the need for this in emulation components,
> but
> > > perhaps even the implementation there is not important if the
> > external api
> > > remains the same. In browser I think things would be a lot easier
> if
> > the
> > > internal 'lists' were managed as a single list of native rows
> > instead of
> > > composed columns of lists for DataGrids (specifically in the
> > browser).
> > > Columns could probably be managed then by custom uid-style classes
> > for
> > > styling of their parts of the 'rows'.
> > >
> > > I 

Re: Performance in lists

[Carlos Rovira]

Hi Raúl,

I think we are not dealing with height 100% in the virtual layout class.
Basic and Jewel are very similar ones in that part I think. Something to
look without doubt. Maybe I can fix it in a similar way I deal with
percentage heights in DataGrid. Will try as I get some time.

thanks




El mar., 5 may. 2020 a las 12:18, Raúl Núñez ()
escribió:

> Hi:
>
> Yishay -> debug mode
> Alex: Virtual List Jewel
>
> Anyway, my problem was in the height of Virtual List. With 100% height, all
> items in the list are displayed. If I use a fixed height, performance is
> good.
>
> Thanks!!
>
> El lun., 4 may. 2020 a las 21:27, Alex Harui ()
> escribió:
>
> > Which list? Mx, spark, jewel, basic?
> >
> > Get Outlook for Android
> >
> > 
> > From: Yishay Weiss 
> > Sent: Monday, May 4, 2020 11:38:02 AM
> > To: dev@royale.apache.org 
> > Subject: RE: Performance in lists
> >
> > Out of curiosity, are you running the debug or the release version?
> >
> > From: Raúl Núñez
> > Sent: Monday, May 4, 2020 9:28 PM
> > To: dev@royale.apache.org
> > Subject: Performance in lists
> >
> > Hi all,
> > we are setting a List with virtual layout and we're getting bad
> > performance.We have around 109 rows. And each item renderer has 18 labels
> > with bindings (so around 1900-2000 labels in screen). Doesn't seems many
> > labels to experience a bad performance (we'll reduce as we develop, this
> is
> > just a test).
> >
> > To show this list first time Royale needs 4sec, what seems many time. If
> I
> > remove the bindings and set up on dataChange in goes to 3sec.
> >
> > Couldn't check if new render initializers has something to do with this
> > problem, since are parte of the component. Maybe someone could give us a
> > clue or check if there's something that can generate such bad
> performance.
> >
> > I think Flex was not having that problem (I can't ensure since didn't
> try a
> > similar example in Flex).
> >
> > Thanks.
> >
> >
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Issue with rowHeight and big amount of data in cells

[Carlos Rovira]

Hi,

sorry for my late response here. flooded these days with lots of things.

I think the manage of row height is a problem since it needs to sync with
the rest of columns, maybe this could be big problem.

About to go rows instead columns, I think that will work better for that
case, but in that case I think we will have a problem with reordering of
columns and order data in a column (asc, desc).

Another point to take into account. I think many people in flex use to see
multi column data list as DataGrid. While working on Flex I end using more
List that DataGrid with renders that represent various pieces of
information (instead of DG cells). That worked very well. The problem in
this approach is to handle a Header in an easy way. For this reason I'm
working this days in a "HeaderList" that is just that a List with a top
header. This will be more efficient and also have a look and feel more
closer to modern apps nowadays [1] (I search quickly for something that
shows a bit like what I want to expose)

I think DG is needed when you need sorting columns or reordering, but if
that's not the case, I think we're overusing it since we come from a Flex
background and this days list based solutions are simpler, beautiful and
better.

That doesn't mean we don't have the problems stated here for DataGrid, just
saying that many of us should rethink where DG is worth it or not.

Piotr, about my time. I need to work on HeaderList since a client request
me. If you need DG solutions, maybe you can start working on new beads that
will be a total replace of the actual ones so we can try it and see if that
way is a better approach or not (rows against columns). If not I'll try to
reach to it later.

Thanks


[1] https://ps.w.org/wpforo/assets/screenshot-1.png?rev=2121401

El sáb., 2 may. 2020 a las 16:32, Alex Harui ()
escribió:

> I don't think there is one perfect implementation.  And that's why we have
> beads.  I think locked columns and individual cell selection are much
> easier with the current implementation, but I agree that variable row
> height will probably be easier if all cells are in a row container.
>
> We just need volunteers to create the other implementations.
>
> -Alex
>
> On 5/2/20, 12:17 AM, "Piotr Zarzycki"  wrote:
>
> Hi,
>
> I absolutely agree with Greg. In fact before I read his email I was
> digging
> into DataGrid and my initial thought was - when I set rowHeight = NaN
> - My
> rows should be adjusted automatically by the browser - why it does not
> happen? This is exactly because of that:
>
> In browser I think things would be a lot easier if the
> > internal 'lists' were managed as a single list of native rows
> instead of
> > composed columns of lists for DataGrids (specifically in the
> browser).
>
>
> Carlos do you think it would be good to change that implementation in
> the
> way as Greg is proposing ? Do you have time to work on that ?
>
> Thanks,
> Piotr
>
> czw., 30 kwi 2020 o 20:48 Greg Dove  napisał(a):
>
> > For the variable rowHeight - that works fine for individual lists,
> but for
> > datagrid that needs to match across the corresponding renderers for
> each
> > item in the other columns, I did not check to see how that part
> works.
> >
> > I haven't looked at the current Jewel implementation of DataGrid
> yet, but I
> > do think that in general we have a lot of 'Flex'/swf thinking in the
> way
> > things work for DataGrid support, and I am not sure it is the best
> way for
> > browsers. I understand the need for this in emulation components, but
> > perhaps even the implementation there is not important if the
> external api
> > remains the same. In browser I think things would be a lot easier if
> the
> > internal 'lists' were managed as a single list of native rows
> instead of
> > composed columns of lists for DataGrids (specifically in the
> browser).
> > Columns could probably be managed then by custom uid-style classes
> for
> > styling of their parts of the 'rows'.
> >
> > I think this probably covers off things like variable row height more
> > height easily, and makes hover/selection at row level etc easier. And
> > things like snapping the scrolling to the renderers (via native
> snap-to
> > support for scroll snapping iiuc) should be much easier also I
> think. Do I
> > have time to work on this ? No - definitely not anytime real soon.
> But I
> > had been thinking about it after digging into internals of DataGrid
> > recently.
> >
> >
> >
> >
> >
> >
> > On Fri, May 1, 2020 at 3:52 AM Alex Harui 
> > wrote:
> >
> > > I haven't looked at Jewel's Lists in detail, but if they have
> switched to
> > > scenario 2 (virtual rendering is probably a good default), then
> there are
> > > assumptions in the beads about fixed rowHeight.  But to handle 5,
> you
> > would
> > > start 

Re: Performance in lists

[Raúl Núñez]

Hi:

Yishay -> debug mode
Alex: Virtual List Jewel

Anyway, my problem was in the height of Virtual List. With 100% height, all
items in the list are displayed. If I use a fixed height, performance is
good.

Thanks!!

El lun., 4 may. 2020 a las 21:27, Alex Harui ()
escribió:

> Which list? Mx, spark, jewel, basic?
>
> Get Outlook for Android
>
> 
> From: Yishay Weiss 
> Sent: Monday, May 4, 2020 11:38:02 AM
> To: dev@royale.apache.org 
> Subject: RE: Performance in lists
>
> Out of curiosity, are you running the debug or the release version?
>
> From: Raúl Núñez
> Sent: Monday, May 4, 2020 9:28 PM
> To: dev@royale.apache.org
> Subject: Performance in lists
>
> Hi all,
> we are setting a List with virtual layout and we're getting bad
> performance.We have around 109 rows. And each item renderer has 18 labels
> with bindings (so around 1900-2000 labels in screen). Doesn't seems many
> labels to experience a bad performance (we'll reduce as we develop, this is
> just a test).
>
> To show this list first time Royale needs 4sec, what seems many time. If I
> remove the bindings and set up on dataChange in goes to 3sec.
>
> Couldn't check if new render initializers has something to do with this
> problem, since are parte of the component. Maybe someone could give us a
> clue or check if there's something that can generate such bad performance.
>
> I think Flex was not having that problem (I can't ensure since didn't try a
> similar example in Flex).
>
> Thanks.
>
>

Build failed in Jenkins: royale-asjs-agent2 #64

[apacheroyaleci]

See 


Changes:

[carlosrovira] rat-check: exclude src/assets/** like *.afdesign or other files 
that


--
[...truncated 2.05 MB...]

tweak-for-jsonly:

ide:

post-build:
[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

[mkdir] Created dir: 

 [copy] Copying 1 file to 

 [copy] Copying 1 file to 

[touch] Creating 

[touch] Creating 

[touch] Creating 


last-message-if-airsdk:

main:
 [echo] ant main target completed on 05/05/2020 10:16:16 AM

sample-themes:

check-runtime-env:

runtime-setup:

mustella-setup:

clean:
   [delete] Deleting: 


check-compiler-home:

check-compiler:

compile:
 [echo] Compiling mustella.swc
 [echo] ROYALE_HOME: 

 [echo] ROYALE_COMPILER_HOME: 

 [java] args:
 [java] 
+royalelib=
 [java] +playerglobal.version=11.7
 [java] +env.PLAYERGLOBAL_HOME=C:\adobe\flash
 [java] +env.AIR_HOME=C:\adobe\air\4.0\AdobeAIRSDK
 [java] -compiler.strict-xml=true
 [java] -compiler.targets=SWF,JSRoyale
 [java] 
-output=
 [java] 
-load-config=
 [java] 
-js-load-config=
 [java] 
-js-load-config+=
 [java] target:SWF
 [java] target:JSRoyale
 [java] COMPC
 [java] Loading configuration: 

 [java] 
 [java] 58086 bytes written to 

 in 2.351 seconds
 [java] COMPCJSCRoyale
 [java] 3.7652828 seconds
 [java] 
:
 col: 8 No definitions matching flash.net.* could be found.
 [java] 
 [java] import flash.net.*;
 [java]^
 [java] 
 [java] 
:
 col: 8 Definition flash.events.Event could not be found.
 [java] 
 [java] import flash.events.Event;
 [java]^
 [java] 
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m 
-Xmx1024m
 [java] Java Result: 2

compile-js:

main:

load-task:

marmotinni-setup:

prepare:
 [echo] Making lib directory 
:\jenkins\workspace\royale-asjs-agent2\marmotinni\java/lib
[mkdir] Created dir: 


selenium3-jar-check:

selenium3-jar:
[mkdir] Created dir: 


download-zip:
[mkdir] Created dir: 

  [get] Getting: https://bit.ly/2zm3ZzF
  [get] To: 

Re: Handling of "binary" files such as "afdesign" files?

[Carlos Rovira]

Hi,

just commit that change

El mar., 5 may. 2020 a las 10:49, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Hi Carlos,
>
> I have no objections to that ... however then I would also add some more
> explanation to the exclusion in the pom files rat-exclusion.
>
>
> Chris
>
>
> Am 05.05.20, 10:33 schrieb "Carlos Rovira" :
>
> Hi Chris,
>
> I'd like to have it "at hand" in the project. What about to move to
> some
> location. I think you suggested /src/assets or something like that
> Moving to other separate repo or CMS make it very cumbersome. I think
> that
> way we get both: not add it to a final output and as well get closer to
> manage in the project so we can modify and put the output in the
> resources
> folder
>
> El mar., 5 may. 2020 a las 10:18, Christofer Dutz (<
> christofer.d...@c-ware.de>) escribió:
>
> > Hi folks,
> >
> > the discussion on the release brought up the existence of the
> afdesign
> > files in one of the examples.
> >
> > These file seem to be the source project files Carlos used to create
> some
> > vector-graphics, so I think it’s good that they are available in the
> > project.
> >
> > However the current location is not ideal.
> >
> > First off all as it’s in the src/main/resources, they will be
> included in
> > any library of application, which is probably not what we want.
> >
> > On the other side it’s sort of a binary file as you need some third
> party
> > tool to edit it.
> >
> > The other thing is, that If someone uses the SVG and edits that … as
> soon
> > as someone then edits the original project file again to generate a
> new
> > SVG, the direct SVG changes get overwritten. Perhaps it’s a good
> idea to
> > put the project files somewhere else and to add a comment to the
> generated
> > SVGs to where to find the sources for the original file.
> >
> > How about adding the afdesign files to either confluence or some
> separate
> > repo? Otherwise I bet this will come up every now and then.
> >
> > Chris
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Handling of "binary" files such as "afdesign" files?

[Christofer Dutz]

Hi Carlos,

I have no objections to that ... however then I would also add some more 
explanation to the exclusion in the pom files rat-exclusion.


Chris


Am 05.05.20, 10:33 schrieb "Carlos Rovira" :

Hi Chris,

I'd like to have it "at hand" in the project. What about to move to some
location. I think you suggested /src/assets or something like that
Moving to other separate repo or CMS make it very cumbersome. I think that
way we get both: not add it to a final output and as well get closer to
manage in the project so we can modify and put the output in the resources
folder

El mar., 5 may. 2020 a las 10:18, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Hi folks,
>
> the discussion on the release brought up the existence of the afdesign
> files in one of the examples.
>
> These file seem to be the source project files Carlos used to create some
> vector-graphics, so I think it’s good that they are available in the
> project.
>
> However the current location is not ideal.
>
> First off all as it’s in the src/main/resources, they will be included in
> any library of application, which is probably not what we want.
>
> On the other side it’s sort of a binary file as you need some third party
> tool to edit it.
>
> The other thing is, that If someone uses the SVG and edits that … as soon
> as someone then edits the original project file again to generate a new
> SVG, the direct SVG changes get overwritten. Perhaps it’s a good idea to
> put the project files somewhere else and to add a comment to the generated
> SVGs to where to find the sources for the original file.
>
> How about adding the afdesign files to either confluence or some separate
> repo? Otherwise I bet this will come up every now and then.
>
> Chris
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Handling of "binary" files such as "afdesign" files?

[Carlos Rovira]

Hi Chris,

I'd like to have it "at hand" in the project. What about to move to some
location. I think you suggested /src/assets or something like that
Moving to other separate repo or CMS make it very cumbersome. I think that
way we get both: not add it to a final output and as well get closer to
manage in the project so we can modify and put the output in the resources
folder

El mar., 5 may. 2020 a las 10:18, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Hi folks,
>
> the discussion on the release brought up the existence of the afdesign
> files in one of the examples.
>
> These file seem to be the source project files Carlos used to create some
> vector-graphics, so I think it’s good that they are available in the
> project.
>
> However the current location is not ideal.
>
> First off all as it’s in the src/main/resources, they will be included in
> any library of application, which is probably not what we want.
>
> On the other side it’s sort of a binary file as you need some third party
> tool to edit it.
>
> The other thing is, that If someone uses the SVG and edits that … as soon
> as someone then edits the original project file again to generate a new
> SVG, the direct SVG changes get overwritten. Perhaps it’s a good idea to
> put the project files somewhere else and to add a comment to the generated
> SVGs to where to find the sources for the original file.
>
> How about adding the afdesign files to either confluence or some separate
> repo? Otherwise I bet this will come up every now and then.
>
> Chris
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Handling of "binary" files such as "afdesign" files?

[Christofer Dutz]

Hi folks,

the discussion on the release brought up the existence of the afdesign files in 
one of the examples.

These file seem to be the source project files Carlos used to create some 
vector-graphics, so I think it’s good that they are available in the project.

However the current location is not ideal.

First off all as it’s in the src/main/resources, they will be included in any 
library of application, which is probably not what we want.

On the other side it’s sort of a binary file as you need some third party tool 
to edit it.

The other thing is, that If someone uses the SVG and edits that … as soon as 
someone then edits the original project file again to generate a new SVG, the 
direct SVG changes get overwritten. Perhaps it’s a good idea to put the project 
files somewhere else and to add a comment to the generated SVGs to where to 
find the sources for the original file.

How about adding the afdesign files to either confluence or some separate repo? 
Otherwise I bet this will come up every now and then.

Chris

Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

[Alex Harui]

The CI Jobs indicate that my changes worked and the groovy files will be in the 
unified source package.  I also reverted the pom changes made by the 
release-plugin so the branches should be ready to go.  That said, you might 
want to wait until other PMC members have reviewed RC3.

HTH,
-Alex

On 5/4/20, 11:24 PM, "Alex Harui"  wrote:

Thanks Yishay.

I am putting together CI jobs to verify that my changes will pick up the 
groovy files.  The files that changed are part of the source package and were 
tagged as RC3 and one of them is in royale-compiler which is why we must start 
essentially from the beginning.  You can skip the CI steps that create the 
release branches and set version numbers, but we have to run pretty much all of 
the steps you ran last time (2, 3, 6, 7,  10, 11, 13).  If I have time I will 
revert the pom changes the release-plugin makes to the release branch.

-Alex

On 5/4/20, 10:48 PM, "Yishay Weiss"  wrote:

Hi All,

It’s starting to look like the cleanest solution is to start an RC4. I 
intend to start working on that in 10 hours or so. In the meantime, I’d 
appreciate it if people took time to look at RC3, so we don’t end up with an 
RC5.

Thanks,
Yishay

From: Alex Harui
Sent: Tuesday, May 5, 2020 12:22 AM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The Ant packages only contain things we know we want to release.  
Top-level folders are not whitelisted in because you never know what might be 
in them.  We've never released the manualtests folder for example, so we don't 
have to spend time certifying it for code quality and build-ability, license, 
etc.  We've never shipped the top-level src folder because it used to only 
contain a site folder that wasn't going to be of use to our users.  So when the 
groovy scripts were added to the src folder, they were not included in the Ant 
packaging.

We also have never voted on and released the 3 top-level Maven source 
packages, mainly to reduce the amount of work the voters need to do.  The Maven 
source packages are "tested" by the Maven release plugin, and the 3 packages 
are unpacked and repacked into the Ant package.  So far, we've found that two 
new files were missed.

How many of our users build the source package is one factor and I 
think the answer for Royale is that few people do it.  Apache release are 
supposed to "build" and the Ant source package will build with Ant.

IMO, the best next thing for PMC members to do is to download the RC 
and try it with Ant, and/or use Maven to point to the staging repos and test 
the artifacts that have been staged up there and see if we see any other big 
issues.  Maybe we'll find something else and make RC4 an obvious choice.

Other choices are:
A) Release RC3 with documenting all of the problems in the online 
release notes
B) Also certifying and voting on the 3 Maven source packages.

IMO, what we don't want to see happen is for folks to not test RC3 and 
find out some big issue later.

My 2 cents,
-Alex

On 5/4/20, 12:24 PM, "Christofer Dutz"  
wrote:

The more I think about it  it's actually not good that the 
groovy script isn't in there as this way you will not be able to download, 
unpack and build anything with maven.
As maven calls this script as the first thing in every maven build 
to ensure everything is setup.

Without this, you will never get past the Maven validate phase ... 
so if I had a vote, I would probably vote -1 on that.

When ere these files getting lost? In the initial source bundles 
built by maven they should be in there ... so probably you only have to re-do 
some of the last steps.

Chris



Am 04.05.20, 20:13 schrieb "Yishay Weiss" :

Ok, I just verified that copying the script to the right 
location makes the groovy plugin happy, so it doesn’t seem to be a windows or 
backslash issue after all.

I need an explanation on when Maven will be used to build the 
Ant sources to decide if it’s worth an RC4.

From: Alex Harui
Sent: Monday, May 4, 2020 7:14 PM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The groovy script is not in the ant packages on dist.  My 
earlier email tried to explain that.   Not every file in the repo ends up in 
the ant packages on purpose.   If we do an RC4, hopefully the changes I made 

Build failed in Jenkins: royale-compiler-integration-tests #869

[apacheroyaleci]

See 


Changes:

[thomas.darocha] Add namespace qualifier in metadata

[thomas.darocha] Accept and replace config variables


--
[...truncated 52.55 KB...]
[junit] BaseAudioContext.prototype.removeEventListener = function(
[junit] 
[junit] 
[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:340: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.dispatchEvent = function(evt) {};
[junit] 
[junit] 
[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager printSummary
[junit] WARNING: 0 error(s), 3 warning(s)
[junit] 

[junit] Math parameters not found!  0
[junit] 

[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:322: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.addEventListener = function(type, 
listener, opt_options) {
[junit] 
[junit] 
[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:332: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.removeEventListener = function(
[junit] 
[junit] 
[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:340: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.dispatchEvent = function(evt) {};
[junit] 
[junit] 
[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager printSummary
[junit] WARNING: 0 error(s), 3 warning(s)
[junit] Math parameters not found!  0
[junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
2.493 sec
[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:322: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.addEventListener = function(type, 
listener, opt_options) {
[junit] 
[junit] 
[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:332: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.removeEventListener = function(
[junit] 
[junit] 
[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager println
[junit] WARNING: [missing]:340: WARNING - name BaseAudioContext is not 
defined in the externs.
[junit] BaseAudioContext.prototype.dispatchEvent = function(evt) {};
[junit] 
[junit] 
[junit] May 05, 2020 7:02:31 AM 
com.google.javascript.jscomp.LoggerErrorManager printSummary
[junit] WARNING: 0 error(s), 3 warning(s)
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestPackageNamespace
[junit] foo parameters not found!  0
[junit] bar parameters not found!  0
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.01 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestReferenceModel
[junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 
0.005 sec
[junit] Running 
org.apache.royale.compiler.internal.codegen.typedefs.TestTypeTypedefs
[junit] foo parameters not found!  0
[junit] bar parameters not found!  0
[junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.023 sec
[junit] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

main:

jar-test:
 [echo] using externc.jar from 
C:/jenkins/workspace/royale-compiler-integration-tests/compiler-jx/lib
 [java] Math parameters not found!  0
 [java] Reflect parameters not found!  0
 [java] Atomics parameters not found!  0
 [java] Intl parameters not found!  0
 [java] 9.5822889 seconds
 [java] Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 -Xms384m -Xmx2g

download:
 [echo] basedir is 

 [echo] ROYALE_COMPILER_HOME is ${ROYALE_COMPILER_HOME}
 [echo] ROYALE_COMPILER_HOME is 

Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

[Alex Harui]

I removed TDF and ASDoc from running after asjs.  That should reduce the 
changes you get blocked by something that takes a long time.  We can put it 
back later.

-Alex

On 5/4/20, 11:29 PM, "Yishay Weiss"  wrote:

Great. Thanks to Alex and Chris for reviewing this. Om, is there any chance 
you can look at the CI configuration and see if the jobs are still distributed 
between the 2 agents? Last time I looked it looked like they were all 
configured to work with agent1, which would mean TDF slowing down the build 
again. I may have missed something.

From: Alex Harui
Sent: Tuesday, May 5, 2020 9:24 AM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

Thanks Yishay.

I am putting together CI jobs to verify that my changes will pick up the 
groovy files.  The files that changed are part of the source package and were 
tagged as RC3 and one of them is in royale-compiler which is why we must start 
essentially from the beginning.  You can skip the CI steps that create the 
release branches and set version numbers, but we have to run pretty much all of 
the steps you ran last time (2, 3, 6, 7,  10, 11, 13).  If I have time I will 
revert the pom changes the release-plugin makes to the release branch.

-Alex

On 5/4/20, 10:48 PM, "Yishay Weiss"  wrote:

Hi All,

It’s starting to look like the cleanest solution is to start an RC4. I 
intend to start working on that in 10 hours or so. In the meantime, I’d 
appreciate it if people took time to look at RC3, so we don’t end up with an 
RC5.

Thanks,
Yishay

From: Alex Harui
Sent: Tuesday, May 5, 2020 12:22 AM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The Ant packages only contain things we know we want to release.  
Top-level folders are not whitelisted in because you never know what might be 
in them.  We've never released the manualtests folder for example, so we don't 
have to spend time certifying it for code quality and build-ability, license, 
etc.  We've never shipped the top-level src folder because it used to only 
contain a site folder that wasn't going to be of use to our users.  So when the 
groovy scripts were added to the src folder, they were not included in the Ant 
packaging.

We also have never voted on and released the 3 top-level Maven source 
packages, mainly to reduce the amount of work the voters need to do.  The Maven 
source packages are "tested" by the Maven release plugin, and the 3 packages 
are unpacked and repacked into the Ant package.  So far, we've found that two 
new files were missed.

How many of our users build the source package is one factor and I 
think the answer for Royale is that few people do it.  Apache release are 
supposed to "build" and the Ant source package will build with Ant.

IMO, the best next thing for PMC members to do is to download the RC 
and try it with Ant, and/or use Maven to point to the staging repos and test 
the artifacts that have been staged up there and see if we see any other big 
issues.  Maybe we'll find something else and make RC4 an obvious choice.

Other choices are:
A) Release RC3 with documenting all of the problems in the online 
release notes
B) Also certifying and voting on the 3 Maven source packages.

IMO, what we don't want to see happen is for folks to not test RC3 and 
find out some big issue later.

My 2 cents,
-Alex

On 5/4/20, 12:24 PM, "Christofer Dutz"  
wrote:

The more I think about it  it's actually not good that the 
groovy script isn't in there as this way you will not be able to download, 
unpack and build anything with maven.
As maven calls this script as the first thing in every maven build 
to ensure everything is setup.

Without this, you will never get past the Maven validate phase ... 
so if I had a vote, I would probably vote -1 on that.

When ere these files getting lost? In the initial source bundles 
built by maven they should be in there ... so probably you only have to re-do 
some of the last steps.

Chris



Am 04.05.20, 20:13 schrieb "Yishay Weiss" :

Ok, I just verified that copying the script to the right 
location makes the groovy plugin happy, so it doesn’t seem to be a windows or 
backslash issue after all.

I need an explanation on when Maven will be used to build the 
Ant sources to decide if it’s worth an RC4.

From: Alex Harui
Sent: Monday, May 4, 2020 7:14 PM
To: 

RE: [DISCUSS] Discuss Release Apache Royale 0.9.7

[Yishay Weiss]

Great. Thanks to Alex and Chris for reviewing this. Om, is there any chance you 
can look at the CI configuration and see if the jobs are still distributed 
between the 2 agents? Last time I looked it looked like they were all 
configured to work with agent1, which would mean TDF slowing down the build 
again. I may have missed something.

From: Alex Harui
Sent: Tuesday, May 5, 2020 9:24 AM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

Thanks Yishay.

I am putting together CI jobs to verify that my changes will pick up the groovy 
files.  The files that changed are part of the source package and were tagged 
as RC3 and one of them is in royale-compiler which is why we must start 
essentially from the beginning.  You can skip the CI steps that create the 
release branches and set version numbers, but we have to run pretty much all of 
the steps you ran last time (2, 3, 6, 7,  10, 11, 13).  If I have time I will 
revert the pom changes the release-plugin makes to the release branch.

-Alex

On 5/4/20, 10:48 PM, "Yishay Weiss"  wrote:

Hi All,

It’s starting to look like the cleanest solution is to start an RC4. I 
intend to start working on that in 10 hours or so. In the meantime, I’d 
appreciate it if people took time to look at RC3, so we don’t end up with an 
RC5.

Thanks,
Yishay

From: Alex Harui
Sent: Tuesday, May 5, 2020 12:22 AM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The Ant packages only contain things we know we want to release.  Top-level 
folders are not whitelisted in because you never know what might be in them.  
We've never released the manualtests folder for example, so we don't have to 
spend time certifying it for code quality and build-ability, license, etc.  
We've never shipped the top-level src folder because it used to only contain a 
site folder that wasn't going to be of use to our users.  So when the groovy 
scripts were added to the src folder, they were not included in the Ant 
packaging.

We also have never voted on and released the 3 top-level Maven source 
packages, mainly to reduce the amount of work the voters need to do.  The Maven 
source packages are "tested" by the Maven release plugin, and the 3 packages 
are unpacked and repacked into the Ant package.  So far, we've found that two 
new files were missed.

How many of our users build the source package is one factor and I think 
the answer for Royale is that few people do it.  Apache release are supposed to 
"build" and the Ant source package will build with Ant.

IMO, the best next thing for PMC members to do is to download the RC and 
try it with Ant, and/or use Maven to point to the staging repos and test the 
artifacts that have been staged up there and see if we see any other big 
issues.  Maybe we'll find something else and make RC4 an obvious choice.

Other choices are:
A) Release RC3 with documenting all of the problems in the online release 
notes
B) Also certifying and voting on the 3 Maven source packages.

IMO, what we don't want to see happen is for folks to not test RC3 and find 
out some big issue later.

My 2 cents,
-Alex

On 5/4/20, 12:24 PM, "Christofer Dutz"  wrote:

The more I think about it  it's actually not good that the groovy 
script isn't in there as this way you will not be able to download, unpack and 
build anything with maven.
As maven calls this script as the first thing in every maven build to 
ensure everything is setup.

Without this, you will never get past the Maven validate phase ... so 
if I had a vote, I would probably vote -1 on that.

When ere these files getting lost? In the initial source bundles built 
by maven they should be in there ... so probably you only have to re-do some of 
the last steps.

Chris



Am 04.05.20, 20:13 schrieb "Yishay Weiss" :

Ok, I just verified that copying the script to the right location 
makes the groovy plugin happy, so it doesn’t seem to be a windows or backslash 
issue after all.

I need an explanation on when Maven will be used to build the Ant 
sources to decide if it’s worth an RC4.

From: Alex Harui
Sent: Monday, May 4, 2020 7:14 PM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The groovy script is not in the ant packages on dist.  My earlier 
email tried to explain that.   Not every file in the repo ends up in the ant 
packages on purpose.   If we do an RC4, hopefully the changes I made will pick 
those two files.

-Alex

On 5/4/20, 8:54 AM, "Yishay Weiss"  wrote:

.mvn folder 

Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

[Alex Harui]

Thanks Yishay.

I am putting together CI jobs to verify that my changes will pick up the groovy 
files.  The files that changed are part of the source package and were tagged 
as RC3 and one of them is in royale-compiler which is why we must start 
essentially from the beginning.  You can skip the CI steps that create the 
release branches and set version numbers, but we have to run pretty much all of 
the steps you ran last time (2, 3, 6, 7,  10, 11, 13).  If I have time I will 
revert the pom changes the release-plugin makes to the release branch.

-Alex

On 5/4/20, 10:48 PM, "Yishay Weiss"  wrote:

Hi All,

It’s starting to look like the cleanest solution is to start an RC4. I 
intend to start working on that in 10 hours or so. In the meantime, I’d 
appreciate it if people took time to look at RC3, so we don’t end up with an 
RC5.

Thanks,
Yishay

From: Alex Harui
Sent: Tuesday, May 5, 2020 12:22 AM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The Ant packages only contain things we know we want to release.  Top-level 
folders are not whitelisted in because you never know what might be in them.  
We've never released the manualtests folder for example, so we don't have to 
spend time certifying it for code quality and build-ability, license, etc.  
We've never shipped the top-level src folder because it used to only contain a 
site folder that wasn't going to be of use to our users.  So when the groovy 
scripts were added to the src folder, they were not included in the Ant 
packaging.

We also have never voted on and released the 3 top-level Maven source 
packages, mainly to reduce the amount of work the voters need to do.  The Maven 
source packages are "tested" by the Maven release plugin, and the 3 packages 
are unpacked and repacked into the Ant package.  So far, we've found that two 
new files were missed.

How many of our users build the source package is one factor and I think 
the answer for Royale is that few people do it.  Apache release are supposed to 
"build" and the Ant source package will build with Ant.

IMO, the best next thing for PMC members to do is to download the RC and 
try it with Ant, and/or use Maven to point to the staging repos and test the 
artifacts that have been staged up there and see if we see any other big 
issues.  Maybe we'll find something else and make RC4 an obvious choice.

Other choices are:
A) Release RC3 with documenting all of the problems in the online release 
notes
B) Also certifying and voting on the 3 Maven source packages.

IMO, what we don't want to see happen is for folks to not test RC3 and find 
out some big issue later.

My 2 cents,
-Alex

On 5/4/20, 12:24 PM, "Christofer Dutz"  wrote:

The more I think about it  it's actually not good that the groovy 
script isn't in there as this way you will not be able to download, unpack and 
build anything with maven.
As maven calls this script as the first thing in every maven build to 
ensure everything is setup.

Without this, you will never get past the Maven validate phase ... so 
if I had a vote, I would probably vote -1 on that.

When ere these files getting lost? In the initial source bundles built 
by maven they should be in there ... so probably you only have to re-do some of 
the last steps.

Chris



Am 04.05.20, 20:13 schrieb "Yishay Weiss" :

Ok, I just verified that copying the script to the right location 
makes the groovy plugin happy, so it doesn’t seem to be a windows or backslash 
issue after all.

I need an explanation on when Maven will be used to build the Ant 
sources to decide if it’s worth an RC4.

From: Alex Harui
Sent: Monday, May 4, 2020 7:14 PM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The groovy script is not in the ant packages on dist.  My earlier 
email tried to explain that.   Not every file in the repo ends up in the ant 
packages on purpose.   If we do an RC4, hopefully the changes I made will pick 
those two files.

-Alex

On 5/4/20, 8:54 AM, "Yishay Weiss"  wrote:

.mvn folder exists in GitHub but not in SVN. Could that be 
related?

From: Yishay Weiss
Sent: Monday, May 4, 2020 6:40 PM
To: dev@royale.apache.org
Subject: RE: [DISCUSS] Discuss Release Apache Royale 0.9.7

Look down-thread:

> >  [exec] [ERROR] Failed to execute 

Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

[Christofer Dutz]

Hi Yishay,

Thank you very much for that. I was starting to get worried after seeing Alex' 
response.

And replying to that (Alex' email):
- Apache releases sources, not binaries (The binaries are convenience). So 
releasing something that doesn't build is topmost-validity reason for a -1 vote.
- As it's difficult to keep track of what's needed in a source bundle and 
what's not Maven has the simple convention of:
- Everything in the target directory is excluded, the rest is included 
per default
- You can add exclusions to the inclusions (usually it's best practice 
to automatically exclude everything in the gitignore
- Regarding the amount of additional work: 
- It's 2 groovy files ... 
- You could simply remove the src/site directories in the future ... I 
set them up years ago as a proposal for an alternate way to build the FlexJS 
website

And Alex, considering the intensity of you insisting everything to be 
reproducible on Ant and Maven and all sorts of additional hoops Apache is not 
even asking for, it puzzles me how you could even consider releasing something 
that doesn't build with one of the two equally supported build-systems.

So I'll put all my non-binding vote-weight on -1 for releasing RC3 and +1 for 
creating a RC4.

However I'm not sure however if this is even needed and perhaps you only need 
to do the steps for creating the big source-archive again. As Alex mentioned, 
it seems to copy the content of the maven source assemblies ... these do 
contain the groovy files. So I would guess you only need to continue from the 
last step involving maven. But I could be wrong as what actually happens in the 
Ant build isn't really documented anywhere I could find it.

Chris


Am 05.05.20, 07:48 schrieb "Yishay Weiss" :

Hi All,

It’s starting to look like the cleanest solution is to start an RC4. I 
intend to start working on that in 10 hours or so. In the meantime, I’d 
appreciate it if people took time to look at RC3, so we don’t end up with an 
RC5.

Thanks,
Yishay

From: Alex Harui
Sent: Tuesday, May 5, 2020 12:22 AM
To: dev@royale.apache.org
Subject: Re: [DISCUSS] Discuss Release Apache Royale 0.9.7

The Ant packages only contain things we know we want to release.  Top-level 
folders are not whitelisted in because you never know what might be in them.  
We've never released the manualtests folder for example, so we don't have to 
spend time certifying it for code quality and build-ability, license, etc.  
We've never shipped the top-level src folder because it used to only contain a 
site folder that wasn't going to be of use to our users.  So when the groovy 
scripts were added to the src folder, they were not included in the Ant 
packaging.

We also have never voted on and released the 3 top-level Maven source 
packages, mainly to reduce the amount of work the voters need to do.  The Maven 
source packages are "tested" by the Maven release plugin, and the 3 packages 
are unpacked and repacked into the Ant package.  So far, we've found that two 
new files were missed.

How many of our users build the source package is one factor and I think 
the answer for Royale is that few people do it.  Apache release are supposed to 
"build" and the Ant source package will build with Ant.

IMO, the best next thing for PMC members to do is to download the RC and 
try it with Ant, and/or use Maven to point to the staging repos and test the 
artifacts that have been staged up there and see if we see any other big 
issues.  Maybe we'll find something else and make RC4 an obvious choice.

Other choices are:
A) Release RC3 with documenting all of the problems in the online release 
notes
B) Also certifying and voting on the 3 Maven source packages.

IMO, what we don't want to see happen is for folks to not test RC3 and find 
out some big issue later.

My 2 cents,
-Alex

On 5/4/20, 12:24 PM, "Christofer Dutz"  wrote:

The more I think about it  it's actually not good that the groovy 
script isn't in there as this way you will not be able to download, unpack and 
build anything with maven.
As maven calls this script as the first thing in every maven build to 
ensure everything is setup.

Without this, you will never get past the Maven validate phase ... so 
if I had a vote, I would probably vote -1 on that.

When ere these files getting lost? In the initial source bundles built 
by maven they should be in there ... so probably you only have to re-do some of 
the last steps.

Chris



Am 04.05.20, 20:13 schrieb "Yishay Weiss" :

Ok, I just verified that copying the script to the right location 
makes the groovy plugin happy, so it doesn’t seem to be a windows or backslash 
issue after all.

I need an explanation on when Maven will be used to build the Ant 
sources