Jenkins build is back to normal : royale-compiler-integration-tests #747

[apacheroyaleci]

See 

Jenkins build is back to normal : royale-asjs_MXTests #825

[apacheroyaleci]

See 

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

[apacheroyaleci]

See 


Changes:


--
Started by upstream project "royale-asjs" build number 959
originally caused by:
 Started by upstream project "royale-asjs_jsonly" build number 1134
 originally caused by:
  Started by an SCM change
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on agent1 in workspace 

No credentials specified
 > C:\Program Files\Git\cmd\git.exe rev-parse --is-inside-work-tree # timeout=10
ERROR: Workspace has a .git repository, but it appears to be corrupt.
hudson.plugins.git.GitException: Error performing git command
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2183)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2142)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2138)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1743)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1755)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.hasGitRepo(CliGitAPIImpl.java:331)
at hudson.plugins.git.GitAPI.hasGitRepo(GitAPI.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:929)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:903)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:855)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at hudson.Proc$LocalProc.(Proc.java:258)
at hudson.Proc$LocalProc.(Proc.java:219)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:937)
at hudson.Launcher$ProcStarter.start(Launcher.java:455)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2170)
... 21 more
Cloning the remote Git repository
Cloning repository https://github.com/apache/royale-compiler
 > C:\Program Files\Git\cmd\git.exe init 
 > 
 >  # timeout=10
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not init 

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:918)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:710)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:212)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:369)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
agent1
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
at 
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:957)
at 

Build failed in Jenkins: royale-asjs_MXTests #824

[apacheroyaleci]

See 


Changes:

[carlosrovira] AMFCompressionException: required javadoc descriptions

[carlosrovira] virtual-list: solve reassign dataprovider not refreshing the 
list with

[carlosrovira] tour-de-jewel: show virtual list refresh all data example

[carlosrovira] jewel-togglebutton: fix selected unboxed and outlined styles

[carlosrovira] jewel-theme: add new "option-with-sass-compile" to produce the 
updated

[carlosrovira] tour-de-jewel: show togglebuttons with outlined and unboxed 
styles

[carlosrovira] BE0014: update example with a togglebutton to show/hide the rule


--
[...truncated 1.25 MB...]
 [java] 
 [java] 
:
 col: 2 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var stageY:Number;
 [java] ^
 [java] 
 [java] 
:
 col: 2 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var shiftKey:Boolean;
 [java] ^
 [java] 
 [java] 
:
 col: 2 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var relatedObject:String;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var window:String;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var type:String;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var char:String;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var charCode:uint;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var ctrlKey:Boolean;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var key:String;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var keys:Array;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var keyCode:uint;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var keyLocation:uint;
 [java] ^
 [java] 
 [java] 
:
 col: 5 public var may not work in minified JS output.  Use getter/setter 
instead.
 [java] 
 [java] public var repeatCount:uint = 1;
 [java] ^
 [java] 
 [java] 

Re: Control over export/rename: Finally giving up

[Josh Tynjala]

Thanks for the info about Object.defineProperties(). That could be a way to
provide a workaround that doesn't mess too much with other stuff.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 12:45 PM Alex Harui 
wrote:

>
>
> On 3/26/20, 12:23 PM, "Josh Tynjala"  wrote:
>
> We can walk the AST if we have the source code. However, if an MXML
> class
> gets compiled into a SWC, I don't think there's a way to figure out
> which
> properties are being set in MXML from the definitions alone. When I was
> investigating some things, I tried the AST walk until I realized that
> it
> only worked in my app project, and not with the classes that I was
> using
> from framework SWCs.
>
> One possibility is that the compiler scans every JS file and looks for the
> MXMLDescriptor and scans it for strings.  Also have to look for the
> properties array as well.
>
> I might actually end up looking at adding an option to convert public
> vars
> into getters/setters first. Should be easier than some of the
> alternatives,
> which I can dig into more later.
>
> FWIW, AFAICT, any Object.defineProperties structure blocks renaming
> through the entire compilation, not just within the file being visited.  In
> fact, I'm not even sure it has to be Object.defineProperties.  It looks
> like there is some criteria for being a global structure.  So to me, it
> looks like you can prevent a rename, not only by swapping in a legitimate
> getter/setter for the public var, but also by having some global structure,
> possibly in an Object.defineProperties attached to the app that defines a
> bunch of empty properties on some never-to-be-used object and then Closure
> will not rename those properties on other objects.
>
> Of course, I could be wrong, but that's what I think I've seen.  I think I
> saw that including some class with a getter/setter would cause properties
> in other classes that use the same property name to not be renamed.
>
> HTH,
> -Alex
>
>
>

Re: Control over export/rename: Finally giving up

[Alex Harui]

On 3/26/20, 12:23 PM, "Josh Tynjala"  wrote:

We can walk the AST if we have the source code. However, if an MXML class
gets compiled into a SWC, I don't think there's a way to figure out which
properties are being set in MXML from the definitions alone. When I was
investigating some things, I tried the AST walk until I realized that it
only worked in my app project, and not with the classes that I was using
from framework SWCs.

One possibility is that the compiler scans every JS file and looks for the 
MXMLDescriptor and scans it for strings.  Also have to look for the properties 
array as well.

I might actually end up looking at adding an option to convert public vars
into getters/setters first. Should be easier than some of the alternatives,
which I can dig into more later.

FWIW, AFAICT, any Object.defineProperties structure blocks renaming through the 
entire compilation, not just within the file being visited.  In fact, I'm not 
even sure it has to be Object.defineProperties.  It looks like there is some 
criteria for being a global structure.  So to me, it looks like you can prevent 
a rename, not only by swapping in a legitimate getter/setter for the public 
var, but also by having some global structure, possibly in an 
Object.defineProperties attached to the app that defines a bunch of empty 
properties on some never-to-be-used object and then Closure will not rename 
those properties on other objects.

Of course, I could be wrong, but that's what I think I've seen.  I think I saw 
that including some class with a getter/setter would cause properties in other 
classes that use the same property name to not be renamed.

HTH,
-Alex

Re: Control over export/rename: Finally giving up

[Josh Tynjala]

We can walk the AST if we have the source code. However, if an MXML class
gets compiled into a SWC, I don't think there's a way to figure out which
properties are being set in MXML from the definitions alone. When I was
investigating some things, I tried the AST walk until I realized that it
only worked in my app project, and not with the classes that I was using
from framework SWCs.

I might actually end up looking at adding an option to convert public vars
into getters/setters first. Should be easier than some of the alternatives,
which I can dig into more later.

I like your idea of a swappable MXMLDataInterpreter. Something for me to
consider.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 11:58 AM Alex Harui 
wrote:

>
>
> On 3/26/20, 11:14 AM, "Josh Tynjala"  wrote:
>
> Snip...
>
> I'm currently looking into a way to include a function with the MXML
> descriptor that can be used to set the property, even if it has been
> renamed. An evolution of what I proposed a couple of months ago.
> However, I
> plan to keep both the string name and the value inside the descriptor
> so
> that it does not affect your debugging approach.
>
> A single property in the MXML descriptor looks like this now:
>
> [
> "someProperty",
> true,
> 123.4
> ]
>
> It might look something like this after my change:
>
> [
> "someProperty",
> function(value) { this.someProperty = value; },
> true,
> 123.4
> ]
>
> If the function exists, it will be called like this (where host is the
> component/object being created):
>
> var func = descriptor[i];
> func.call(host, value);
>
> This will ensure that someProperty can be renamed, and all of the
> original
> data is preserved for debugging.
>
> I should be able to make the compiler smart enough to only include the
> function where necessary (public vars) and omit it when not necessary
> (public setters) to save on file size and make it PAYG. I would, of
> course,
> also add a compiler option to include no functions in the descriptor
> (in
> other words, keep the existing behavior).
>
> Please consider the PAYG aspects of this approach.  Without thinking about
> it too much, it will at minimum make the MXMLDataInterpreter have to think
> harder whether you use that capability or not.
>
> It might be that we need to make sure there is an easy way to replace
> which MXMLDataIntepreter gets used so that more sophisticated logic can be
> plugged in if the app developer asks for it.  And if we can do that, then
> it might just be easier to have a test to see if the property exists before
> setting it and if it doesn't check some sort of rename map.
>
> Or, can we know which classes are having properties set via MXML and swap
> out public vars for getter/setters?
>
> HTH,
> -Alex
>
>

Re: Numbers not initialized to NaN

[Alex Harui]

I can’t view the image.

What is ValidateRadioButtonBox based on?  Also what layout is it using?

Royale defaults to not measuring stuff.  Even MXRoyale tries to skip measuring 
stuff.  Measuring stuff is expensive and in the browser, often wrong.  You may 
need to emulate measuredHeight for mx:RadioButton to make your code happy.

If ValidateRadioButtonBox doesn’t have custom layout logic, try creating a test 
case with its base class instead.  And if that fails and you can’t figure out 
why, post that example.

HTH,
-Alex

From: Yishay Weiss 
Reply-To: "dev@royale.apache.org" 
Date: Thursday, March 26, 2020 at 11:27 AM
To: "dev@royale.apache.org" 
Subject: RE: Numbers not initialized to NaN

My problem is that this code



  
  
  



Looks like this

[cid:image001.png@01D603AC.12544860]

It’s because the measured height for buttons 1 and 2 is different from button 
3. Moreover, button 3 changes its measured height in different phases of the 
layout due to its positioner.offsetHeight changing.

The weird thing is that positioner looks exactly the same [1], whether its 
offsetHeight is 19 or 34. Any ideas would be welcome.

[1]
3

From: Yishay Weiss
Sent: Thursday, March 26, 2020 7:50 PM
To: dev@royale.apache.org
Subject: RE: Numbers not initialized to NaN

Investigating. Unrelated to my subject line.


From: Alex Harui 
Sent: Thursday, March 26, 2020 7:49:42 PM
To: dev@royale.apache.org 
Subject: Re: Numbers not initialized to NaN

If I understood that correctly, that's what I would expect, so I don't know why 
it would matter if the value was undefined or initialized to NaN.  And thus, 
I'm not sure why the code went in the wrong direction.

On 3/26/20, 9:45 AM, "Yishay Weiss"  wrote:

isNaN(undefined) is actually true, same as isNaN(NaN).

From: Yishay Weiss
Sent: Thursday, March 26, 2020 6:27 PM
To: dev@royale.apache.org
Subject: RE: Numbers not initialized to NaN

Ok, I’ll investigate why it’s undefined.

> isNaN(percentHeight) is thus evaluated

I meant !isNaN

Thanks.


From: Josh Tynjala
Sent: Thursday, March 26, 2020 6:23 PM
To: Apache Royale Development
Subject: Re: Numbers not initialized to NaN

Numbers should be initialized to NaN, unless you've added
-js-default-initializers=false to your compiler options.

--
Josh Tynjala
Bowler Hat LLC 
>


On Thu, Mar 26, 2020 at 9:17 AM Yishay Weiss  wrote:

> I think this might have come up in one of my previous posts so my
> apologies if I’m repeating a question. In Flex.as we have the following
> code:
>
> if (!isNaN(percentHeight)
> && child.includeInLayout)
> {
> height =
> Math.max(child.minHeight,
>
>   Math.min(child.maxHeight,
>
>   ((percentHeight >= 100) ? h : h * percentHeight / 100)));
> }
>
> percentHeight, which is a Number, seems to be initialized to undefined.
> isNaN(percentHeight) is thus evaluated to true which results in the wrong
> height being set.
>
> Should I change the code to check for undefined instead of NaN, or should
> the compiler initialized to NaN?
>

Re: Control over export/rename: Finally giving up

[Alex Harui]

On 3/26/20, 11:14 AM, "Josh Tynjala"  wrote:

Snip...

I'm currently looking into a way to include a function with the MXML
descriptor that can be used to set the property, even if it has been
renamed. An evolution of what I proposed a couple of months ago. However, I
plan to keep both the string name and the value inside the descriptor so
that it does not affect your debugging approach.

A single property in the MXML descriptor looks like this now:

[
"someProperty",
true,
123.4
]

It might look something like this after my change:

[
"someProperty",
function(value) { this.someProperty = value; },
true,
123.4
]

If the function exists, it will be called like this (where host is the
component/object being created):

var func = descriptor[i];
func.call(host, value);

This will ensure that someProperty can be renamed, and all of the original
data is preserved for debugging.

I should be able to make the compiler smart enough to only include the
function where necessary (public vars) and omit it when not necessary
(public setters) to save on file size and make it PAYG. I would, of course,
also add a compiler option to include no functions in the descriptor (in
other words, keep the existing behavior).

Please consider the PAYG aspects of this approach.  Without thinking about it 
too much, it will at minimum make the MXMLDataInterpreter have to think harder 
whether you use that capability or not.

It might be that we need to make sure there is an easy way to replace which 
MXMLDataIntepreter gets used so that more sophisticated logic can be plugged in 
if the app developer asks for it.  And if we can do that, then it might just be 
easier to have a test to see if the property exists before setting it and if it 
doesn't check some sort of rename map.

Or, can we know which classes are having properties set via MXML and swap out 
public vars for getter/setters?

HTH,
-Alex 

Re: Maven Distribution SDK fixed and working for IDEs

[Carlos Rovira]

Hi Piotr,

I had configured SDK in File -> Settings -> Default SDK
Then with your email I tried to configure in the project (that was
emptied). I need to reload Moonshine since it removed options to build.
After reload, I tried to compile but results are the same

Josh told me just now the ${royalelib} token should be populated
automatically.
don't need to configure anything in Moonshine.

Asked to check that the file exists in the Maven distribution:

frameworks/themes/JewelTheme/src/main/resources/defaults.css

I check and the file is there.

So don't see for now issues in Maven distribution. Hope you can track with
Moonshine team

Thanks





El jue., 26 mar. 2020 a las 19:26, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Carlos,
>
> One question to Moonshine. Where do you have configured your SDK. In menu
> File -> Settings -> Default SDK or in right click on the project Settings
> -> Build Options ?
>
> It shouldn't be any difference but I just wanted to know.
>
> Thanks,
> Piotr
>
> czw., 26 mar 2020 o 19:21 Christofer Dutz 
> napisał(a):
>
> > Hi all,
> >
> > well it's probably easy to fix if someone tells me what the difference
> is.
> >
> > Chris
> >
> >
> > Am 26.03.20, 19:15 schrieb "Piotr Zarzycki"  >:
> >
> > Hi Carlos,
> >
> > No you don't need to configure anything in Moonshine TDJ project, it
> > should
> > build with SDK right away - Remember I didn't try Maven SDK
> > distribution
> > with TDJ - I did try only with hello world, so your problem indicates
> > that
> > there is something which is missing.
> >
> > ${royalelib} -> This should be filled automatically by I'm not sure
> > Language server ? Maybe Josh can shed some light I don't remember who
> > filled that part, for sure not Moonshine itself. I do remember there
> > were
> > discussion about that variable on mailing list. :)
> >
> > Thanks,
> > Piotr
> >
> > czw., 26 mar 2020 o 19:09 Carlos Rovira 
> > napisał(a):
> >
> > > Hi Chris,
> > >
> > > not sure is a problem of the Maven sdk since the same is working in
> > VSCode
> > >
> > > The offending line is:
> > >
> > > The error is: command line Error: unable to open
> > > '/themes/JewelTheme/src/main/resources/defaults.css'.
> > >
> > > The config in Moonshine is in TourDejewel.as3proj has this:
> > >
> > >  > >
> > >
> >
> additional="-theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> > > -html-template=src/main/resources/jewel-example-index-template.html
> > > -js-dynamic-access-unknown-members=true"/>
> > >
> > > So don't know how ${royalelib} is worked in Moonshine. Maybe is
> > something I
> > > don't have configured yet in Moonshine
> > >
> > > @Piotr, could you let me know if is something that I need to
> > configure? can
> > > you try to compile TDJ with Moonshine and the maven distribution
> too?
> > >
> > > The full output for the record is:
> > >
> > >
> > > : Compiling TourDeJewel
> > > : Command:
> > > "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/bin/mxmlc"
> > > -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> > >
> -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> > > -html-template=src/main/resources/jewel-example-index-template.html
> > > -js-dynamic-access-unknown-members=true -debug=true -o
> > bin-debug/App.swf
> > > : SDK path: /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> > > : Sending to mxmlc: export
> > >
> >
> ROYALE_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven;export
> > > SETUP_SH_VMARGS="-Duser.language=en -Duser.region=en"; export
> > >
> > >
> >
> ROYALE_SWF_COMPILER_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven&&
> > >
> > "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/mxmlc"
> > > -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> > >
> -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> > > -html-template=src/main/resources/jewel-example-index-template.html
> > > -js-dynamic-access-unknown-members=true -debug=true -o
> > bin-debug/App.swf
> > > -compiler.targets=SWF
> > > : Using Royale Compiler codebase:
> > >
> /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/../..
> > > : Using Royale SDK:
> > /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> > > : MXMLJSC
> > > :
> > >
> > >
> >
> +royalelib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks
> > > :
> > >
> > >
> >
> -sdk-js-lib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks/js/Royale/generated-sources
> > > : -load-config+=obj/TourDeJewelConfig.xml
> > > : -optimize=false
> > > : -theme=/themes/JewelTheme/src/main/resources/defaults.css
> > > :
> 

Re: Releasing: Finally giving up

[Alex Harui]

@Yishay Weiss

Let's wait until the set of Maven steps are available from Chris and Carlos.  
Then I will try to find some cycles to help you.  Because of where I live, 
where the schools are closed, and my kids schedule, I have good weeks and bad 
weeks for having time for work, so it will be best to wait to try a release 
until we have the steps and it is one of my good weeks (next good week starts 
this Friday at 5pm my time).

Thanks,
-Alex

On 3/26/20, 5:13 AM, "Yishay Weiss"  wrote:

Hi All,

I too, feel very uncomfortable participating in these threads. While 
grateful to Carlos and Chris for their work I’m very annoyed with the tone of 
ultimatums and doom and gloom. Alex has put in a lot of work into this and I 
trust his concerns are technical, rather than protecting his ego as has been 
suggested. We need to get this discussion back on technical tracks.

Since Chris has given up, and it looks like Carlos has as well, I volunteer 
to start the release process from scratch next Sunday, which is after Israel 
has switched to day light saving. I will try to do the process incrementally 
and in parallel to my other tasks. If by the end of the week it turns out the 
process is too cumbersome and cannot realistically be made to work smoothly I 
will be in favor of changing the requirements to enable Chris’s mvn setup to be 
the main release tool.

Thanks,
Yishay

From: Piotr Zarzycki
Sent: Thursday, March 26, 2020 1:27 PM
To: Apache Royale Development
Subject: Re: Releasing: Finally giving up

Hi All,

I'm member of Apache Foundation for quite some time now. I think I have 
wrote maybe 2-3 emails during that time on members mailing list. - Why? - well 
I'm a person which doesn't like never ending stories, stories which are not end 
up with consensus nor action and I'm sorry but this is how it looks like in 
most cases there. Here we are in Apache Royale project where this thread ended 
up exactly the same - never ending story. - As PMC of this project I would like 
to say enough! :)

I had hope that when Carlos and Chris try CI steps and in the process they 
may have some issues, but they will end up in the same place as I ended up 
where I was able to prepare RC1 in about 2h without the problem. It turns out 
that they end up in the place where I have started, in the place where I have 
spend 5-6 days of work to finally reach stable point. They ended up frustrated 
in the same way as I was!

I really don't care now what kind of issue they have now, whether it's 
fixable or not - I just have enough of those never ending discussions where 
there is absolutely no results.

I met Chris in US in Miami and I have spend with him best time ever, he is 
really great developer - if he is saying that he will have release process in 
3-4 steps on my machine - I'm +1 make it so. Not tomorrow, not in a week - 
start today!

Please start whole work on that and make it happen. I will be the first who 
try the process and maybe with Chris's help we will solve also issue with 
uploading artifacts to staging area which we had.

Good Luck,
Piotr

czw., 26 mar 2020 o 12:02 
mailto:cont...@cristallium.com>> napisał(a):

Hi Guys,

I'm a lover of Flex dev guy since more than 10 years, been members of Flex 
group on Montpellier (France) at golden age of Flex and go at all conferences 
when Michaël Chaize came to Montpellier (and using Flex every day).

First of all I want to thank every one of you for your hard work, and 
congratulate you for the actual Apache Royale capabilities.
With the last features (especialy datagrid), today your great work make 
possible to use Apache Royale in business application. Of course, there are 
bugs, but when reported, it's quickly fix, this is great.

Now, this is a huge opportunity but also risk for all guys like me to adop 
Apache Royale for futur projects or use it instead of using Air when it's 
possible.
Personnaly, I first use it on my own Webs applications and perhaps for my 
customers on little applications for the begin. My big enormous worry is to use 
it and be alone in front of a SDK bug.
Seeing new release every 1 or 2 months should certainly reassure me. For 
now I see SDK 0.9.7 since a lot of time and this make me affraid and I don't 
understand why there is no 0.9.8.

I'm speaking as an Apache Royale SDK user : I'm very sad to read these 
debates on the subject of tools to use for making release. I don't care about 
tools nedeed or not to build the release SDK.
I would like use Apache Royale to build RAD (Rapid Application Dev) Web 
applications and see more and more SDK features added, and participate to 
project (like today) by reporting bug  by using my time on isolate the bug and 
make tests cases with screenshoots to save your time 

RE: Numbers not initialized to NaN

[Yishay Weiss]

My problem is that this code



  
  
  



Looks like this

[cid:image001.png@01D603AC.12544860]

It’s because the measured height for buttons 1 and 2 is different from button 
3. Moreover, button 3 changes its measured height in different phases of the 
layout due to its positioner.offsetHeight changing.

The weird thing is that positioner looks exactly the same [1], whether its 
offsetHeight is 19 or 34. Any ideas would be welcome.

[1]
3

From: Yishay Weiss
Sent: Thursday, March 26, 2020 7:50 PM
To: dev@royale.apache.org
Subject: RE: Numbers not initialized to NaN

Investigating. Unrelated to my subject line.


From: Alex Harui 
Sent: Thursday, March 26, 2020 7:49:42 PM
To: dev@royale.apache.org 
Subject: Re: Numbers not initialized to NaN

If I understood that correctly, that's what I would expect, so I don't know why 
it would matter if the value was undefined or initialized to NaN.  And thus, 
I'm not sure why the code went in the wrong direction.

On 3/26/20, 9:45 AM, "Yishay Weiss"  wrote:

isNaN(undefined) is actually true, same as isNaN(NaN).

From: Yishay Weiss
Sent: Thursday, March 26, 2020 6:27 PM
To: dev@royale.apache.org
Subject: RE: Numbers not initialized to NaN

Ok, I’ll investigate why it’s undefined.

> isNaN(percentHeight) is thus evaluated

I meant !isNaN

Thanks.


From: Josh Tynjala
Sent: Thursday, March 26, 2020 6:23 PM
To: Apache Royale Development
Subject: Re: Numbers not initialized to NaN

Numbers should be initialized to NaN, unless you've added
-js-default-initializers=false to your compiler options.

--
Josh Tynjala
Bowler Hat LLC 



On Thu, Mar 26, 2020 at 9:17 AM Yishay Weiss  wrote:

> I think this might have come up in one of my previous posts so my
> apologies if I’m repeating a question. In Flex.as we have the following
> code:
>
> if (!isNaN(percentHeight)
> && child.includeInLayout)
> {
> height =
> Math.max(child.minHeight,
>
>   Math.min(child.maxHeight,
>
>   ((percentHeight >= 100) ? h : h * percentHeight / 100)));
> }
>
> percentHeight, which is a Number, seems to be initialized to undefined.
> isNaN(percentHeight) is thus evaluated to true which results in the wrong
> height being set.
>
> Should I change the code to check for undefined instead of NaN, or should
> the compiler initialized to NaN?
>

Re: Maven Distribution SDK fixed and working for IDEs

[Piotr Zarzycki]

Carlos,

One question to Moonshine. Where do you have configured your SDK. In menu
File -> Settings -> Default SDK or in right click on the project Settings
-> Build Options ?

It shouldn't be any difference but I just wanted to know.

Thanks,
Piotr

czw., 26 mar 2020 o 19:21 Christofer Dutz 
napisał(a):

> Hi all,
>
> well it's probably easy to fix if someone tells me what the difference is.
>
> Chris
>
>
> Am 26.03.20, 19:15 schrieb "Piotr Zarzycki" :
>
> Hi Carlos,
>
> No you don't need to configure anything in Moonshine TDJ project, it
> should
> build with SDK right away - Remember I didn't try Maven SDK
> distribution
> with TDJ - I did try only with hello world, so your problem indicates
> that
> there is something which is missing.
>
> ${royalelib} -> This should be filled automatically by I'm not sure
> Language server ? Maybe Josh can shed some light I don't remember who
> filled that part, for sure not Moonshine itself. I do remember there
> were
> discussion about that variable on mailing list. :)
>
> Thanks,
> Piotr
>
> czw., 26 mar 2020 o 19:09 Carlos Rovira 
> napisał(a):
>
> > Hi Chris,
> >
> > not sure is a problem of the Maven sdk since the same is working in
> VSCode
> >
> > The offending line is:
> >
> > The error is: command line Error: unable to open
> > '/themes/JewelTheme/src/main/resources/defaults.css'.
> >
> > The config in Moonshine is in TourDejewel.as3proj has this:
> >
> >  >
> >
> additional="-theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> > -html-template=src/main/resources/jewel-example-index-template.html
> > -js-dynamic-access-unknown-members=true"/>
> >
> > So don't know how ${royalelib} is worked in Moonshine. Maybe is
> something I
> > don't have configured yet in Moonshine
> >
> > @Piotr, could you let me know if is something that I need to
> configure? can
> > you try to compile TDJ with Moonshine and the maven distribution too?
> >
> > The full output for the record is:
> >
> >
> > : Compiling TourDeJewel
> > : Command:
> > "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/bin/mxmlc"
> > -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> > -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> > -html-template=src/main/resources/jewel-example-index-template.html
> > -js-dynamic-access-unknown-members=true -debug=true -o
> bin-debug/App.swf
> > : SDK path: /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> > : Sending to mxmlc: export
> >
> ROYALE_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven;export
> > SETUP_SH_VMARGS="-Duser.language=en -Duser.region=en"; export
> >
> >
> ROYALE_SWF_COMPILER_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven&&
> >
> "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/mxmlc"
> > -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> > -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> > -html-template=src/main/resources/jewel-example-index-template.html
> > -js-dynamic-access-unknown-members=true -debug=true -o
> bin-debug/App.swf
> > -compiler.targets=SWF
> > : Using Royale Compiler codebase:
> > /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/../..
> > : Using Royale SDK:
> /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> > : MXMLJSC
> > :
> >
> >
> +royalelib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks
> > :
> >
> >
> -sdk-js-lib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks/js/Royale/generated-sources
> > : -load-config+=obj/TourDeJewelConfig.xml
> > : -optimize=false
> > : -theme=/themes/JewelTheme/src/main/resources/defaults.css
> > : -html-template=src/main/resources/jewel-example-index-template.html
> > : -js-dynamic-access-unknown-members=true
> > : -debug=true
> > : -o
> > : bin-debug/App.swf
> > : -compiler.targets=SWF
> > : command line Error: unable to open
> > '/themes/JewelTheme/src/main/resources/defaults.css'.
> > : 0.676110556 seconds
> > : Compilation of TourDeJewel finished.
> >
> >
> > El jue., 26 mar. 2020 a las 18:20, Christofer Dutz (<
> > christofer.d...@c-ware.de>) escribió:
> >
> > > Hi all,
> > >
> > > Good to know it's now working.
> > >
> > > So what is still the difference between the Maven and the Ant
> > distribution?
> > >
> > > I'm asking cause I would love to make the maven distribution match
> the
> > Ant
> > > version and just use the one Maven created in the future.
> > >
> > > Chris
> > >
> > >
> > > Am 26.03.20, 17:58 schrieb "Carlos Rovira" <
> carlosrov...@apache.org>:
> > >
> > > Hi Piotr,
> 

Re: Maven Distribution SDK fixed and working for IDEs

[Carlos Rovira]

Ok,
hope Josh could let us know what could be missing and why VSCode is able to
get it. Probably will be more efficient than try to see ourselves.
Thanks!

El jue., 26 mar. 2020 a las 19:15, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Hi Carlos,
>
> No you don't need to configure anything in Moonshine TDJ project, it should
> build with SDK right away - Remember I didn't try Maven SDK distribution
> with TDJ - I did try only with hello world, so your problem indicates that
> there is something which is missing.
>
> ${royalelib} -> This should be filled automatically by I'm not sure
> Language server ? Maybe Josh can shed some light I don't remember who
> filled that part, for sure not Moonshine itself. I do remember there were
> discussion about that variable on mailing list. :)
>
> Thanks,
> Piotr
>
> czw., 26 mar 2020 o 19:09 Carlos Rovira 
> napisał(a):
>
> > Hi Chris,
> >
> > not sure is a problem of the Maven sdk since the same is working in
> VSCode
> >
> > The offending line is:
> >
> > The error is: command line Error: unable to open
> > '/themes/JewelTheme/src/main/resources/defaults.css'.
> >
> > The config in Moonshine is in TourDejewel.as3proj has this:
> >
> >  >
> >
> additional="-theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> > -html-template=src/main/resources/jewel-example-index-template.html
> > -js-dynamic-access-unknown-members=true"/>
> >
> > So don't know how ${royalelib} is worked in Moonshine. Maybe is
> something I
> > don't have configured yet in Moonshine
> >
> > @Piotr, could you let me know if is something that I need to configure?
> can
> > you try to compile TDJ with Moonshine and the maven distribution too?
> >
> > The full output for the record is:
> >
> >
> > : Compiling TourDeJewel
> > : Command:
> > "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/bin/mxmlc"
> > -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> > -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> > -html-template=src/main/resources/jewel-example-index-template.html
> > -js-dynamic-access-unknown-members=true -debug=true -o bin-debug/App.swf
> > : SDK path: /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> > : Sending to mxmlc: export
> >
> ROYALE_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven;export
> > SETUP_SH_VMARGS="-Duser.language=en -Duser.region=en"; export
> >
> >
> ROYALE_SWF_COMPILER_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven&&
> > "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/mxmlc"
> > -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> > -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> > -html-template=src/main/resources/jewel-example-index-template.html
> > -js-dynamic-access-unknown-members=true -debug=true -o bin-debug/App.swf
> > -compiler.targets=SWF
> > : Using Royale Compiler codebase:
> > /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/../..
> > : Using Royale SDK:
> /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> > : MXMLJSC
> > :
> >
> >
> +royalelib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks
> > :
> >
> >
> -sdk-js-lib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks/js/Royale/generated-sources
> > : -load-config+=obj/TourDeJewelConfig.xml
> > : -optimize=false
> > : -theme=/themes/JewelTheme/src/main/resources/defaults.css
> > : -html-template=src/main/resources/jewel-example-index-template.html
> > : -js-dynamic-access-unknown-members=true
> > : -debug=true
> > : -o
> > : bin-debug/App.swf
> > : -compiler.targets=SWF
> > : command line Error: unable to open
> > '/themes/JewelTheme/src/main/resources/defaults.css'.
> > : 0.676110556 seconds
> > : Compilation of TourDeJewel finished.
> >
> >
> > El jue., 26 mar. 2020 a las 18:20, Christofer Dutz (<
> > christofer.d...@c-ware.de>) escribió:
> >
> > > Hi all,
> > >
> > > Good to know it's now working.
> > >
> > > So what is still the difference between the Maven and the Ant
> > distribution?
> > >
> > > I'm asking cause I would love to make the maven distribution match the
> > Ant
> > > version and just use the one Maven created in the future.
> > >
> > > Chris
> > >
> > >
> > > Am 26.03.20, 17:58 schrieb "Carlos Rovira" :
> > >
> > > Hi Piotr,
> > >
> > > just downloaded latest nightly and could finally compile the TDJ.
> > > Is failing due to some config issue, but that's an issue to solve
> in
> > > TDJ
> > > config
> > > Congrats y think I can at last use Moonshine and explore it! :)
> > >
> > >
> > >
> > > El jue., 26 mar. 2020 a las 12:44, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>) escribió:
> > >
> > > > Hi Carlos,
> > > >
> > > > Colleague from the Team was able to reproduce your problem with
> > > "Build
> > > > Project". It looks like he fixed that - you can download Nightly
> > > Build of
> > > > Moonshine and check.
> > > >
> > > 

Re: Maven Distribution SDK fixed and working for IDEs

[Christofer Dutz]

Hi all,

well it's probably easy to fix if someone tells me what the difference is.

Chris


Am 26.03.20, 19:15 schrieb "Piotr Zarzycki" :

Hi Carlos,

No you don't need to configure anything in Moonshine TDJ project, it should
build with SDK right away - Remember I didn't try Maven SDK distribution
with TDJ - I did try only with hello world, so your problem indicates that
there is something which is missing.

${royalelib} -> This should be filled automatically by I'm not sure
Language server ? Maybe Josh can shed some light I don't remember who
filled that part, for sure not Moonshine itself. I do remember there were
discussion about that variable on mailing list. :)

Thanks,
Piotr

czw., 26 mar 2020 o 19:09 Carlos Rovira 
napisał(a):

> Hi Chris,
>
> not sure is a problem of the Maven sdk since the same is working in VSCode
>
> The offending line is:
>
> The error is: command line Error: unable to open
> '/themes/JewelTheme/src/main/resources/defaults.css'.
>
> The config in Moonshine is in TourDejewel.as3proj has this:
>
> 
> 
additional="-theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> -html-template=src/main/resources/jewel-example-index-template.html
> -js-dynamic-access-unknown-members=true"/>
>
> So don't know how ${royalelib} is worked in Moonshine. Maybe is something 
I
> don't have configured yet in Moonshine
>
> @Piotr, could you let me know if is something that I need to configure? 
can
> you try to compile TDJ with Moonshine and the maven distribution too?
>
> The full output for the record is:
>
>
> : Compiling TourDeJewel
> : Command:
> "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/bin/mxmlc"
> -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> -html-template=src/main/resources/jewel-example-index-template.html
> -js-dynamic-access-unknown-members=true -debug=true -o bin-debug/App.swf
> : SDK path: /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> : Sending to mxmlc: export
> ROYALE_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven;export
> SETUP_SH_VMARGS="-Duser.language=en -Duser.region=en"; export
>
> 
ROYALE_SWF_COMPILER_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven&&
> "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/mxmlc"
> -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> -html-template=src/main/resources/jewel-example-index-template.html
> -js-dynamic-access-unknown-members=true -debug=true -o bin-debug/App.swf
> -compiler.targets=SWF
> : Using Royale Compiler codebase:
> /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/../..
> : Using Royale SDK: 
/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> : MXMLJSC
> :
>
> 
+royalelib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks
> :
>
> 
-sdk-js-lib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks/js/Royale/generated-sources
> : -load-config+=obj/TourDeJewelConfig.xml
> : -optimize=false
> : -theme=/themes/JewelTheme/src/main/resources/defaults.css
> : -html-template=src/main/resources/jewel-example-index-template.html
> : -js-dynamic-access-unknown-members=true
> : -debug=true
> : -o
> : bin-debug/App.swf
> : -compiler.targets=SWF
> : command line Error: unable to open
> '/themes/JewelTheme/src/main/resources/defaults.css'.
> : 0.676110556 seconds
> : Compilation of TourDeJewel finished.
>
>
> El jue., 26 mar. 2020 a las 18:20, Christofer Dutz (<
> christofer.d...@c-ware.de>) escribió:
>
> > Hi all,
> >
> > Good to know it's now working.
> >
> > So what is still the difference between the Maven and the Ant
> distribution?
> >
> > I'm asking cause I would love to make the maven distribution match the
> Ant
> > version and just use the one Maven created in the future.
> >
> > Chris
> >
> >
> > Am 26.03.20, 17:58 schrieb "Carlos Rovira" :
> >
> > Hi Piotr,
> >
> > just downloaded latest nightly and could finally compile the TDJ.
> > Is failing due to some config issue, but that's an issue to solve in
> > TDJ
> > config
> > Congrats y think I can at last use Moonshine and explore it! :)
> >
> >
> >
> > El jue., 26 mar. 2020 a las 12:44, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > Hi Carlos,
> > >
> > > Colleague from the Team was able to reproduce your problem with
> > "Build
> > > 

Re: Maven Distribution SDK fixed and working for IDEs

[Piotr Zarzycki]

Hi Carlos,

No you don't need to configure anything in Moonshine TDJ project, it should
build with SDK right away - Remember I didn't try Maven SDK distribution
with TDJ - I did try only with hello world, so your problem indicates that
there is something which is missing.

${royalelib} -> This should be filled automatically by I'm not sure
Language server ? Maybe Josh can shed some light I don't remember who
filled that part, for sure not Moonshine itself. I do remember there were
discussion about that variable on mailing list. :)

Thanks,
Piotr

czw., 26 mar 2020 o 19:09 Carlos Rovira 
napisał(a):

> Hi Chris,
>
> not sure is a problem of the Maven sdk since the same is working in VSCode
>
> The offending line is:
>
> The error is: command line Error: unable to open
> '/themes/JewelTheme/src/main/resources/defaults.css'.
>
> The config in Moonshine is in TourDejewel.as3proj has this:
>
> 
> additional="-theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> -html-template=src/main/resources/jewel-example-index-template.html
> -js-dynamic-access-unknown-members=true"/>
>
> So don't know how ${royalelib} is worked in Moonshine. Maybe is something I
> don't have configured yet in Moonshine
>
> @Piotr, could you let me know if is something that I need to configure? can
> you try to compile TDJ with Moonshine and the maven distribution too?
>
> The full output for the record is:
>
>
> : Compiling TourDeJewel
> : Command:
> "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/bin/mxmlc"
> -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> -html-template=src/main/resources/jewel-example-index-template.html
> -js-dynamic-access-unknown-members=true -debug=true -o bin-debug/App.swf
> : SDK path: /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> : Sending to mxmlc: export
> ROYALE_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven;export
> SETUP_SH_VMARGS="-Duser.language=en -Duser.region=en"; export
>
> ROYALE_SWF_COMPILER_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven&&
> "/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/mxmlc"
> -load-config+=obj/TourDeJewelConfig.xml -optimize=false
> -theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
> -html-template=src/main/resources/jewel-example-index-template.html
> -js-dynamic-access-unknown-members=true -debug=true -o bin-debug/App.swf
> -compiler.targets=SWF
> : Using Royale Compiler codebase:
> /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/../..
> : Using Royale SDK: /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
> : MXMLJSC
> :
>
> +royalelib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks
> :
>
> -sdk-js-lib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks/js/Royale/generated-sources
> : -load-config+=obj/TourDeJewelConfig.xml
> : -optimize=false
> : -theme=/themes/JewelTheme/src/main/resources/defaults.css
> : -html-template=src/main/resources/jewel-example-index-template.html
> : -js-dynamic-access-unknown-members=true
> : -debug=true
> : -o
> : bin-debug/App.swf
> : -compiler.targets=SWF
> : command line Error: unable to open
> '/themes/JewelTheme/src/main/resources/defaults.css'.
> : 0.676110556 seconds
> : Compilation of TourDeJewel finished.
>
>
> El jue., 26 mar. 2020 a las 18:20, Christofer Dutz (<
> christofer.d...@c-ware.de>) escribió:
>
> > Hi all,
> >
> > Good to know it's now working.
> >
> > So what is still the difference between the Maven and the Ant
> distribution?
> >
> > I'm asking cause I would love to make the maven distribution match the
> Ant
> > version and just use the one Maven created in the future.
> >
> > Chris
> >
> >
> > Am 26.03.20, 17:58 schrieb "Carlos Rovira" :
> >
> > Hi Piotr,
> >
> > just downloaded latest nightly and could finally compile the TDJ.
> > Is failing due to some config issue, but that's an issue to solve in
> > TDJ
> > config
> > Congrats y think I can at last use Moonshine and explore it! :)
> >
> >
> >
> > El jue., 26 mar. 2020 a las 12:44, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > Hi Carlos,
> > >
> > > Colleague from the Team was able to reproduce your problem with
> > "Build
> > > Project". It looks like he fixed that - you can download Nightly
> > Build of
> > > Moonshine and check.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > pon., 23 mar 2020 o 15:10 Carlos Rovira 
> > > napisał(a):
> > >
> > > > Yeah, hope someone on your team could know where we can start
> > looking :)
> > > > thanks!
> > > > Carlos
> > > >
> > > > El lun., 23 mar. 2020 a las 15:04, Piotr Zarzycki (<
> > > > piotrzarzyck...@gmail.com>) escribió:
> > > >
> > > > > Next is reproduce your problem with Moonshine. ;)
> > > > >
> > > > > pon., 23 mar 2020 o 15:02 Carlos Rovira <

Re: Control over export/rename: Finally giving up

[Josh Tynjala]

> I would like to know what got rolled back.  IOW, what is the status now?
Is the compiler back to where it was maybe two years ago where we warn on
public vars, but the output is not made more verbose?  Or what?

I'm not sure what "two years ago" refers to exactly. All of the commits
that I rolled back were from this year, 2020.

But to answer what I rolled back, yes, it will warn on public vars again,
and the names of properties in the MXML descriptor are back to simple
strings. No more use of goog.reflect.objectProperty() because I realized
that it would only work in some situations.

I'm currently looking into a way to include a function with the MXML
descriptor that can be used to set the property, even if it has been
renamed. An evolution of what I proposed a couple of months ago. However, I
plan to keep both the string name and the value inside the descriptor so
that it does not affect your debugging approach.

A single property in the MXML descriptor looks like this now:

[
"someProperty",
true,
123.4
]

It might look something like this after my change:

[
"someProperty",
function(value) { this.someProperty = value; },
true,
123.4
]

If the function exists, it will be called like this (where host is the
component/object being created):

var func = descriptor[i];
func.call(host, value);

This will ensure that someProperty can be renamed, and all of the original
data is preserved for debugging.

I should be able to make the compiler smart enough to only include the
function where necessary (public vars) and omit it when not necessary
(public setters) to save on file size and make it PAYG. I would, of course,
also add a compiler option to include no functions in the descriptor (in
other words, keep the existing behavior).

> Also note that module support currently allows renaming, although Josh's
original post got me wondering if I missed something along the way.  Google
Closure was taking a rename map and seemed to be using it.

I mentioned this in my original post. Closure's ability to use these rename
maps is intended specifically for compiling multiple projects together,
exactly how we are using it for modules. There are comments in the code
that explicitly say that the rename map should not be used as a way to
prevent things from being renamed, and that the rename maps are considered
by Closure to be suggestions only, and they may be ignored in some cases.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 10:47 AM Alex Harui 
wrote:

> I'm also sorry to hear.  I did not pay much attention to this effort,
> other than complaining that we should not make our debug output hard to
> work with in order to support such an effort, because it really did make
> the kind of debugging I do much more painful.
>
> I would like to know what got rolled back.  IOW, what is the status now?
> Is the compiler back to where it was maybe two years ago where we warn on
> public vars, but the output is not made more verbose?  Or what?
>
> We might be able to enumerate where the framework relies on dynamic
> access, but it will be much harder, without control-flow analysis, to know
> where the application code relies on dynamic access.
>
> Without thinking about it too much, I would think we can define some
> scenarios, represent those scenarios as compiler options, and make more
> people happy.  But it could be a lot of work and I don't have the cycles
> for it.
>
> Some examples of a scenarios that could be output options:
> 1) I am not using binding or any other dynamic access in my app.  Remove
> all exports and I'll debug the resuls and add directives to fix the few
> things that need fixing
> 2) I am not using modules, so don't worry about any other compilation
> accessing my APIs
> 3) I am using modules, and here are the classes that are referenced by the
> modules
>
> There is also another dimension of ways to prevent renaming:
> A) Please convert all public vars to getter/setter
> B) Please convert all public var access to dynamic access
> C) Please inject anti-renaming stubs for all dynamic access
>
> Also note that module support currently allows renaming, although Josh's
> original post got me wondering if I missed something along the way.  Google
> Closure was taking a rename map and seemed to be using it.
>
> HTH,
> -Alex
>
> On 3/26/20, 1:23 AM, "Harbs"  wrote:
>
> Sorry to hear. :-(
>
> I still wonder if maybe we can document all the cases where we’re
> relying on not renaming and find a way to deal with those cases. (for
> someone who wants to disable exports)
>
> I know Greg has done a significant amount of digging related to his
> reflection work. Alex, do you have any thoughts?
>
> Harbs
>
> > On Mar 25, 2020, at 9:06 PM, Josh Tynjala 
> wrote:
> >
> > (With credit to Chris for the subject name )
> >
> > Some of you may know that over the last 2-3 months I've been looking
> into
> > ways to add more control over how the 

Re: Maven Distribution SDK fixed and working for IDEs

[Carlos Rovira]

Hi Chris,

not sure is a problem of the Maven sdk since the same is working in VSCode

The offending line is:

The error is: command line Error: unable to open
'/themes/JewelTheme/src/main/resources/defaults.css'.

The config in Moonshine is in TourDejewel.as3proj has this:



So don't know how ${royalelib} is worked in Moonshine. Maybe is something I
don't have configured yet in Moonshine

@Piotr, could you let me know if is something that I need to configure? can
you try to compile TDJ with Moonshine and the maven distribution too?

The full output for the record is:


: Compiling TourDeJewel
: Command:
"/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/bin/mxmlc"
-load-config+=obj/TourDeJewelConfig.xml -optimize=false
-theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
-html-template=src/main/resources/jewel-example-index-template.html
-js-dynamic-access-unknown-members=true -debug=true -o bin-debug/App.swf
: SDK path: /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
: Sending to mxmlc: export
ROYALE_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven;export
SETUP_SH_VMARGS="-Duser.language=en -Duser.region=en"; export
ROYALE_SWF_COMPILER_HOME=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven&&
"/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/mxmlc"
-load-config+=obj/TourDeJewelConfig.xml -optimize=false
-theme=${royalelib}/themes/JewelTheme/src/main/resources/defaults.css
-html-template=src/main/resources/jewel-example-index-template.html
-js-dynamic-access-unknown-members=true -debug=true -o bin-debug/App.swf
-compiler.targets=SWF
: Using Royale Compiler codebase:
/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/js/bin/../..
: Using Royale SDK: /Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven
: MXMLJSC
:
+royalelib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks
:
-sdk-js-lib=/Users/carlosrovira/Dev/Royale/Sdks/apache-royale-maven/frameworks/js/Royale/generated-sources
: -load-config+=obj/TourDeJewelConfig.xml
: -optimize=false
: -theme=/themes/JewelTheme/src/main/resources/defaults.css
: -html-template=src/main/resources/jewel-example-index-template.html
: -js-dynamic-access-unknown-members=true
: -debug=true
: -o
: bin-debug/App.swf
: -compiler.targets=SWF
: command line Error: unable to open
'/themes/JewelTheme/src/main/resources/defaults.css'.
: 0.676110556 seconds
: Compilation of TourDeJewel finished.


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

> Hi all,
>
> Good to know it's now working.
>
> So what is still the difference between the Maven and the Ant distribution?
>
> I'm asking cause I would love to make the maven distribution match the Ant
> version and just use the one Maven created in the future.
>
> Chris
>
>
> Am 26.03.20, 17:58 schrieb "Carlos Rovira" :
>
> Hi Piotr,
>
> just downloaded latest nightly and could finally compile the TDJ.
> Is failing due to some config issue, but that's an issue to solve in
> TDJ
> config
> Congrats y think I can at last use Moonshine and explore it! :)
>
>
>
> El jue., 26 mar. 2020 a las 12:44, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Hi Carlos,
> >
> > Colleague from the Team was able to reproduce your problem with
> "Build
> > Project". It looks like he fixed that - you can download Nightly
> Build of
> > Moonshine and check.
> >
> > Thanks,
> > Piotr
> >
> > pon., 23 mar 2020 o 15:10 Carlos Rovira 
> > napisał(a):
> >
> > > Yeah, hope someone on your team could know where we can start
> looking :)
> > > thanks!
> > > Carlos
> > >
> > > El lun., 23 mar. 2020 a las 15:04, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>) escribió:
> > >
> > > > Next is reproduce your problem with Moonshine. ;)
> > > >
> > > > pon., 23 mar 2020 o 15:02 Carlos Rovira  >
> > > > napisał(a):
> > > >
> > > > > Very cool Piotr!
> > > > > seems we finally has Maven distribution sdk working! :)
> > > > >
> > > > > El lun., 23 mar. 2020 a las 14:44, Piotr Zarzycki (<
> > > > > piotrzarzyck...@gmail.com>) escribió:
> > > > >
> > > > > > Hi Guys,
> > > > > >
> > > > > > I just checked Maven Distribution with Moonshine and I was
> able to
> > > > build
> > > > > > Jewel Hello World and TourDeJewel. :)
> > > > > >
> > > > > > Thanks,
> > > > > > Piotr
> > > > > >
> > > > > > niedz., 22 mar 2020 o 20:58 Carlos Rovira <
> carlosrov...@apache.org
> > >
> > > > > > napisał(a):
> > > > > >
> > > > > > > Hi Piotr,
> > > > > > >
> > > > > > > nothing happens or log is printed in the console, is like
> if I
> > > didn't
> > > > > > push
> > > > > > > the menu button.
> > > > > > > I ensured that I have the SDK setup, maybe something more
> is
> > > needed,
> > > > > and
> > > > > > > 

Re: Releasing: Finally giving up

[Alex Harui]

Chris and Carlos, please actually produce a wiki page with the list of Maven 
commands.  I'm sorry, but don't think it will be as amazingly simple as you 
stated.  So do it!  Maybe Chris first to document the steps in a wiki page, 
then Carlos next to prove that Chris didn't miss anything in the documentation. 
 Also, please make sure that the parameters used to produce the artifacts 
includes the plugins and options for creating a reproducible binary.  Don't 
worry about if it actually matches anything right now.  I think I've explained 
why that is on another thread.

Like I said, the test is that the staging repo will have the same set of files 
as the 0.9.6 release (other than any new SWCs and with a different version 
number.

I think there will be more commands than just release:prepare and 
release:perform, calling set-property on things.  It is a lot of typing for the 
RM, prone to typing errors, which is why it was automated in Ant scripts and CI 
steps.

I would actually love to be wrong about this, because then I think we could 
reduce the set of CI steps to match as well.  As I've written many times, most 
of the CI steps just do the minimum Maven commands to build the release 
artifacts using the Maven poms we had in the past.

So go for it, and let us know when the final list of Maven commands is ready.

Don't worry about the Ant artifacts either for now.  Just get the Maven staging 
repo ready.  The Ant steps already know how to pull the Maven source artifact 
from staging and build the Ant artifacts.  I'm still unclear why it will ever 
make sense to drive that portion from Maven.  I have yet to see a technical 
explanation of how we can validate that Ant can use the build.xml files to 
create the Ant artifacts without actually running Ant, but that can wait until 
after we get the set of Maven commands for the Maven artifacts first.

Thanks,
-Alex

On 3/26/20, 1:26 AM, "Carlos Rovira"  wrote:

Hi,

that's amazingly simple, so I think we should go that way without doubt. I
think reached this point there's a clear sense of that we need to go that
route.

We tried our best to stick with the previous process and we're all
loosing lots of time. Then currently seems no more people in the community
was interested in this thread, event to comment a single line (here or in
the other users list thread), what means that or there's no more people
like us in this project or people really is not interested and just want us
to release and go forward.

As previously I think most of the PMCs here (Om, Josh, Greg and me for
sure), probably Yishay for his concise comments are more for this.
My thinking is that the right now I think only 2 PMCs are for CI Server,
and other one that is uncertainly but didn't try the CI Server.

I think all can live together while is not a must for the rest that don't
want it the others option, so what's about if we release with the
super-simple steps Chris proposal, and others wanting to use CI do that
when is their RM turn ? (of course maintaining it and making it work for
his release without requiring nothing for the rest that doesn't want it).

Release as other projects do is recommended but not required, the same as
the actual CI server (but this one should be less recommended since is a
royale-only practice not seen in any other place).

What's the important thing is to release, do it, and do it easily and often.

Thanks



El jue., 26 mar. 2020 a las 8:24, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Ok,
>
> I'll write this a last time as I do feel like we're going in circles and
> will from now on not participate in any discussion involving releasing on 
a
> CI server.
>
> A correct Maven release would use (There will be some additional profiles
> to activate to include all modules)
>
> 1) the "mvn release:branch" call in order to create the branch and bump
> the version of develop to the next version.
> 2) the "mvn release:prepare" to change the pom to the release version, set
> the timestamp in the pom (for reproducible builds) build ... if all tests
> are good, commit the changes, tag this commit, update the poms to the next
> development version, commit those changes and push everything.
> 3) the "mvn release:perform" which will checkout the tagged version build
> everything with the "apache-release" profile turned on (Which causes the
> source.jars, Javadoc.jars, hashes and gpg singatures to be created as well
> as the assembly) This also deploys the built artifacts to Nexus.
>
> Most of that you are already doing on the CI server however you're not
> letting it do all automatically (For lack of credentials)
>
> But ... if you would just be doing those steps on the RM machine.
>
> Chris
>
>
   

RE: Numbers not initialized to NaN

[Yishay Weiss]

Investigating. Unrelated to my subject line.


From: Alex Harui 
Sent: Thursday, March 26, 2020 7:49:42 PM
To: dev@royale.apache.org 
Subject: Re: Numbers not initialized to NaN

If I understood that correctly, that's what I would expect, so I don't know why 
it would matter if the value was undefined or initialized to NaN.  And thus, 
I'm not sure why the code went in the wrong direction.

On 3/26/20, 9:45 AM, "Yishay Weiss"  wrote:

isNaN(undefined) is actually true, same as isNaN(NaN).

From: Yishay Weiss
Sent: Thursday, March 26, 2020 6:27 PM
To: dev@royale.apache.org
Subject: RE: Numbers not initialized to NaN

Ok, I’ll investigate why it’s undefined.

> isNaN(percentHeight) is thus evaluated

I meant !isNaN

Thanks.


From: Josh Tynjala
Sent: Thursday, March 26, 2020 6:23 PM
To: Apache Royale Development
Subject: Re: Numbers not initialized to NaN

Numbers should be initialized to NaN, unless you've added
-js-default-initializers=false to your compiler options.

--
Josh Tynjala
Bowler Hat LLC 



On Thu, Mar 26, 2020 at 9:17 AM Yishay Weiss  wrote:

> I think this might have come up in one of my previous posts so my
> apologies if I’m repeating a question. In Flex.as we have the following
> code:
>
> if (!isNaN(percentHeight)
> && child.includeInLayout)
> {
> height =
> Math.max(child.minHeight,
>
>   Math.min(child.maxHeight,
>
>   ((percentHeight >= 100) ? h : h * percentHeight / 100)));
> }
>
> percentHeight, which is a Number, seems to be initialized to undefined.
> isNaN(percentHeight) is thus evaluated to true which results in the wrong
> height being set.
>
> Should I change the code to check for undefined instead of NaN, or should
> the compiler initialized to NaN?
>

Re: Numbers not initialized to NaN

[Alex Harui]

If I understood that correctly, that's what I would expect, so I don't know why 
it would matter if the value was undefined or initialized to NaN.  And thus, 
I'm not sure why the code went in the wrong direction.

On 3/26/20, 9:45 AM, "Yishay Weiss"  wrote:

isNaN(undefined) is actually true, same as isNaN(NaN).

From: Yishay Weiss
Sent: Thursday, March 26, 2020 6:27 PM
To: dev@royale.apache.org
Subject: RE: Numbers not initialized to NaN

Ok, I’ll investigate why it’s undefined.

> isNaN(percentHeight) is thus evaluated

I meant !isNaN

Thanks.


From: Josh Tynjala
Sent: Thursday, March 26, 2020 6:23 PM
To: Apache Royale Development
Subject: Re: Numbers not initialized to NaN

Numbers should be initialized to NaN, unless you've added
-js-default-initializers=false to your compiler options.

--
Josh Tynjala
Bowler Hat LLC 



On Thu, Mar 26, 2020 at 9:17 AM Yishay Weiss  wrote:

> I think this might have come up in one of my previous posts so my
> apologies if I’m repeating a question. In Flex.as we have the following
> code:
>
> if (!isNaN(percentHeight)
> && child.includeInLayout)
> {
> height =
> Math.max(child.minHeight,
>
>   Math.min(child.maxHeight,
>
>   ((percentHeight >= 100) ? h : h * percentHeight / 100)));
> }
>
> percentHeight, which is a Number, seems to be initialized to undefined.
> isNaN(percentHeight) is thus evaluated to true which results in the wrong
> height being set.
>
> Should I change the code to check for undefined instead of NaN, or should
> the compiler initialized to NaN?
>

Re: Control over export/rename: Finally giving up

[Alex Harui]

I'm also sorry to hear.  I did not pay much attention to this effort, other 
than complaining that we should not make our debug output hard to work with in 
order to support such an effort, because it really did make the kind of 
debugging I do much more painful.

I would like to know what got rolled back.  IOW, what is the status now?  Is 
the compiler back to where it was maybe two years ago where we warn on public 
vars, but the output is not made more verbose?  Or what?

We might be able to enumerate where the framework relies on dynamic access, but 
it will be much harder, without control-flow analysis, to know where the 
application code relies on dynamic access.

Without thinking about it too much, I would think we can define some scenarios, 
represent those scenarios as compiler options, and make more people happy.  But 
it could be a lot of work and I don't have the cycles for it.

Some examples of a scenarios that could be output options:
1) I am not using binding or any other dynamic access in my app.  Remove all 
exports and I'll debug the resuls and add directives to fix the few things that 
need fixing
2) I am not using modules, so don't worry about any other compilation accessing 
my APIs
3) I am using modules, and here are the classes that are referenced by the 
modules

There is also another dimension of ways to prevent renaming:
A) Please convert all public vars to getter/setter
B) Please convert all public var access to dynamic access
C) Please inject anti-renaming stubs for all dynamic access

Also note that module support currently allows renaming, although Josh's 
original post got me wondering if I missed something along the way.  Google 
Closure was taking a rename map and seemed to be using it.

HTH,
-Alex

On 3/26/20, 1:23 AM, "Harbs"  wrote:

Sorry to hear. :-(

I still wonder if maybe we can document all the cases where we’re relying 
on not renaming and find a way to deal with those cases. (for someone who wants 
to disable exports)

I know Greg has done a significant amount of digging related to his 
reflection work. Alex, do you have any thoughts?

Harbs

> On Mar 25, 2020, at 9:06 PM, Josh Tynjala  
wrote:
> 
> (With credit to Chris for the subject name )
> 
> Some of you may know that over the last 2-3 months I've been looking into
> ways to add more control over how the compiler handles renaming and
> exporting APIs in the generated JS. Ideally, my work would have culminated
> in a variety of options that would allow release builds to be much 
smaller,
> if you were willing to sacrifice certain capabilities (things along the
> lines of dynamic access of properties and reflection). Obviously, you 
would
> have been able to keep things working the same as they do today, so my
> changes would have been opt-in.
> 
> I've determined that Closure does not actually expose the ability to
> prevent renaming of JS APIs, except by exporting them. The advanced
> compiler APIs that Closure exposes to prevent renaming are specifically
> intended for compiling multiple related projects together (like we're 
doing
> with modules). Additionally, I discovered that Closure does not guarantee
> that any custom rename mappings will be respected. In fact, the
> documentation says they may be completely ignored, and there is official
> guidance that says not to do what I was originally trying to do. I could
> not find any other Closure compiler APIs accessible in Java that could do
> what we want here, so I think that our original assumption that preventing
> renaming programmatically would be possible was incorrect.
> 
> In the case of disabling exports, I found that there are parts of the
> Royale framework that rely on the fact that properties are exported.
> Bindings and setting properties in MXML are the most visible. There are
> probably more that I didn't discover yet because the first two had such a
> big impact. Honestly, I am not experienced enough in the framework side of
> Royale to know that I won't break anything if I try to start making 
changes
> to ensure that all framework code can handle property renaming. Maybe
> disabling exports is still possible, but I don't think that I'm the one 
who
> can do it.
> 
> In the end, I was left feeling extremely frustrated with Closure compiler
> once again. It's not the first time, and it's unlikely to be the last. I
> wasted two whole months trying to follow its incredibly strict rule 
system.
> In the past, I have tried to fight Closure instead, so I thought that I 
was
> doing things right this time. I really wish I would have spent that time
> doing something else that would have benefitted Royale more.
> 
> Side note: As I was reverting the rename/export changes I had made to the
> compiler, I realized that there were some 

Re: Maven Distribution SDK fixed and working for IDEs

[Christofer Dutz]

Hi all, 

Good to know it's now working.

So what is still the difference between the Maven and the Ant distribution?

I'm asking cause I would love to make the maven distribution match the Ant 
version and just use the one Maven created in the future.

Chris


Am 26.03.20, 17:58 schrieb "Carlos Rovira" :

Hi Piotr,

just downloaded latest nightly and could finally compile the TDJ.
Is failing due to some config issue, but that's an issue to solve in TDJ
config
Congrats y think I can at last use Moonshine and explore it! :)



El jue., 26 mar. 2020 a las 12:44, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Hi Carlos,
>
> Colleague from the Team was able to reproduce your problem with "Build
> Project". It looks like he fixed that - you can download Nightly Build of
> Moonshine and check.
>
> Thanks,
> Piotr
>
> pon., 23 mar 2020 o 15:10 Carlos Rovira 
> napisał(a):
>
> > Yeah, hope someone on your team could know where we can start looking :)
> > thanks!
> > Carlos
> >
> > El lun., 23 mar. 2020 a las 15:04, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > Next is reproduce your problem with Moonshine. ;)
> > >
> > > pon., 23 mar 2020 o 15:02 Carlos Rovira 
> > > napisał(a):
> > >
> > > > Very cool Piotr!
> > > > seems we finally has Maven distribution sdk working! :)
> > > >
> > > > El lun., 23 mar. 2020 a las 14:44, Piotr Zarzycki (<
> > > > piotrzarzyck...@gmail.com>) escribió:
> > > >
> > > > > Hi Guys,
> > > > >
> > > > > I just checked Maven Distribution with Moonshine and I was able to
> > > build
> > > > > Jewel Hello World and TourDeJewel. :)
> > > > >
> > > > > Thanks,
> > > > > Piotr
> > > > >
> > > > > niedz., 22 mar 2020 o 20:58 Carlos Rovira  >
> > > > > napisał(a):
> > > > >
> > > > > > Hi Piotr,
> > > > > >
> > > > > > nothing happens or log is printed in the console, is like if I
> > didn't
> > > > > push
> > > > > > the menu button.
> > > > > > I ensured that I have the SDK setup, maybe something more is
> > needed,
> > > > and
> > > > > > I'm missing something.
> > > > > > As well I understand that "Project > Build Project" is the right
> > > option
> > > > > in
> > > > > > the menu to push
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > El dom., 22 mar. 2020 a las 17:55, Piotr Zarzycki (<
> > > > > > piotrzarzyck...@gmail.com>) escribió:
> > > > > >
> > > > > > > Carlos,
> > > > > > >
> > > > > > > By saying that nothing happens - you don't get any information
> on
> > > the
> > > > > > > console at all?
> > > > > > >
> > > > > > > On Sun, Mar 22, 2020, 5:34 PM Carlos Rovira <
> > > carlosrov...@apache.org
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Chris and Piotr,
> > > > > > > >
> > > > > > > > I was having the same issue. After latest PR from Chris, I
> can
> > > > > confirm
> > > > > > is
> > > > > > > > working ok :)
> > > > > > > > Piotr, please, a last attempt. I think you'll get working
> right
> > > now
> > > > > > from
> > > > > > > > Moonshine.
> > > > > > > >
> > > > > > > > As well I'm curious about how to build with IDE in 
Moonshine,
> > or
> > > > why
> > > > > > > >  Project > Build Project is not working for me
> > > > > > > > something I must have into account?
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > Carlos
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > El dom., 22 mar. 2020 a las 17:04, Christofer Dutz (<
> > > > > > > > christofer.d...@c-ware.de>) escribió:
> > > > > > > >
> > > > > > > > > Yeah ... sorry for that.
> > > > > > > > >
> > > > > > > > > I noticed that I took care of the "SNAPSHOT" instead of 
the
> > > > > > Timestamp,
> > > > > > > > but
> > > > > > > > > I forgot to add the classifier ... will be in the next PR.
> > > > > > > > > Can you confirm that now the files have a "SNAPSHOT"
> instead
> > of
> > > > the
> > > > > > > > > Timestamp?
> > > > > > > > >
> > > > > > > > > Chris
> > > > > > > > >
> > > > > > > > > Am 22.03.20, 15:56 schrieb "Piotr Zarzycki" <
> > > > > > > piotrzarzyck...@gmail.com
> > > > > > > > >:
> > > > > > > > >
> > > > > > > > > Hi Chris,
> > > > > > > > >
> > > > > > > > > Nothing changed I have exactly same issue after 
pulling
> > all
> > > > > > changes
> > > > > > > > and
> > > > > > > > > rebuilding sdk.
> > > > > > > > >
> > > > > > > > > niedz., 22 mar 2020 o 12:15 Carlos Rovira <
> > > > > > carlosrov...@apache.org
> > > > > > > >
  

Re: Maven Distribution SDK fixed and working for IDEs

[Carlos Rovira]

Hi Piotr,

just downloaded latest nightly and could finally compile the TDJ.
Is failing due to some config issue, but that's an issue to solve in TDJ
config
Congrats y think I can at last use Moonshine and explore it! :)



El jue., 26 mar. 2020 a las 12:44, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Hi Carlos,
>
> Colleague from the Team was able to reproduce your problem with "Build
> Project". It looks like he fixed that - you can download Nightly Build of
> Moonshine and check.
>
> Thanks,
> Piotr
>
> pon., 23 mar 2020 o 15:10 Carlos Rovira 
> napisał(a):
>
> > Yeah, hope someone on your team could know where we can start looking :)
> > thanks!
> > Carlos
> >
> > El lun., 23 mar. 2020 a las 15:04, Piotr Zarzycki (<
> > piotrzarzyck...@gmail.com>) escribió:
> >
> > > Next is reproduce your problem with Moonshine. ;)
> > >
> > > pon., 23 mar 2020 o 15:02 Carlos Rovira 
> > > napisał(a):
> > >
> > > > Very cool Piotr!
> > > > seems we finally has Maven distribution sdk working! :)
> > > >
> > > > El lun., 23 mar. 2020 a las 14:44, Piotr Zarzycki (<
> > > > piotrzarzyck...@gmail.com>) escribió:
> > > >
> > > > > Hi Guys,
> > > > >
> > > > > I just checked Maven Distribution with Moonshine and I was able to
> > > build
> > > > > Jewel Hello World and TourDeJewel. :)
> > > > >
> > > > > Thanks,
> > > > > Piotr
> > > > >
> > > > > niedz., 22 mar 2020 o 20:58 Carlos Rovira  >
> > > > > napisał(a):
> > > > >
> > > > > > Hi Piotr,
> > > > > >
> > > > > > nothing happens or log is printed in the console, is like if I
> > didn't
> > > > > push
> > > > > > the menu button.
> > > > > > I ensured that I have the SDK setup, maybe something more is
> > needed,
> > > > and
> > > > > > I'm missing something.
> > > > > > As well I understand that "Project > Build Project" is the right
> > > option
> > > > > in
> > > > > > the menu to push
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > El dom., 22 mar. 2020 a las 17:55, Piotr Zarzycki (<
> > > > > > piotrzarzyck...@gmail.com>) escribió:
> > > > > >
> > > > > > > Carlos,
> > > > > > >
> > > > > > > By saying that nothing happens - you don't get any information
> on
> > > the
> > > > > > > console at all?
> > > > > > >
> > > > > > > On Sun, Mar 22, 2020, 5:34 PM Carlos Rovira <
> > > carlosrov...@apache.org
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi Chris and Piotr,
> > > > > > > >
> > > > > > > > I was having the same issue. After latest PR from Chris, I
> can
> > > > > confirm
> > > > > > is
> > > > > > > > working ok :)
> > > > > > > > Piotr, please, a last attempt. I think you'll get working
> right
> > > now
> > > > > > from
> > > > > > > > Moonshine.
> > > > > > > >
> > > > > > > > As well I'm curious about how to build with IDE in Moonshine,
> > or
> > > > why
> > > > > > > >  Project > Build Project is not working for me
> > > > > > > > something I must have into account?
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >
> > > > > > > > Carlos
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > El dom., 22 mar. 2020 a las 17:04, Christofer Dutz (<
> > > > > > > > christofer.d...@c-ware.de>) escribió:
> > > > > > > >
> > > > > > > > > Yeah ... sorry for that.
> > > > > > > > >
> > > > > > > > > I noticed that I took care of the "SNAPSHOT" instead of the
> > > > > > Timestamp,
> > > > > > > > but
> > > > > > > > > I forgot to add the classifier ... will be in the next PR.
> > > > > > > > > Can you confirm that now the files have a "SNAPSHOT"
> instead
> > of
> > > > the
> > > > > > > > > Timestamp?
> > > > > > > > >
> > > > > > > > > Chris
> > > > > > > > >
> > > > > > > > > Am 22.03.20, 15:56 schrieb "Piotr Zarzycki" <
> > > > > > > piotrzarzyck...@gmail.com
> > > > > > > > >:
> > > > > > > > >
> > > > > > > > > Hi Chris,
> > > > > > > > >
> > > > > > > > > Nothing changed I have exactly same issue after pulling
> > all
> > > > > > changes
> > > > > > > > and
> > > > > > > > > rebuilding sdk.
> > > > > > > > >
> > > > > > > > > niedz., 22 mar 2020 o 12:15 Carlos Rovira <
> > > > > > carlosrov...@apache.org
> > > > > > > >
> > > > > > > > > napisał(a):
> > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > Many thanks for the fix Chris.
> > > > > > > > > > Piotr, can you try again and confirm if all is ok
> now?
> > > > > > > > > >
> > > > > > > > > > thanks
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > El dom., 22 mar. 2020 a las 11:47, Christofer Dutz (<
> > > > > > > > > > christofer.d...@c-ware.de>) escribió:
> > > > > > > > > >
> > > > > > > > > > > Hi Piotr,
> > > > > > > > > > >
> > > > > > > > > > > I had a look and you are right ... even if this
> only
> > > > seems
> > > > > to
> > > > > > > > > happen if
> > > > > > > > > > > you haven't built the typedefs on your machine that
> > day
> > > > > > before
> > > > > > > > > building
> > > > > > > > > > 

RE: Numbers not initialized to NaN

[Yishay Weiss]

isNaN(undefined) is actually true, same as isNaN(NaN).

From: Yishay Weiss
Sent: Thursday, March 26, 2020 6:27 PM
To: dev@royale.apache.org
Subject: RE: Numbers not initialized to NaN

Ok, I’ll investigate why it’s undefined.

> isNaN(percentHeight) is thus evaluated

I meant !isNaN

Thanks.


From: Josh Tynjala
Sent: Thursday, March 26, 2020 6:23 PM
To: Apache Royale Development
Subject: Re: Numbers not initialized to NaN

Numbers should be initialized to NaN, unless you've added
-js-default-initializers=false to your compiler options.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 9:17 AM Yishay Weiss  wrote:

> I think this might have come up in one of my previous posts so my
> apologies if I’m repeating a question. In Flex.as we have the following
> code:
>
> if (!isNaN(percentHeight)
> && child.includeInLayout)
> {
> height =
> Math.max(child.minHeight,
>
>   Math.min(child.maxHeight,
>
>   ((percentHeight >= 100) ? h : h * percentHeight / 100)));
> }
>
> percentHeight, which is a Number, seems to be initialized to undefined.
> isNaN(percentHeight) is thus evaluated to true which results in the wrong
> height being set.
>
> Should I change the code to check for undefined instead of NaN, or should
> the compiler initialized to NaN?
>

Re: Releasing: Finally giving up

[Carlos Rovira]

Hi Piotr,

I think is good to wait for Yishay try. I prefer he test the current
process and then comes back and report his founds.
I'll be more happy if all people here see the same problem we're having
instead of just believing in something that if is not tried is a black box
for the rest. For me was a black box until I was in front of it. I now have
a clear knowledge of it. Others need to see if arrives to the same shore or
not.

We need to solve this problem in a way that all people here choose an
option that see is the right one, and I think the only way that we all know
that is experiencing it.

So for me +1 to Yishay trying it and reporting, and thanks for taking that
step forward :)

Hoping to get soon your report of your experience.

Carlos


El jue., 26 mar. 2020 a las 14:47, Piotr Zarzycki (<
piotrzarzyck...@gmail.com>) escribió:

> Chris,
>
> I would love to test stuff, once it's really do for me everything. If you
> are saying that I will take source-bundle (not sure what do you mean by
> that - take source bundle from where) and do in console "ant -f build.xml"
> - That's not what expect. I expect that I will make everything being in one
> console windows.
>
> 1) Prepare RC1 with signed stuff - should I sign stuff if it's RC1 by my
> Apache gpg keys ?
> 2) Produce Maven distribution IDE so I could test them
> 3) Produce Ant IDE artifacts to test them
>
> Provide me an instruction which I do that and I will start going trough it
> in upcoming week. Instruction should also contains whether I need to create
> branches, tags etc. That instruction should contains everything what RM
> should do, what should click, type checkout etc. - Treat me that I would
> just join the project. I was an RM, some steps would be an obvious for me,
> but for Yishay or any other person won't be at all - whether he try old way
> of doing stuff or new.
>
> Thanks,
> Piotr
>
>
>
> czw., 26 mar 2020 o 14:04 Christofer Dutz 
> napisał(a):
>
> > Hi Piotr,
> >
> > I would assume that ideally you would simply do a normal Maven release.
> >
> > This will produce all the artifacts needed for an official Apache release
> > and
> > also create and deploy the convenience binaries for Maven.
> >
> > I would then suggest to use the source-bundle and run the Ant build
> inside
> > it to produce the Ant convenience binary (SDK) from that.
> >
> > Chris
> >
> >
> >
> > Am 26.03.20, 13:43 schrieb "Piotr Zarzycki"  >:
> >
> > Hi Chris,
> >
> > My end expectation is that I will be able to prepare RC1 by Maven,
> but
> > also
> > take care of ANT build - I'm not sure maybe it would be enough if ANT
> > build
> > will be launched by maven and produce IDE ready SDK - which could be
> > tested
> > in that way.
> >
> > Thanks,
> > Piotr
> >
> > czw., 26 mar 2020 o 13:38 Christofer Dutz  >
> > napisał(a):
> >
> > > Hi Piotr,
> > >
> > > generally the build is currently already in a state we should be
> > able to
> > > release Royale with Maven.
> > > I intentionally put all the bells and whistles in a profile that
> you
> > need
> > > to activate “royale-release”.
> > > If you don’t do that, it should be a normal Maven release.
> > >
> > > Chris
> > >
> > > Von: Piotr Zarzycki 
> > > Antworten an: "dev@royale.apache.org" 
> > > Datum: Donnerstag, 26. März 2020 um 12:27
> > > An: Apache Royale Development 
> > > Betreff: Re: Releasing: Finally giving up
> > >
> > > Hi All,
> > >
> > > I'm member of Apache Foundation for quite some time now. I think I
> > have
> > > wrote maybe 2-3 emails during that time on members mailing list. -
> > Why? -
> > > well I'm a person which doesn't like never ending stories, stories
> > which
> > > are not end up with consensus nor action and I'm sorry but this is
> > how it
> > > looks like in most cases there. Here we are in Apache Royale
> project
> > where
> > > this thread ended up exactly the same - never ending story. - As
> PMC
> > of
> > > this project I would like to say enough! :)
> > >
> > > I had hope that when Carlos and Chris try CI steps and in the
> > process they
> > > may have some issues, but they will end up in the same place as I
> > ended up
> > > where I was able to prepare RC1 in about 2h without the problem. It
> > turns
> > > out that they end up in the place where I have started, in the
> place
> > where
> > > I have spend 5-6 days of work to finally reach stable point. They
> > ended up
> > > frustrated in the same way as I was!
> > >
> > > I really don't care now what kind of issue they have now, whether
> > it's
> > > fixable or not - I just have enough of those never ending
> > discussions where
> > > there is absolutely no results.
> > >
> > > I met Chris in US in Miami and I have spend with him best time
> ever,
> > he is
> > > really great developer - if he is saying that he will have 

RE: Numbers not initialized to NaN

[Yishay Weiss]

Ok, I’ll investigate why it’s undefined.

> isNaN(percentHeight) is thus evaluated

I meant !isNaN

Thanks.


From: Josh Tynjala
Sent: Thursday, March 26, 2020 6:23 PM
To: Apache Royale Development
Subject: Re: Numbers not initialized to NaN

Numbers should be initialized to NaN, unless you've added
-js-default-initializers=false to your compiler options.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 9:17 AM Yishay Weiss  wrote:

> I think this might have come up in one of my previous posts so my
> apologies if I’m repeating a question. In Flex.as we have the following
> code:
>
> if (!isNaN(percentHeight)
> && child.includeInLayout)
> {
> height =
> Math.max(child.minHeight,
>
>   Math.min(child.maxHeight,
>
>   ((percentHeight >= 100) ? h : h * percentHeight / 100)));
> }
>
> percentHeight, which is a Number, seems to be initialized to undefined.
> isNaN(percentHeight) is thus evaluated to true which results in the wrong
> height being set.
>
> Should I change the code to check for undefined instead of NaN, or should
> the compiler initialized to NaN?
>

Re: Numbers not initialized to NaN

[Josh Tynjala]

Numbers should be initialized to NaN, unless you've added
-js-default-initializers=false to your compiler options.

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Mar 26, 2020 at 9:17 AM Yishay Weiss  wrote:

> I think this might have come up in one of my previous posts so my
> apologies if I’m repeating a question. In Flex.as we have the following
> code:
>
> if (!isNaN(percentHeight)
> && child.includeInLayout)
> {
> height =
> Math.max(child.minHeight,
>
>   Math.min(child.maxHeight,
>
>   ((percentHeight >= 100) ? h : h * percentHeight / 100)));
> }
>
> percentHeight, which is a Number, seems to be initialized to undefined.
> isNaN(percentHeight) is thus evaluated to true which results in the wrong
> height being set.
>
> Should I change the code to check for undefined instead of NaN, or should
> the compiler initialized to NaN?
>

Numbers not initialized to NaN

[Yishay Weiss]

I think this might have come up in one of my previous posts so my apologies if 
I’m repeating a question. In Flex.as we have the following code:

if (!isNaN(percentHeight) && 
child.includeInLayout)
{
height = 
Math.max(child.minHeight,

Math.min(child.maxHeight,

((percentHeight >= 100) ? h : h * percentHeight / 100)));
}

percentHeight, which is a Number, seems to be initialized to undefined. 
isNaN(percentHeight) is thus evaluated to true which results in the wrong 
height being set.

Should I change the code to check for undefined instead of NaN, or should the 
compiler initialized to NaN?

Re: Releasing: Finally giving up

[Piotr Zarzycki]

Chris,

I would love to test stuff, once it's really do for me everything. If you
are saying that I will take source-bundle (not sure what do you mean by
that - take source bundle from where) and do in console "ant -f build.xml"
- That's not what expect. I expect that I will make everything being in one
console windows.

1) Prepare RC1 with signed stuff - should I sign stuff if it's RC1 by my
Apache gpg keys ?
2) Produce Maven distribution IDE so I could test them
3) Produce Ant IDE artifacts to test them

Provide me an instruction which I do that and I will start going trough it
in upcoming week. Instruction should also contains whether I need to create
branches, tags etc. That instruction should contains everything what RM
should do, what should click, type checkout etc. - Treat me that I would
just join the project. I was an RM, some steps would be an obvious for me,
but for Yishay or any other person won't be at all - whether he try old way
of doing stuff or new.

Thanks,
Piotr



czw., 26 mar 2020 o 14:04 Christofer Dutz 
napisał(a):

> Hi Piotr,
>
> I would assume that ideally you would simply do a normal Maven release.
>
> This will produce all the artifacts needed for an official Apache release
> and
> also create and deploy the convenience binaries for Maven.
>
> I would then suggest to use the source-bundle and run the Ant build inside
> it to produce the Ant convenience binary (SDK) from that.
>
> Chris
>
>
>
> Am 26.03.20, 13:43 schrieb "Piotr Zarzycki" :
>
> Hi Chris,
>
> My end expectation is that I will be able to prepare RC1 by Maven, but
> also
> take care of ANT build - I'm not sure maybe it would be enough if ANT
> build
> will be launched by maven and produce IDE ready SDK - which could be
> tested
> in that way.
>
> Thanks,
> Piotr
>
> czw., 26 mar 2020 o 13:38 Christofer Dutz 
> napisał(a):
>
> > Hi Piotr,
> >
> > generally the build is currently already in a state we should be
> able to
> > release Royale with Maven.
> > I intentionally put all the bells and whistles in a profile that you
> need
> > to activate “royale-release”.
> > If you don’t do that, it should be a normal Maven release.
> >
> > Chris
> >
> > Von: Piotr Zarzycki 
> > Antworten an: "dev@royale.apache.org" 
> > Datum: Donnerstag, 26. März 2020 um 12:27
> > An: Apache Royale Development 
> > Betreff: Re: Releasing: Finally giving up
> >
> > Hi All,
> >
> > I'm member of Apache Foundation for quite some time now. I think I
> have
> > wrote maybe 2-3 emails during that time on members mailing list. -
> Why? -
> > well I'm a person which doesn't like never ending stories, stories
> which
> > are not end up with consensus nor action and I'm sorry but this is
> how it
> > looks like in most cases there. Here we are in Apache Royale project
> where
> > this thread ended up exactly the same - never ending story. - As PMC
> of
> > this project I would like to say enough! :)
> >
> > I had hope that when Carlos and Chris try CI steps and in the
> process they
> > may have some issues, but they will end up in the same place as I
> ended up
> > where I was able to prepare RC1 in about 2h without the problem. It
> turns
> > out that they end up in the place where I have started, in the place
> where
> > I have spend 5-6 days of work to finally reach stable point. They
> ended up
> > frustrated in the same way as I was!
> >
> > I really don't care now what kind of issue they have now, whether
> it's
> > fixable or not - I just have enough of those never ending
> discussions where
> > there is absolutely no results.
> >
> > I met Chris in US in Miami and I have spend with him best time ever,
> he is
> > really great developer - if he is saying that he will have release
> process
> > in 3-4 steps on my machine - I'm +1 make it so. Not tomorrow, not in
> a week
> > - start today!
> >
> > Please start whole work on that and make it happen. I will be the
> first
> > who try the process and maybe with Chris's help we will solve also
> issue
> > with uploading artifacts to staging area which we had.
> >
> > Good Luck,
> > Piotr
> >
> > czw., 26 mar 2020 o 12:02  > cont...@cristallium.com>> napisał(a):
> >
> > Hi Guys,
> >
> > I'm a lover of Flex dev guy since more than 10 years, been members
> of Flex
> > group on Montpellier (France) at golden age of Flex and go at all
> > conferences when Michaël Chaize came to Montpellier (and using Flex
> every
> > day).
> >
> > First of all I want to thank every one of you for your hard work, and
> > congratulate you for the actual Apache Royale capabilities.
> > With the last features (especialy datagrid), today your great work
> make
> > possible to use Apache Royale in business application. Of course,
> there 

Re: Releasing: Finally giving up

[Christofer Dutz]

Hi Piotr,

I would assume that ideally you would simply do a normal Maven release.

This will produce all the artifacts needed for an official Apache release and
also create and deploy the convenience binaries for Maven.

I would then suggest to use the source-bundle and run the Ant build inside 
it to produce the Ant convenience binary (SDK) from that.

Chris



Am 26.03.20, 13:43 schrieb "Piotr Zarzycki" :

Hi Chris,

My end expectation is that I will be able to prepare RC1 by Maven, but also
take care of ANT build - I'm not sure maybe it would be enough if ANT build
will be launched by maven and produce IDE ready SDK - which could be tested
in that way.

Thanks,
Piotr

czw., 26 mar 2020 o 13:38 Christofer Dutz 
napisał(a):

> Hi Piotr,
>
> generally the build is currently already in a state we should be able to
> release Royale with Maven.
> I intentionally put all the bells and whistles in a profile that you need
> to activate “royale-release”.
> If you don’t do that, it should be a normal Maven release.
>
> Chris
>
> Von: Piotr Zarzycki 
> Antworten an: "dev@royale.apache.org" 
> Datum: Donnerstag, 26. März 2020 um 12:27
> An: Apache Royale Development 
> Betreff: Re: Releasing: Finally giving up
>
> Hi All,
>
> I'm member of Apache Foundation for quite some time now. I think I have
> wrote maybe 2-3 emails during that time on members mailing list. - Why? -
> well I'm a person which doesn't like never ending stories, stories which
> are not end up with consensus nor action and I'm sorry but this is how it
> looks like in most cases there. Here we are in Apache Royale project where
> this thread ended up exactly the same - never ending story. - As PMC of
> this project I would like to say enough! :)
>
> I had hope that when Carlos and Chris try CI steps and in the process they
> may have some issues, but they will end up in the same place as I ended up
> where I was able to prepare RC1 in about 2h without the problem. It turns
> out that they end up in the place where I have started, in the place where
> I have spend 5-6 days of work to finally reach stable point. They ended up
> frustrated in the same way as I was!
>
> I really don't care now what kind of issue they have now, whether it's
> fixable or not - I just have enough of those never ending discussions 
where
> there is absolutely no results.
>
> I met Chris in US in Miami and I have spend with him best time ever, he is
> really great developer - if he is saying that he will have release process
> in 3-4 steps on my machine - I'm +1 make it so. Not tomorrow, not in a 
week
> - start today!
>
> Please start whole work on that and make it happen. I will be the first
> who try the process and maybe with Chris's help we will solve also issue
> with uploading artifacts to staging area which we had.
>
> Good Luck,
> Piotr
>
> czw., 26 mar 2020 o 12:02  cont...@cristallium.com>> napisał(a):
>
> Hi Guys,
>
> I'm a lover of Flex dev guy since more than 10 years, been members of Flex
> group on Montpellier (France) at golden age of Flex and go at all
> conferences when Michaël Chaize came to Montpellier (and using Flex every
> day).
>
> First of all I want to thank every one of you for your hard work, and
> congratulate you for the actual Apache Royale capabilities.
> With the last features (especialy datagrid), today your great work make
> possible to use Apache Royale in business application. Of course, there 
are
> bugs, but when reported, it's quickly fix, this is great.
>
> Now, this is a huge opportunity but also risk for all guys like me to adop
> Apache Royale for futur projects or use it instead of using Air when it's
> possible.
> Personnaly, I first use it on my own Webs applications and perhaps for my
> customers on little applications for the begin. My big enormous worry is 
to
> use it and be alone in front of a SDK bug.
> Seeing new release every 1 or 2 months should certainly reassure me. For
> now I see SDK 0.9.7 since a lot of time and this make me affraid and I
> don't understand why there is no 0.9.8.
>
> I'm speaking as an Apache Royale SDK user : I'm very sad to read these
> debates on the subject of tools to use for making release. I don't care
> about tools nedeed or not to build the release SDK.
> I would like use Apache Royale to build RAD (Rapid Application Dev) Web
> applications and see more and more SDK features added, and participate to
> project (like today) by reporting bug  by using my time on isolate the bug
> and make tests cases with screenshoots to save your time in fixing it.
>
> Using Reac, Bootstrap, AngularJS or other similar is a 

Re: Releasing: Finally giving up

[Piotr Zarzycki]

Hi Chris,

My end expectation is that I will be able to prepare RC1 by Maven, but also
take care of ANT build - I'm not sure maybe it would be enough if ANT build
will be launched by maven and produce IDE ready SDK - which could be tested
in that way.

Thanks,
Piotr

czw., 26 mar 2020 o 13:38 Christofer Dutz 
napisał(a):

> Hi Piotr,
>
> generally the build is currently already in a state we should be able to
> release Royale with Maven.
> I intentionally put all the bells and whistles in a profile that you need
> to activate “royale-release”.
> If you don’t do that, it should be a normal Maven release.
>
> Chris
>
> Von: Piotr Zarzycki 
> Antworten an: "dev@royale.apache.org" 
> Datum: Donnerstag, 26. März 2020 um 12:27
> An: Apache Royale Development 
> Betreff: Re: Releasing: Finally giving up
>
> Hi All,
>
> I'm member of Apache Foundation for quite some time now. I think I have
> wrote maybe 2-3 emails during that time on members mailing list. - Why? -
> well I'm a person which doesn't like never ending stories, stories which
> are not end up with consensus nor action and I'm sorry but this is how it
> looks like in most cases there. Here we are in Apache Royale project where
> this thread ended up exactly the same - never ending story. - As PMC of
> this project I would like to say enough! :)
>
> I had hope that when Carlos and Chris try CI steps and in the process they
> may have some issues, but they will end up in the same place as I ended up
> where I was able to prepare RC1 in about 2h without the problem. It turns
> out that they end up in the place where I have started, in the place where
> I have spend 5-6 days of work to finally reach stable point. They ended up
> frustrated in the same way as I was!
>
> I really don't care now what kind of issue they have now, whether it's
> fixable or not - I just have enough of those never ending discussions where
> there is absolutely no results.
>
> I met Chris in US in Miami and I have spend with him best time ever, he is
> really great developer - if he is saying that he will have release process
> in 3-4 steps on my machine - I'm +1 make it so. Not tomorrow, not in a week
> - start today!
>
> Please start whole work on that and make it happen. I will be the first
> who try the process and maybe with Chris's help we will solve also issue
> with uploading artifacts to staging area which we had.
>
> Good Luck,
> Piotr
>
> czw., 26 mar 2020 o 12:02  cont...@cristallium.com>> napisał(a):
>
> Hi Guys,
>
> I'm a lover of Flex dev guy since more than 10 years, been members of Flex
> group on Montpellier (France) at golden age of Flex and go at all
> conferences when Michaël Chaize came to Montpellier (and using Flex every
> day).
>
> First of all I want to thank every one of you for your hard work, and
> congratulate you for the actual Apache Royale capabilities.
> With the last features (especialy datagrid), today your great work make
> possible to use Apache Royale in business application. Of course, there are
> bugs, but when reported, it's quickly fix, this is great.
>
> Now, this is a huge opportunity but also risk for all guys like me to adop
> Apache Royale for futur projects or use it instead of using Air when it's
> possible.
> Personnaly, I first use it on my own Webs applications and perhaps for my
> customers on little applications for the begin. My big enormous worry is to
> use it and be alone in front of a SDK bug.
> Seeing new release every 1 or 2 months should certainly reassure me. For
> now I see SDK 0.9.7 since a lot of time and this make me affraid and I
> don't understand why there is no 0.9.8.
>
> I'm speaking as an Apache Royale SDK user : I'm very sad to read these
> debates on the subject of tools to use for making release. I don't care
> about tools nedeed or not to build the release SDK.
> I would like use Apache Royale to build RAD (Rapid Application Dev) Web
> applications and see more and more SDK features added, and participate to
> project (like today) by reporting bug  by using my time on isolate the bug
> and make tests cases with screenshoots to save your time in fixing it.
>
> Using Reac, Bootstrap, AngularJS or other similar is a back to 80's. How
> can I explain my customer that I need 3 ou 4 days to make thinks that took
> me 1 day with Flex ?
> The big competitive advantage of Apache Royale is not only be able to
> re-use Flex apps but is also simplicity and time saving where other SDK
> can't do it. (I think you already know that)
>
> I am convinced that all guys like me will jump using Royale when they will
> know that there is a bug free SDK with fast evolution available.
> (unfortunaly it's not known enough, nobody know someone working in
> newspapers ?)
>
> So please, I beg you, don't waste your time on things that are not
> essential and like Carlos said, go forward. From outside view, Apache
> Royale stay sticky to 0.9.7.
>
> You are so close of a v1.0, I hope see it very soon and other releases
> with bugs 

Re: Releasing: Finally giving up

[Christofer Dutz]

Hi Piotr,

generally the build is currently already in a state we should be able to 
release Royale with Maven.
I intentionally put all the bells and whistles in a profile that you need to 
activate “royale-release”.
If you don’t do that, it should be a normal Maven release.

Chris

Von: Piotr Zarzycki 
Antworten an: "dev@royale.apache.org" 
Datum: Donnerstag, 26. März 2020 um 12:27
An: Apache Royale Development 
Betreff: Re: Releasing: Finally giving up

Hi All,

I'm member of Apache Foundation for quite some time now. I think I have wrote 
maybe 2-3 emails during that time on members mailing list. - Why? - well I'm a 
person which doesn't like never ending stories, stories which are not end up 
with consensus nor action and I'm sorry but this is how it looks like in most 
cases there. Here we are in Apache Royale project where this thread ended up 
exactly the same - never ending story. - As PMC of this project I would like to 
say enough! :)

I had hope that when Carlos and Chris try CI steps and in the process they may 
have some issues, but they will end up in the same place as I ended up where I 
was able to prepare RC1 in about 2h without the problem. It turns out that they 
end up in the place where I have started, in the place where I have spend 5-6 
days of work to finally reach stable point. They ended up frustrated in the 
same way as I was!

I really don't care now what kind of issue they have now, whether it's fixable 
or not - I just have enough of those never ending discussions where there is 
absolutely no results.

I met Chris in US in Miami and I have spend with him best time ever, he is 
really great developer - if he is saying that he will have release process in 
3-4 steps on my machine - I'm +1 make it so. Not tomorrow, not in a week - 
start today!

Please start whole work on that and make it happen. I will be the first who try 
the process and maybe with Chris's help we will solve also issue with uploading 
artifacts to staging area which we had.

Good Luck,
Piotr

czw., 26 mar 2020 o 12:02 
mailto:cont...@cristallium.com>> napisał(a):

Hi Guys,

I'm a lover of Flex dev guy since more than 10 years, been members of Flex 
group on Montpellier (France) at golden age of Flex and go at all conferences 
when Michaël Chaize came to Montpellier (and using Flex every day).

First of all I want to thank every one of you for your hard work, and 
congratulate you for the actual Apache Royale capabilities.
With the last features (especialy datagrid), today your great work make 
possible to use Apache Royale in business application. Of course, there are 
bugs, but when reported, it's quickly fix, this is great.

Now, this is a huge opportunity but also risk for all guys like me to adop 
Apache Royale for futur projects or use it instead of using Air when it's 
possible.
Personnaly, I first use it on my own Webs applications and perhaps for my 
customers on little applications for the begin. My big enormous worry is to use 
it and be alone in front of a SDK bug.
Seeing new release every 1 or 2 months should certainly reassure me. For now I 
see SDK 0.9.7 since a lot of time and this make me affraid and I don't 
understand why there is no 0.9.8.

I'm speaking as an Apache Royale SDK user : I'm very sad to read these debates 
on the subject of tools to use for making release. I don't care about tools 
nedeed or not to build the release SDK.
I would like use Apache Royale to build RAD (Rapid Application Dev) Web 
applications and see more and more SDK features added, and participate to 
project (like today) by reporting bug  by using my time on isolate the bug and 
make tests cases with screenshoots to save your time in fixing it.

Using Reac, Bootstrap, AngularJS or other similar is a back to 80's. How can I 
explain my customer that I need 3 ou 4 days to make thinks that took me 1 day 
with Flex ?
The big competitive advantage of Apache Royale is not only be able to re-use 
Flex apps but is also simplicity and time saving where other SDK can't do it. 
(I think you already know that)

I am convinced that all guys like me will jump using Royale when they will know 
that there is a bug free SDK with fast evolution available. (unfortunaly it's 
not known enough, nobody know someone working in newspapers ?)

So please, I beg you, don't waste your time on things that are not essential 
and like Carlos said, go forward. From outside view, Apache Royale stay sticky 
to 0.9.7.

You are so close of a v1.0, I hope see it very soon and other releases with 
bugs fix every 1, 2 or 3 months.
Consider my comments as support and not criticism.

Thanks again for your hard work.

Long life and success to Apache Royale !

Fred



Le 26.03.2020 09:26, Carlos Rovira a écrit :
Hi,

that's amazingly simple, so I think we should go that way without doubt. I
think reached this point there's a clear sense of that we need to go that
route.

We tried our best to stick with the previous process and we're all
loosing lots of 

Re: Releasing: Finally giving up

[Piotr Zarzycki]

Hi Yishay,

I would say - great some time ago, but now - We will have again bunch of
emails with same questions on the list which were asked and debated here,
again and again. It end up in the same place with loosed energy. However I
hope guys won't wait but start working in parallel on new stuff - I'm sorry
but I don't believe in a an old process anymore - not after what I'm
reading here.

Thanks,
Piotr

czw., 26 mar 2020 o 13:13 Yishay Weiss  napisał(a):

> Hi All,
>
> I too, feel very uncomfortable participating in these threads. While
> grateful to Carlos and Chris for their work I’m very annoyed with the tone
> of ultimatums and doom and gloom. Alex has put in a lot of work into this
> and I trust his concerns are technical, rather than protecting his ego as
> has been suggested. We need to get this discussion back on technical tracks.
>
> Since Chris has given up, and it looks like Carlos has as well, I
> volunteer to start the release process from scratch next Sunday, which is
> after Israel has switched to day light saving. I will try to do the process
> incrementally and in parallel to my other tasks. If by the end of the week
> it turns out the process is too cumbersome and cannot realistically be made
> to work smoothly I will be in favor of changing the requirements to enable
> Chris’s mvn setup to be the main release tool.
>
> Thanks,
> Yishay
>
> From: Piotr Zarzycki
> Sent: Thursday, March 26, 2020 1:27 PM
> To: Apache Royale Development
> Subject: Re: Releasing: Finally giving up
>
> Hi All,
>
> I'm member of Apache Foundation for quite some time now. I think I have
> wrote maybe 2-3 emails during that time on members mailing list. - Why? -
> well I'm a person which doesn't like never ending stories, stories which
> are not end up with consensus nor action and I'm sorry but this is how it
> looks like in most cases there. Here we are in Apache Royale project where
> this thread ended up exactly the same - never ending story. - As PMC of
> this project I would like to say enough! :)
>
> I had hope that when Carlos and Chris try CI steps and in the process they
> may have some issues, but they will end up in the same place as I ended up
> where I was able to prepare RC1 in about 2h without the problem. It turns
> out that they end up in the place where I have started, in the place where
> I have spend 5-6 days of work to finally reach stable point. They ended up
> frustrated in the same way as I was!
>
> I really don't care now what kind of issue they have now, whether it's
> fixable or not - I just have enough of those never ending discussions where
> there is absolutely no results.
>
> I met Chris in US in Miami and I have spend with him best time ever, he is
> really great developer - if he is saying that he will have release process
> in 3-4 steps on my machine - I'm +1 make it so. Not tomorrow, not in a week
> - start today!
>
> Please start whole work on that and make it happen. I will be the first
> who try the process and maybe with Chris's help we will solve also issue
> with uploading artifacts to staging area which we had.
>
> Good Luck,
> Piotr
>
> czw., 26 mar 2020 o 12:02  cont...@cristallium.com>> napisał(a):
>
> Hi Guys,
>
> I'm a lover of Flex dev guy since more than 10 years, been members of Flex
> group on Montpellier (France) at golden age of Flex and go at all
> conferences when Michaël Chaize came to Montpellier (and using Flex every
> day).
>
> First of all I want to thank every one of you for your hard work, and
> congratulate you for the actual Apache Royale capabilities.
> With the last features (especialy datagrid), today your great work make
> possible to use Apache Royale in business application. Of course, there are
> bugs, but when reported, it's quickly fix, this is great.
>
> Now, this is a huge opportunity but also risk for all guys like me to adop
> Apache Royale for futur projects or use it instead of using Air when it's
> possible.
> Personnaly, I first use it on my own Webs applications and perhaps for my
> customers on little applications for the begin. My big enormous worry is to
> use it and be alone in front of a SDK bug.
> Seeing new release every 1 or 2 months should certainly reassure me. For
> now I see SDK 0.9.7 since a lot of time and this make me affraid and I
> don't understand why there is no 0.9.8.
>
> I'm speaking as an Apache Royale SDK user : I'm very sad to read these
> debates on the subject of tools to use for making release. I don't care
> about tools nedeed or not to build the release SDK.
> I would like use Apache Royale to build RAD (Rapid Application Dev) Web
> applications and see more and more SDK features added, and participate to
> project (like today) by reporting bug  by using my time on isolate the bug
> and make tests cases with screenshoots to save your time in fixing it.
>
> Using Reac, Bootstrap, AngularJS or other similar is a back to 80's. How
> can I 

RE: Releasing: Finally giving up

[Yishay Weiss]

Hi All,

I too, feel very uncomfortable participating in these threads. While grateful 
to Carlos and Chris for their work I’m very annoyed with the tone of ultimatums 
and doom and gloom. Alex has put in a lot of work into this and I trust his 
concerns are technical, rather than protecting his ego as has been suggested. 
We need to get this discussion back on technical tracks.

Since Chris has given up, and it looks like Carlos has as well, I volunteer to 
start the release process from scratch next Sunday, which is after Israel has 
switched to day light saving. I will try to do the process incrementally and in 
parallel to my other tasks. If by the end of the week it turns out the process 
is too cumbersome and cannot realistically be made to work smoothly I will be 
in favor of changing the requirements to enable Chris’s mvn setup to be the 
main release tool.

Thanks,
Yishay

From: Piotr Zarzycki
Sent: Thursday, March 26, 2020 1:27 PM
To: Apache Royale Development
Subject: Re: Releasing: Finally giving up

Hi All,

I'm member of Apache Foundation for quite some time now. I think I have wrote 
maybe 2-3 emails during that time on members mailing list. - Why? - well I'm a 
person which doesn't like never ending stories, stories which are not end up 
with consensus nor action and I'm sorry but this is how it looks like in most 
cases there. Here we are in Apache Royale project where this thread ended up 
exactly the same - never ending story. - As PMC of this project I would like to 
say enough! :)

I had hope that when Carlos and Chris try CI steps and in the process they may 
have some issues, but they will end up in the same place as I ended up where I 
was able to prepare RC1 in about 2h without the problem. It turns out that they 
end up in the place where I have started, in the place where I have spend 5-6 
days of work to finally reach stable point. They ended up frustrated in the 
same way as I was!

I really don't care now what kind of issue they have now, whether it's fixable 
or not - I just have enough of those never ending discussions where there is 
absolutely no results.

I met Chris in US in Miami and I have spend with him best time ever, he is 
really great developer - if he is saying that he will have release process in 
3-4 steps on my machine - I'm +1 make it so. Not tomorrow, not in a week - 
start today!

Please start whole work on that and make it happen. I will be the first who try 
the process and maybe with Chris's help we will solve also issue with uploading 
artifacts to staging area which we had.

Good Luck,
Piotr

czw., 26 mar 2020 o 12:02 
mailto:cont...@cristallium.com>> napisał(a):

Hi Guys,

I'm a lover of Flex dev guy since more than 10 years, been members of Flex 
group on Montpellier (France) at golden age of Flex and go at all conferences 
when Michaël Chaize came to Montpellier (and using Flex every day).

First of all I want to thank every one of you for your hard work, and 
congratulate you for the actual Apache Royale capabilities.
With the last features (especialy datagrid), today your great work make 
possible to use Apache Royale in business application. Of course, there are 
bugs, but when reported, it's quickly fix, this is great.

Now, this is a huge opportunity but also risk for all guys like me to adop 
Apache Royale for futur projects or use it instead of using Air when it's 
possible.
Personnaly, I first use it on my own Webs applications and perhaps for my 
customers on little applications for the begin. My big enormous worry is to use 
it and be alone in front of a SDK bug.
Seeing new release every 1 or 2 months should certainly reassure me. For now I 
see SDK 0.9.7 since a lot of time and this make me affraid and I don't 
understand why there is no 0.9.8.

I'm speaking as an Apache Royale SDK user : I'm very sad to read these debates 
on the subject of tools to use for making release. I don't care about tools 
nedeed or not to build the release SDK.
I would like use Apache Royale to build RAD (Rapid Application Dev) Web 
applications and see more and more SDK features added, and participate to 
project (like today) by reporting bug  by using my time on isolate the bug and 
make tests cases with screenshoots to save your time in fixing it.

Using Reac, Bootstrap, AngularJS or other similar is a back to 80's. How can I 
explain my customer that I need 3 ou 4 days to make thinks that took me 1 day 
with Flex ?
The big competitive advantage of Apache Royale is not only be able to re-use 
Flex apps but is also simplicity and time saving where other SDK can't do it. 
(I think you already know that)

I am convinced that all guys like me will jump using Royale when they will know 
that there is a bug free SDK with fast evolution available. (unfortunaly it's 
not known enough, nobody know someone working in newspapers ?)

So please, I beg you, don't waste your time on things that are not 

Re: Maven Distribution SDK fixed and working for IDEs

[Piotr Zarzycki]

Hi Carlos,

Colleague from the Team was able to reproduce your problem with "Build
Project". It looks like he fixed that - you can download Nightly Build of
Moonshine and check.

Thanks,
Piotr

pon., 23 mar 2020 o 15:10 Carlos Rovira 
napisał(a):

> Yeah, hope someone on your team could know where we can start looking :)
> thanks!
> Carlos
>
> El lun., 23 mar. 2020 a las 15:04, Piotr Zarzycki (<
> piotrzarzyck...@gmail.com>) escribió:
>
> > Next is reproduce your problem with Moonshine. ;)
> >
> > pon., 23 mar 2020 o 15:02 Carlos Rovira 
> > napisał(a):
> >
> > > Very cool Piotr!
> > > seems we finally has Maven distribution sdk working! :)
> > >
> > > El lun., 23 mar. 2020 a las 14:44, Piotr Zarzycki (<
> > > piotrzarzyck...@gmail.com>) escribió:
> > >
> > > > Hi Guys,
> > > >
> > > > I just checked Maven Distribution with Moonshine and I was able to
> > build
> > > > Jewel Hello World and TourDeJewel. :)
> > > >
> > > > Thanks,
> > > > Piotr
> > > >
> > > > niedz., 22 mar 2020 o 20:58 Carlos Rovira 
> > > > napisał(a):
> > > >
> > > > > Hi Piotr,
> > > > >
> > > > > nothing happens or log is printed in the console, is like if I
> didn't
> > > > push
> > > > > the menu button.
> > > > > I ensured that I have the SDK setup, maybe something more is
> needed,
> > > and
> > > > > I'm missing something.
> > > > > As well I understand that "Project > Build Project" is the right
> > option
> > > > in
> > > > > the menu to push
> > > > >
> > > > > Thanks
> > > > >
> > > > > El dom., 22 mar. 2020 a las 17:55, Piotr Zarzycki (<
> > > > > piotrzarzyck...@gmail.com>) escribió:
> > > > >
> > > > > > Carlos,
> > > > > >
> > > > > > By saying that nothing happens - you don't get any information on
> > the
> > > > > > console at all?
> > > > > >
> > > > > > On Sun, Mar 22, 2020, 5:34 PM Carlos Rovira <
> > carlosrov...@apache.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi Chris and Piotr,
> > > > > > >
> > > > > > > I was having the same issue. After latest PR from Chris, I can
> > > > confirm
> > > > > is
> > > > > > > working ok :)
> > > > > > > Piotr, please, a last attempt. I think you'll get working right
> > now
> > > > > from
> > > > > > > Moonshine.
> > > > > > >
> > > > > > > As well I'm curious about how to build with IDE in Moonshine,
> or
> > > why
> > > > > > >  Project > Build Project is not working for me
> > > > > > > something I must have into account?
> > > > > > >
> > > > > > > Thanks
> > > > > > >
> > > > > > > Carlos
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > El dom., 22 mar. 2020 a las 17:04, Christofer Dutz (<
> > > > > > > christofer.d...@c-ware.de>) escribió:
> > > > > > >
> > > > > > > > Yeah ... sorry for that.
> > > > > > > >
> > > > > > > > I noticed that I took care of the "SNAPSHOT" instead of the
> > > > > Timestamp,
> > > > > > > but
> > > > > > > > I forgot to add the classifier ... will be in the next PR.
> > > > > > > > Can you confirm that now the files have a "SNAPSHOT" instead
> of
> > > the
> > > > > > > > Timestamp?
> > > > > > > >
> > > > > > > > Chris
> > > > > > > >
> > > > > > > > Am 22.03.20, 15:56 schrieb "Piotr Zarzycki" <
> > > > > > piotrzarzyck...@gmail.com
> > > > > > > >:
> > > > > > > >
> > > > > > > > Hi Chris,
> > > > > > > >
> > > > > > > > Nothing changed I have exactly same issue after pulling
> all
> > > > > changes
> > > > > > > and
> > > > > > > > rebuilding sdk.
> > > > > > > >
> > > > > > > > niedz., 22 mar 2020 o 12:15 Carlos Rovira <
> > > > > carlosrov...@apache.org
> > > > > > >
> > > > > > > > napisał(a):
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Many thanks for the fix Chris.
> > > > > > > > > Piotr, can you try again and confirm if all is ok now?
> > > > > > > > >
> > > > > > > > > thanks
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > El dom., 22 mar. 2020 a las 11:47, Christofer Dutz (<
> > > > > > > > > christofer.d...@c-ware.de>) escribió:
> > > > > > > > >
> > > > > > > > > > Hi Piotr,
> > > > > > > > > >
> > > > > > > > > > I had a look and you are right ... even if this only
> > > seems
> > > > to
> > > > > > > > happen if
> > > > > > > > > > you haven't built the typedefs on your machine that
> day
> > > > > before
> > > > > > > > building
> > > > > > > > > the
> > > > > > > > > > distribution. I just pushed a PR that should fix
> this.
> > > > > > > > > >
> > > > > > > > > > Chris
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Am 22.03.20, 10:59 schrieb "Piotr Zarzycki" <
> > > > > > > > piotrzarzyck...@gmail.com
> > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > Hi Carlos,
> > > > > > > > > >
> > > > > > > > > > I've just build royale-asjs with following
> command:
> > > > > > > > > >
> > > > > > > > > > mvn clean install -P
> > > > > > > with-distribution,option-with-sass-compile
> > > 

Re: Releasing: Finally giving up

[Piotr Zarzycki]

Hi All,

I'm member of Apache Foundation for quite some time now. I think I have
wrote maybe 2-3 emails during that time on members mailing list. - Why? -
well I'm a person which doesn't like never ending stories, stories which
are not end up with consensus nor action and I'm sorry but this is how it
looks like in most cases there. Here we are in Apache Royale project where
this thread ended up exactly the same - never ending story. - As PMC of
this project I would like to say enough! :)

I had hope that when Carlos and Chris try CI steps and in the process they
may have some issues, but they will end up in the same place as I ended up
where I was able to prepare RC1 in about 2h without the problem. It turns
out that they end up in the place where I have started, in the place where
I have spend 5-6 days of work to finally reach stable point. They ended up
frustrated in the same way as I was!

I really don't care now what kind of issue they have now, whether it's
fixable or not - I just have enough of those never ending discussions where
there is absolutely no results.

I met Chris in US in Miami and I have spend with him best time ever, he is
really great developer - if he is saying that he will have release process
in 3-4 steps on my machine - I'm +1 make it so. Not tomorrow, not in a week
- start today!

Please start whole work on that and make it happen. I will be the first who
try the process and maybe with Chris's help we will solve also issue with
uploading artifacts to staging area which we had.

Good Luck,
Piotr

czw., 26 mar 2020 o 12:02  napisał(a):

> Hi Guys,
>
> I'm a lover of Flex dev guy since more than 10 years, been members of Flex 
> group on Montpellier (France) at golden age of Flex and go at all conferences 
> when Michaël Chaize came to Montpellier (and using Flex every day).
>
> First of all I want to thank every one of you for your hard work, and 
> congratulate you for the actual Apache Royale capabilities.
> With the last features (especialy datagrid), today your great work make 
> possible to use Apache Royale in business application. Of course, there are 
> bugs, but when reported, it's quickly fix, this is great.
>
> Now, this is a huge opportunity but also risk for all guys like me to adop 
> Apache Royale for futur projects or use it instead of using Air when it's 
> possible.
> Personnaly, I first use it on my own Webs applications and perhaps for my 
> customers on little applications for the begin. My big enormous worry is to 
> use it and be alone in front of a SDK bug.
> Seeing new release every 1 or 2 months should certainly reassure me. For now 
> I see SDK 0.9.7 since a lot of time and this make me affraid and I don't 
> understand why there is no 0.9.8.
>
> I'm speaking as an Apache Royale SDK user : I'm very sad to read these 
> debates on the subject of tools to use for making release. I don't care about 
> tools nedeed or not to build the release SDK.
> I would like use Apache Royale to build RAD (Rapid Application Dev) Web 
> applications and see more and more SDK features added, and participate to 
> project (like today) by reporting bug  by using my time on isolate the bug 
> and make tests cases with screenshoots to save your time in fixing it.
>
> Using Reac, Bootstrap, AngularJS or other similar is a back to 80's. How can 
> I explain my customer that I need 3 ou 4 days to make thinks that took me 1 
> day with Flex ?
> The big competitive advantage of Apache Royale is not only be able to re-use 
> Flex apps but is also simplicity and time saving where other SDK can't do it. 
> (I think you already know that)
>
> I am convinced that all guys like me will jump using Royale when they will 
> know that there is a bug free SDK with fast evolution available. (unfortunaly 
> it's not known enough, nobody know someone working in newspapers ?)
>
> So please, I beg you, don't waste your time on things that are not essential 
> and like Carlos said, go forward. From outside view, Apache Royale stay 
> sticky to 0.9.7.
>
> You are so close of a v1.0, I hope see it very soon and other releases with 
> bugs fix every 1, 2 or 3 months.
> Consider my comments as support and not criticism.
>
> Thanks again for your hard work.
>
> Long life and success to Apache Royale !
>
> Fred
>
>
>
> Le 26.03.2020 09:26, Carlos Rovira a écrit :
>
> Hi,
>
> that's amazingly simple, so I think we should go that way without doubt. I
> think reached this point there's a clear sense of that we need to go that
> route.
>
> We tried our best to stick with the previous process and we're all
> loosing lots of time. Then currently seems no more people in the community
> was interested in this thread, event to comment a single line (here or in
> the other users list thread), what means that or there's no more people
> like us in this project or people really is not interested and just want us
> to release and go forward.
>
> As previously I think most of the PMCs here (Om, Josh, Greg and me for
> 

Re: Releasing: Finally giving up

[contact]

Hi Guys,

I'm a lover of Flex dev guy since more than 10 years, been members of
Flex group on Montpellier (France) at golden age of Flex and go at all
conferences when Michaël Chaize came to Montpellier (and using Flex
every day).

First of all I want to thank every one of you for your hard work, and
congratulate you for the actual Apache Royale capabilities.
With the last features (especialy datagrid), today your great work make
possible to use Apache Royale in business application. Of course, there
are bugs, but when reported, it's quickly fix, this is great.

Now, this is a huge opportunity but also risk for all guys like me to
adop Apache Royale for futur projects or use it instead of using Air
when it's possible.
Personnaly, I first use it on my own Webs applications and perhaps for
my customers on little applications for the begin. My big enormous worry
is to use it and be alone in front of a SDK bug. 
Seeing new release every 1 or 2 months should certainly reassure me. For

now I see SDK 0.9.7 since a lot of time and this make me affraid and I
don't understand why there is no 0.9.8.

I'm speaking as an Apache Royale SDK user : I'm very sad to read these
debates on the subject of tools to use for making release. I don't care
about tools nedeed or not to build the release SDK.
I would like use Apache Royale to build RAD (Rapid Application Dev) Web
applications and see more and more SDK features added, and participate
to project (like today) by reporting bug  by using my time on isolate
the bug and make tests cases with screenshoots to save your time in
fixing it. 


Using Reac, Bootstrap, AngularJS or other similar is a back to 80's. How
can I explain my customer that I need 3 ou 4 days to make thinks that
took me 1 day with Flex ? 
The big competitive advantage of Apache Royale is not only be able to

re-use Flex apps but is also simplicity and time saving where other SDK
can't do it. (I think you already know that)

I am convinced that all guys like me will jump using Royale when they
will know that there is a bug free SDK with fast evolution available.
(unfortunaly it's not known enough, nobody know someone working in
newspapers ?) 


So please, I beg you, don't waste your time on things that are not
essential and like Carlos said, go forward. From outside view, Apache
Royale stay sticky to 0.9.7. 


You are so close of a v1.0, I hope see it very soon and other releases
with bugs fix every 1, 2 or 3 months.
Consider my comments as support and not criticism.

Thanks again for your hard work.

Long life and success to Apache Royale !

Fred

Le 26.03.2020 09:26, Carlos Rovira a écrit :


Hi,

that's amazingly simple, so I think we should go that way without doubt. I
think reached this point there's a clear sense of that we need to go that
route.

We tried our best to stick with the previous process and we're all
loosing lots of time. Then currently seems no more people in the community
was interested in this thread, event to comment a single line (here or in
the other users list thread), what means that or there's no more people
like us in this project or people really is not interested and just want us
to release and go forward.

As previously I think most of the PMCs here (Om, Josh, Greg and me for
sure), probably Yishay for his concise comments are more for this.
My thinking is that the right now I think only 2 PMCs are for CI Server,
and other one that is uncertainly but didn't try the CI Server.

I think all can live together while is not a must for the rest that don't
want it the others option, so what's about if we release with the
super-simple steps Chris proposal, and others wanting to use CI do that
when is their RM turn ? (of course maintaining it and making it work for
his release without requiring nothing for the rest that doesn't want it).

Release as other projects do is recommended but not required, the same as
the actual CI server (but this one should be less recommended since is a
royale-only practice not seen in any other place).

What's the important thing is to release, do it, and do it easily and often.

Thanks

El jue., 26 mar. 2020 a las 8:24, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:


Ok,

I'll write this a last time as I do feel like we're going in circles and
will from now on not participate in any discussion involving releasing on a
CI server.

A correct Maven release would use (There will be some additional profiles
to activate to include all modules)

1) the "mvn release:branch" call in order to create the branch and bump
the version of develop to the next version.
2) the "mvn release:prepare" to change the pom to the release version, set
the timestamp in the pom (for reproducible builds) build ... if all tests
are good, commit the changes, tag this commit, update the poms to the next
development version, commit those changes and push everything.
3) the "mvn release:perform" which will checkout the tagged version build
everything with the 

Fwd: Reseting the state back

[Carlos Rovira]

sorry wrong list, this was for royale :)

-- Forwarded message -
De: Carlos Rovira 
Date: jue., 26 mar. 2020 a las 9:54
Subject: Reseting the state back
To: 


Hi

I reset versions and remove release/tag branches, so all must be in a safe
state.
Going to wait to see if we can start a (backed) simple release process or
if I must left for others

Thanks


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



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

Re: Releasing: Finally giving up

[Carlos Rovira]

Hi,

that's amazingly simple, so I think we should go that way without doubt. I
think reached this point there's a clear sense of that we need to go that
route.

We tried our best to stick with the previous process and we're all
loosing lots of time. Then currently seems no more people in the community
was interested in this thread, event to comment a single line (here or in
the other users list thread), what means that or there's no more people
like us in this project or people really is not interested and just want us
to release and go forward.

As previously I think most of the PMCs here (Om, Josh, Greg and me for
sure), probably Yishay for his concise comments are more for this.
My thinking is that the right now I think only 2 PMCs are for CI Server,
and other one that is uncertainly but didn't try the CI Server.

I think all can live together while is not a must for the rest that don't
want it the others option, so what's about if we release with the
super-simple steps Chris proposal, and others wanting to use CI do that
when is their RM turn ? (of course maintaining it and making it work for
his release without requiring nothing for the rest that doesn't want it).

Release as other projects do is recommended but not required, the same as
the actual CI server (but this one should be less recommended since is a
royale-only practice not seen in any other place).

What's the important thing is to release, do it, and do it easily and often.

Thanks



El jue., 26 mar. 2020 a las 8:24, Christofer Dutz (<
christofer.d...@c-ware.de>) escribió:

> Ok,
>
> I'll write this a last time as I do feel like we're going in circles and
> will from now on not participate in any discussion involving releasing on a
> CI server.
>
> A correct Maven release would use (There will be some additional profiles
> to activate to include all modules)
>
> 1) the "mvn release:branch" call in order to create the branch and bump
> the version of develop to the next version.
> 2) the "mvn release:prepare" to change the pom to the release version, set
> the timestamp in the pom (for reproducible builds) build ... if all tests
> are good, commit the changes, tag this commit, update the poms to the next
> development version, commit those changes and push everything.
> 3) the "mvn release:perform" which will checkout the tagged version build
> everything with the "apache-release" profile turned on (Which causes the
> source.jars, Javadoc.jars, hashes and gpg singatures to be created as well
> as the assembly) This also deploys the built artifacts to Nexus.
>
> Most of that you are already doing on the CI server however you're not
> letting it do all automatically (For lack of credentials)
>
> But ... if you would just be doing those steps on the RM machine.
>
> Chris
>
>
>
>
>
> Am 26.03.20, 05:54 schrieb "Alex Harui" :
>
>
>
> On 3/25/20, 4:46 PM, "Carlos Rovira"  wrote:
>
> > What I want to know is what the Maven commands should be to
> create a
> > release in this "conventional process" you are referring to.
> >
>
> If you want to know what's the conventional maven process is, I
> think I can
> ask Chris if he wants to work with me on that process, since he
> already did
> many other Apache projects, we can expect the process is what is
> needed for
> us to. But just expect that will be a series of standard maven
> commands
> (prepare, release,...), so nothing strange at all (I expect).
>
> Do you want us to do that?
>
> Yes.  I want to know what the series of standard Maven commands are.
> Then we can figure out how to convert them to run on the CI server.
>
> -Alex
>
> Thanks
>
>
> >
> > Maybe someone else can explain better than me.
> >
> > -Alex
> >
> > On 3/25/20, 2:22 PM, "Carlos Rovira" 
> wrote:
> >
> > Hi Alex,
> >
> > El mié., 25 mar. 2020 a las 21:26, Alex Harui
> > ()
> > escribió:
> >
> > > Carlos,
> > >
> > > I'm pretty sure that part of the "conventional process"
> you want to
> > try
> > > requires filling the staging repo from a local machine.
> > >
> >
> > This is what we already did. If you go to [1] will see [2].
> That was
> > the
> > upload of compiler to the staging repo. When trying to do
> the same for
> > typedefs it failed when trying to fill repo from local
> machine. I think
> > Chris or I should not take more time in trying to fix Ant
> scripts that
> > are
> > failing.
> >
> > Thanks
> >
> > [1]
> >
> 

Re: Control over export/rename: Finally giving up

[Harbs]

Sorry to hear. :-(

I still wonder if maybe we can document all the cases where we’re relying on 
not renaming and find a way to deal with those cases. (for someone who wants to 
disable exports)

I know Greg has done a significant amount of digging related to his reflection 
work. Alex, do you have any thoughts?

Harbs

> On Mar 25, 2020, at 9:06 PM, Josh Tynjala  wrote:
> 
> (With credit to Chris for the subject name )
> 
> Some of you may know that over the last 2-3 months I've been looking into
> ways to add more control over how the compiler handles renaming and
> exporting APIs in the generated JS. Ideally, my work would have culminated
> in a variety of options that would allow release builds to be much smaller,
> if you were willing to sacrifice certain capabilities (things along the
> lines of dynamic access of properties and reflection). Obviously, you would
> have been able to keep things working the same as they do today, so my
> changes would have been opt-in.
> 
> I've determined that Closure does not actually expose the ability to
> prevent renaming of JS APIs, except by exporting them. The advanced
> compiler APIs that Closure exposes to prevent renaming are specifically
> intended for compiling multiple related projects together (like we're doing
> with modules). Additionally, I discovered that Closure does not guarantee
> that any custom rename mappings will be respected. In fact, the
> documentation says they may be completely ignored, and there is official
> guidance that says not to do what I was originally trying to do. I could
> not find any other Closure compiler APIs accessible in Java that could do
> what we want here, so I think that our original assumption that preventing
> renaming programmatically would be possible was incorrect.
> 
> In the case of disabling exports, I found that there are parts of the
> Royale framework that rely on the fact that properties are exported.
> Bindings and setting properties in MXML are the most visible. There are
> probably more that I didn't discover yet because the first two had such a
> big impact. Honestly, I am not experienced enough in the framework side of
> Royale to know that I won't break anything if I try to start making changes
> to ensure that all framework code can handle property renaming. Maybe
> disabling exports is still possible, but I don't think that I'm the one who
> can do it.
> 
> In the end, I was left feeling extremely frustrated with Closure compiler
> once again. It's not the first time, and it's unlikely to be the last. I
> wasted two whole months trying to follow its incredibly strict rule system.
> In the past, I have tried to fight Closure instead, so I thought that I was
> doing things right this time. I really wish I would have spent that time
> doing something else that would have benefitted Royale more.
> 
> Side note: As I was reverting the rename/export changes I had made to the
> compiler, I realized that there were some issues with my previous attempts
> to improve the situation with warn-public-vars. With that in mind, I
> reverted those changes too (for now). I plan to look into a better solution
> for warn-public-vars soon, but I can't guarantee that anything will work
> because it's another place where Closure compiler is the cause of the issue.
> 
> --
> Josh Tynjala
> Bowler Hat LLC 

Re: Releasing: Finally giving up

[Christofer Dutz]

Ok, 

I'll write this a last time as I do feel like we're going in circles and will 
from now on not participate in any discussion involving releasing on a CI 
server.

A correct Maven release would use (There will be some additional profiles to 
activate to include all modules)

1) the "mvn release:branch" call in order to create the branch and bump the 
version of develop to the next version.
2) the "mvn release:prepare" to change the pom to the release version, set the 
timestamp in the pom (for reproducible builds) build ... if all tests are good, 
commit the changes, tag this commit, update the poms to the next development 
version, commit those changes and push everything.
3) the "mvn release:perform" which will checkout the tagged version build 
everything with the "apache-release" profile turned on (Which causes the 
source.jars, Javadoc.jars, hashes and gpg singatures to be created as well as 
the assembly) This also deploys the built artifacts to Nexus.

Most of that you are already doing on the CI server however you're not letting 
it do all automatically (For lack of credentials)

But ... if you would just be doing those steps on the RM machine.

Chris





Am 26.03.20, 05:54 schrieb "Alex Harui" :



On 3/25/20, 4:46 PM, "Carlos Rovira"  wrote:

> What I want to know is what the Maven commands should be to create a
> release in this "conventional process" you are referring to.
>

If you want to know what's the conventional maven process is, I think I 
can
ask Chris if he wants to work with me on that process, since he already 
did
many other Apache projects, we can expect the process is what is needed 
for
us to. But just expect that will be a series of standard maven commands
(prepare, release,...), so nothing strange at all (I expect).

Do you want us to do that?

Yes.  I want to know what the series of standard Maven commands are.  Then 
we can figure out how to convert them to run on the CI server.

-Alex

Thanks


>
> Maybe someone else can explain better than me.
>
> -Alex
>
> On 3/25/20, 2:22 PM, "Carlos Rovira"  wrote:
>
> Hi Alex,
>
> El mié., 25 mar. 2020 a las 21:26, Alex Harui
> ()
> escribió:
>
> > Carlos,
> >
> > I'm pretty sure that part of the "conventional process" you 
want to
> try
> > requires filling the staging repo from a local machine.
> >
>
> This is what we already did. If you go to [1] will see [2]. That 
was
> the
> upload of compiler to the staging repo. When trying to do the 
same for
> typedefs it failed when trying to fill repo from local machine. I 
think
> Chris or I should not take more time in trying to fix Ant scripts 
that
> are
> failing.
>
> Thanks
>
> [1]
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2F%23stagingRepositoriesdata=02%7C01%7Caharui%40adobe.com%7C821c810ff88f4f3371a608d7d116c8e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207768101866118sdata=qSFTmdvxYB8fK%2FKM5kAd%2Bzslsl0fNxUJi%2BybUIleIUY%3Dreserved=0
> [2]
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimgur.com%2Fa%2Fw4az7pDdata=02%7C01%7Caharui%40adobe.com%7C821c810ff88f4f3371a608d7d116c8e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207768101866118sdata=mOv7%2BFzO764iEkXZgA3DiGEdeRaXQrLp%2Fgq8g%2BOkjt0%3Dreserved=0
>
>
>
>
> >
> > --
> > Carlos Rovira
> >
> 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C821c810ff88f4f3371a608d7d116c8e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207768101866118sdata=96pUSZqS1Sc%2FJ4%2BvUUIFpcKEW4b2DAj2FJjCvc9eW2k%3Dreserved=0
> >
> >
> >
> >
>
>
>

-- 
Carlos Rovira

https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosroviradata=02%7C01%7Caharui%40adobe.com%7C821c810ff88f4f3371a608d7d116c8e0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637207768101866118sdata=96pUSZqS1Sc%2FJ4%2BvUUIFpcKEW4b2DAj2FJjCvc9eW2k%3Dreserved=0

ZipEntry and Reproducible Builds (was Re: Releasing: Finally giving up)

[Alex Harui]

FWIW, the code attributed to me in SWCWriter seems to also include a change 
made two days ago that was not made by me (specifically, the call to 
setTimeZone).  So the original attempt by me did not set a timezone at all.  
The TODO comment was also not written by me.

After doing more digging, I came across a couple of hopefully relevant web 
pages:

https://stackoverflow.com/questions/27675454/zipentry-gettime-unpredictable-results
https://www.baeldung.com/java-daylight-savings

If I understand the first web page correctly, the Zip file does not contain 
some standard like "milliseconds since the epoch", but rather, a unique 
encoding into a long based on just the Year, Month, Day, Hour, Minute, Second.  
No milliseconds or timezone information.

If I understand the second web page correctly, because we are using Java 8, 
when the Zip library converts the "milliseconds since the epoch" we pass in 
into this unique encoding, it might produce the wrong results.  I haven't taken 
the time to research the actual format in the Zip file, but if the encoding 
converts the "milliseconds since the epoch" back into a Date or String and then 
does something like:

Long timestamp = date.year << 28 + date.month << 21 + date.day << 16 + 
date.hour << 12 + date.minutes << 6 + date.seconds;

Then whenever the Java compiler version on the computer creating the SWCs has 
out-of-date information about the whether "daylight savings time (DST)" a.k.a 
"summer time" should be to used to convert the "milliseconds since the epoch" 
back to a Date or String then I think you'll get incorrect results.  There may 
be a way to tell Java 8 to use different DST change dates.  But it may be that 
the original code I put in is as good as we can do in our code.

Of course, I could be wrong...
-Alex


On 3/25/20, 1:39 PM, "Alex Harui"  wrote:

Reproducible builds for Royale is certainly new.  There could be bugs in 
North vs South hemispheres.  Don't know.  Volunteers are welcome to improve 
this portion of our code.

I believe one (maybe the only one) of the challenges is to figure out how 
to choose a timestamp that can be used in the SWCs for at least those needing 
to reproduce the SWCs.  The ZipEntry used in the SWC does not contain a 
timezone so I think there are some challenges to that.

You can try building the SWCs using the timestamps used in the daily builds 
and see if you also see time skews and propose solutions.

-Alex 

On 3/25/20, 1:28 PM, "Greg Dove"  wrote:

 'It could be an issue when the US and Europe have different daylight
savings time settings.  When we saw it work, we were not at one of
those transition points.'

Southern hemisphere and northern hemisphere differences pivot by 2 hours
through these transition gaps, which are typically 2 weeks or 1 week 
when
the application or non-application of DST is aligned between the two
countries being compared.
For the majority of the year DST is not aligned. The end of each 
transition
results in things being 2 hours different from whatever was 'normal'
before.

If the nature of this problem is as-described, which seems to require 
DST
alignment, does that mean the timestamp issues might be present most of 
the
time for someone south of the equator and perhaps only work in the
'transitions' when DST 'settings' are briefly aligned?
So far, I know this hasn't been a problem, with Royale having had no RM
from southern climes, iirc. So I'm just asking mainly to clarify my
understanding of the problem itself. If the answer is "I'm not sure, 
try it
and see" I am not at that point yet :)

If, however, there is something specific that I can investigate about
timestamp issues, I am happy to try.


On Thu, Mar 26, 2020 at 7:23 AM Alex Harui  
wrote:

> That has nothing to do with the Ant build of release artifacts.  That 
is
> just using Ant to run command line commands to download and verify 
Maven
> release artifacts.  I'm pretty sure you can just look at the steps 
and type
> them in manually at the command line and you'll get the same results.
>
> AFAICT, the problem is that the reproducible binaries generated by 
Maven
> aren't reproducible.It could be an issue when the US and Europe 
have
> different daylight savings time settings.  When we saw it work, we 
were not
> at one of those transition points.  So maybe it is best to just wait 
until
> Sunday.  But it did work for me in the US and Piotr in EU.
>
> Proposals for better ways to have an RM verify artifacts built on a 
remote
> machine are welcome.  Testing reproducible binaries was the only way I
> could think of and implement.
>
>