RE: [EXTERNAL] Re: Clear the cache strategy

[Brian Raymes]

If you use Maven, you can the maven-replacer-plugin to automate the 
version/timestamp/build/etc for every build. One could also filter out things 
such unwanted files like .DS_Store with other plugins.

For instance:
 . . .
 ${maven.build.timestamp}
 . . .
  

  
com.google.code.maven-replacer-plugin
replacer
${google.replacer.version}

  
prepare-package

  replace

  


  false
  ${compiler.output-dir}/index.html
  

  

  
  

  


  

  
  

  

  

  
 . . .

Brian

-Original Message-
From: Hugo Ferreira  
Sent: Thursday, March 9, 2023 4:30 PM
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Clear the cache strategy

I found this VS Code extension:
https://marketplace.visualstudio.com/items?itemName=adrianwilczynski.terminal-commands
With this I'm writing a script, so then after build-release, right-click on the 
release folder to clean files and inject the version.

Hugo Ferreira  escreveu no dia sexta, 10/03/2023
à(s) 00:05:

> Thank you all.
> You all gave me greate ideas.
> Josh, no need to spend time on this.
> I will create my own script (remove the .DS files is also a good idea 
> - I hate the mac pollute all my folders with that).
>
> Harbs  escreveu no dia quinta, 9/03/2023 à(s)
> 21:56:
>
>> Yes. My script also has some "aws s3 sync", "aws s3 cp” and "aws 
>> cloudfront create-invalidation” commands to upload the app after 
>> updating the version info.
>>
>> The sync commands (for the whole release directory has these arguments:
>>
>>  --exclude "*.DS_Store*" --delete --cache-control max-age=2592000 
>> --acl public-read
>>
>> The cp command for the index.html file has these arguments:
>>
>>  --metadata-directive REPLACE --cache-control max-age=60,public 
>> --content-type text/html --acl public-read
>>
>>
>> > On Mar 9, 2023, at 11:42 PM, Hugo Ferreira 
>> wrote:
>> >
>> > Thank you.
>> >
>> > OK, after you build-release you run a script that does exactly that.
>> >
>> > Harbs  escreveu no dia quinta, 9/03/2023 
>> > à(s)
>> 21:37:
>> >
>> >> I have a bash script to stage my app that looks like this:
>> >>
>> >> version=$(cat $DIR/releases.json | jq '.version') 
>> >> version="${version%\"}"
>> >> version="${version#\"}"
>> >>
>> >> build=$(node -e 'console.log(Date.now())') jq '.build = '$build 
>> >> releases.json > tmp.$$.json && mv tmp.$$.json releases.json
>> >>
>> >> sed -ie "s/MyApp.js/MyApp.js?{build_number}/g"
>> bin/js-release/index.html
>> >> sed -ie "s/{build_number}/$build/g" bin/js-release/index.html sed 
>> >> -ie "s/{version_number}/$version/g" bin/js-release/index.html
>> >>
>> >> releases.json has the version and the build number is updated by 
>> >> this script.
>> >>
>> >> The template html has this:
>> >>
>> >>
>> >>
>> >>> >> href="${application}.css?{build_number}">
>> >>
>> >> The HTML file on the server has a very short TTL. The rest of the 
>> >> files have a much longer TTL. The build script busts the cache 
>> >> when it’s
>> deployed.
>> >>
>> >> Change “MyApp” to the name of your app.
>> >>
>> >> HTH,
>> >> Harbs
>> >>
>> >>
>> >>> On Mar 9, 2023, at 10:43 PM, Hugo Ferreira 
>> >>> 
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I'm releasing now updates more often and sometimes (many times), 
>> >>> the browser cache my App.js In a quick google search I found a 
>> >>> solution (more a workaround) =>
>> >>>
>> >>
>> https://stackoverflow.com/questions/1011605/clear-the-cache-in-javasc
>> ript
>> >>> When I build - release with VS Code, it inject this line on my 
>> >>> html file: 
>> >>> So, I don't have control over it.
>> >>>
>> >>> What I would like to do is something like have a version flag of 
>> >>> my
>> App
>> >> in
>> >>> the asconfig.json and when I build - relase the compiler inject
>> something
>> >>> like: 
>> >>>  ...
>> >>>
>> >>> This is possible today ?
>> >>>
>> >>> Regards,
>> >>> Hugo.
>> >>
>> >>
>>
>>

RE: [EXTERNAL] Binding inside the html property has stopped working

[Brian Raymes]

I don't believe bindings work within CDATA blocks?

This should work:




Brian

-Original Message-
From: Maria Jose Esteve  
Sent: Monday, February 13, 2023 10:33 AM
To: dev@royale.apache.org
Subject: [EXTERNAL] Binding inside the html property has stopped working

Greetings to all,
After a couple of months of unemployment, I have been able to resume the Royale 
project and I have encountered a problem in my itemRenderers: The bindings 
included in the html property of a Label control are displayed as is, not 
replaced by the expected binded value. [1]

The code:

  



Or

  



[1] 
https://drive.google.com/file/d/1WNm_hi2HtU71JaVWGNQgbtr4ukSsbulD/view?usp=share_link

I have identified the source of the problem in Josh's December 7, 2022 commits:

MXMLTreeBuilder: fix CData handling with [CollapseWhiteSpace] metadata (closes 
#213) Josh Tynjala joshtynj...@apache.org 
d50913c14b5b998a82a14e6c14592ad24995e3e2 07/12/2022 23:18:34
MXMLDataBindingParser: use constant instead of literal Josh Tynjala 
joshtynj...@apache.org 
1c3acfe9767359e35fd6fe0607d22be0946243db 07/12/2022 21:39:55
MXMLDataBindingParser: fix data binding being incorrectly detected inside CData 
text (references #213) Josh Tynjala 
joshtynj...@apache.org 
e570d87f621837b2dc9e6eafa4de9a79f89600fb 07/12/2022 19:00:22
MXMLRoyaleEmitter: remove dead code that was causing a null exception (closes 
#216) Josh Tynjala joshtynj...@apache.org 
053ea997fcaa1d15b2b3efe77de7ffc10bdb13b5 07/12/2022 18:05:55

@Josh, can this be fixed or do I have to implement it some other way?
Thx.
Hiedra

RE: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

[Brian Raymes]

Updated and working well so far. Thank you Greg. 

-Original Message-
From: Greg Dove  
Sent: Monday, April 18, 2022 8:31 PM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

I pushed some updates for events a couple of hours back. Hopefully that fixes 
things. Please let me know if you still see issues.
We should also now see a warning log in the browser console if there are 
additional problematic event classes encountered (i.e. for events that are
re-dispatched) that do not implement the royale approach for event cloning.
This is only in js-debug builds.




On Tue, Apr 19, 2022 at 8:50 AM Brian Raymes 
wrote:

> You are welcome, and thank you; a vacation sure does sound nice!
>
> -Original Message-
> From: Greg Dove 
> Sent: Monday, April 18, 2022 1:26 PM
> To: Apache Royale Development 
> Subject: Re: [EXTERNAL] Re: Problem with Release 0.9.9 and 
> 0.9.10-SNAPSHOT
>
> Sorry Brian, the only delay has been my available time. I am focusing 
> today on catching up on Royale work, after a local 4-day public 
> holiday weekend, which I actually took as a break from work (I do 
> often work through them and was originally intending to get this done 
> during that 'break', but circumstances changed).
>
> Thanks for the offer, however you will see that these changes are not 
> complicated, and I have already done most of the work for that, and 
> will get this in within the next 12 hours.
>
>
> Greg
>
>
> On Tue, 19 Apr 2022, 5:14 am Brian Raymes, 
> wrote:
>
> > Hi Greg,
> >
> > Is there a way I can assist you with these changes? Can you provide 
> > an example of what needs to be updated?
> >
> >
> > Brian
> >
> > -Original Message-
> > From: Greg Dove 
> > Sent: Monday, April 11, 2022 11:19 PM
> > To: Apache Royale Development 
> > Subject: Re: [EXTERNAL] Re: Problem with Release 0.9.9 and 
> > 0.9.10-SNAPSHOT
> >
> > Sorry, free time is challenging right now, I didn't get this in yet, 
> > I will find some time at the end of my day tomorrow
> >
> > On Mon, Apr 11, 2022 at 6:41 PM Greg Dove  wrote:
> >
> > >
> > > Yeah, that would be a symptom of this (getting just a plain Event) 
> > > Looks like there are a whole bunch of event classes that were 
> > > missing the JS cloning support, although flash was being supported.
> > > I plan to push a change tomorrow.
> > >
> > >
> > >
> > >
> > > On Fri, Apr 8, 2022 at 7:14 AM Brian Raymes 
> > > 
> > > wrote:
> > >
> > >> Ah great. I've noticed that the event hitting that method is not 
> > >> actually of type ChannelFaultEvent, but just plain Event.
> > >>
> > >> I've occasionally noticed this behavior while working with Royale 
> > >> these last couple years -- where the expected event type is 
> > >> sometimes plain old Event instead of the actual type declared.
> > >>
> > >> -Original Message-
> > >> From: Greg Dove 
> > >> Sent: Thursday, April 7, 2022 12:00 PM
> > >> To: Apache Royale Development 
> > >> Subject: [EXTERNAL] Re: Problem with Release 0.9.9 and 
> > >> 0.9.10-SNAPSHOT
> > >>
> > >> Brian, I have an idea what it might be. There was a change for 
> > >> event redispatching to align more with the way flash does it 
> > >> natively. It could be incomplete or unimplemented event cloning 
> > >> support. I will look into this over the weekend.
> > >>
> > >> On Fri, 8 Apr 2022, 5:51 am Brian Raymes, 
> > >> 
> > >> wrote:
> > >>
> > >> > Hello all,
> > >> >
> > >> > It appears that something slipped through right before the 
> > >> > 0.9.9 release that breaks MX RemoteObjects/Consumers.
> > >> >
> > >> > I've attempted rolling through and reverting various recent 
> > >> > commits to try to narrow down the problem, but have yet to be 
> > >> > able to find one
> > >> related.
> > >> >
> > >> > To provide context, I've been building on the 0.9.9-SHAPSHOT up 
> > >> > to and in the middle of the latest release. Sometime around 
> > >> > when the release came out, this method, from MessageAgent.as 
> > >> > (MX), now
> fails:
> > >> >
> > >> > public function
> channelFaultHandler(event:ChannelFaultEv

RE: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

[Brian Raymes]

You are welcome, and thank you; a vacation sure does sound nice!

-Original Message-
From: Greg Dove  
Sent: Monday, April 18, 2022 1:26 PM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

Sorry Brian, the only delay has been my available time. I am focusing today on 
catching up on Royale work, after a local 4-day public holiday weekend, which I 
actually took as a break from work (I do often work through them and was 
originally intending to get this done during that 'break', but circumstances 
changed).

Thanks for the offer, however you will see that these changes are not 
complicated, and I have already done most of the work for that, and will get 
this in within the next 12 hours.


Greg


On Tue, 19 Apr 2022, 5:14 am Brian Raymes,  wrote:

> Hi Greg,
>
> Is there a way I can assist you with these changes? Can you provide an 
> example of what needs to be updated?
>
>
> Brian
>
> -Original Message-
> From: Greg Dove 
> Sent: Monday, April 11, 2022 11:19 PM
> To: Apache Royale Development 
> Subject: Re: [EXTERNAL] Re: Problem with Release 0.9.9 and 
> 0.9.10-SNAPSHOT
>
> Sorry, free time is challenging right now, I didn't get this in yet, I 
> will find some time at the end of my day tomorrow
>
> On Mon, Apr 11, 2022 at 6:41 PM Greg Dove  wrote:
>
> >
> > Yeah, that would be a symptom of this (getting just a plain Event) 
> > Looks like there are a whole bunch of event classes that were 
> > missing the JS cloning support, although flash was being supported. 
> > I plan to push a change tomorrow.
> >
> >
> >
> >
> > On Fri, Apr 8, 2022 at 7:14 AM Brian Raymes 
> > 
> > wrote:
> >
> >> Ah great. I've noticed that the event hitting that method is not 
> >> actually of type ChannelFaultEvent, but just plain Event.
> >>
> >> I've occasionally noticed this behavior while working with Royale 
> >> these last couple years -- where the expected event type is 
> >> sometimes plain old Event instead of the actual type declared.
> >>
> >> -Original Message-
> >> From: Greg Dove 
> >> Sent: Thursday, April 7, 2022 12:00 PM
> >> To: Apache Royale Development 
> >> Subject: [EXTERNAL] Re: Problem with Release 0.9.9 and 
> >> 0.9.10-SNAPSHOT
> >>
> >> Brian, I have an idea what it might be. There was a change for 
> >> event redispatching to align more with the way flash does it 
> >> natively. It could be incomplete or unimplemented event cloning 
> >> support. I will look into this over the weekend.
> >>
> >> On Fri, 8 Apr 2022, 5:51 am Brian Raymes, 
> >> 
> >> wrote:
> >>
> >> > Hello all,
> >> >
> >> > It appears that something slipped through right before the 0.9.9 
> >> > release that breaks MX RemoteObjects/Consumers.
> >> >
> >> > I've attempted rolling through and reverting various recent 
> >> > commits to try to narrow down the problem, but have yet to be 
> >> > able to find one
> >> related.
> >> >
> >> > To provide context, I've been building on the 0.9.9-SHAPSHOT up 
> >> > to and in the middle of the latest release. Sometime around when 
> >> > the release came out, this method, from MessageAgent.as (MX), now fails:
> >> >
> >> > public function channelFaultHandler(event:ChannelFaultEvent):void
> >> > {
> >> > if (Log.isWarn())
> >> > _log.warn("'{0}' {1} channel faulted with {2} {3}", 
> >> > id, _agentType, event.faultCode, event.faultDetail);
> >> >
> >> > if (!event.channel.connected) <--<--<--<--<-- HERE
> >> <--<--<--<--<--
> >> > {
> >> > setConnected(false);
> >> > // If we have remoteCredentials we need to send them 
> >> > on reconnect.
> >> > if (_remoteCredentials != null)
> >> > {
> >> > _sendRemoteCredentials = true;
> >> > }
> >> > }
> >> > dispatchEvent(event);
> >> > }
> >> >
> >> > If reverting my project to run off the 0.9.8 release, everything 
> >> > runs as expected. If I were to revert the compiler/framework to 
> >> > sometime before the release, everything worked as expected as well.
> >> >

RE: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

[Brian Raymes]

Hi Greg,

Is there a way I can assist you with these changes? Can you provide an example 
of what needs to be updated?


Brian

-Original Message-
From: Greg Dove  
Sent: Monday, April 11, 2022 11:19 PM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

Sorry, free time is challenging right now, I didn't get this in yet, I will 
find some time at the end of my day tomorrow

On Mon, Apr 11, 2022 at 6:41 PM Greg Dove  wrote:

>
> Yeah, that would be a symptom of this (getting just a plain Event) 
> Looks like there are a whole bunch of event classes that were missing 
> the JS cloning support, although flash was being supported. I plan to 
> push a change tomorrow.
>
>
>
>
> On Fri, Apr 8, 2022 at 7:14 AM Brian Raymes 
> wrote:
>
>> Ah great. I've noticed that the event hitting that method is not 
>> actually of type ChannelFaultEvent, but just plain Event.
>>
>> I've occasionally noticed this behavior while working with Royale 
>> these last couple years -- where the expected event type is sometimes 
>> plain old Event instead of the actual type declared.
>>
>> -Original Message-
>> From: Greg Dove 
>> Sent: Thursday, April 7, 2022 12:00 PM
>> To: Apache Royale Development 
>> Subject: [EXTERNAL] Re: Problem with Release 0.9.9 and 
>> 0.9.10-SNAPSHOT
>>
>> Brian, I have an idea what it might be. There was a change for event 
>> redispatching to align more with the way flash does it natively. It 
>> could be incomplete or unimplemented event cloning support. I will 
>> look into this over the weekend.
>>
>> On Fri, 8 Apr 2022, 5:51 am Brian Raymes, 
>> wrote:
>>
>> > Hello all,
>> >
>> > It appears that something slipped through right before the 0.9.9 
>> > release that breaks MX RemoteObjects/Consumers.
>> >
>> > I've attempted rolling through and reverting various recent commits 
>> > to try to narrow down the problem, but have yet to be able to find 
>> > one
>> related.
>> >
>> > To provide context, I've been building on the 0.9.9-SHAPSHOT up to 
>> > and in the middle of the latest release. Sometime around when the 
>> > release came out, this method, from MessageAgent.as (MX), now fails:
>> >
>> > public function channelFaultHandler(event:ChannelFaultEvent):void
>> > {
>> > if (Log.isWarn())
>> > _log.warn("'{0}' {1} channel faulted with {2} {3}", id, 
>> > _agentType, event.faultCode, event.faultDetail);
>> >
>> > if (!event.channel.connected) <--<--<--<--<-- HERE
>> <--<--<--<--<--
>> > {
>> > setConnected(false);
>> > // If we have remoteCredentials we need to send them on 
>> > reconnect.
>> > if (_remoteCredentials != null)
>> > {
>> > _sendRemoteCredentials = true;
>> > }
>> > }
>> > dispatchEvent(event);
>> > }
>> >
>> > If reverting my project to run off the 0.9.8 release, everything 
>> > runs as expected. If I were to revert the compiler/framework to 
>> > sometime before the release, everything worked as expected as well.
>> >
>> > Exception has occurred: TypeError: Cannot read properties of 
>> > undefined (reading 'connected')
>> >   at 
>> > mx.rpc.AsyncRequest.mx.messaging.MessageAgent.channelFaultHandler
>> > (
>> > http://localhost/mx/messaging/MessageAgent.js:464:22)
>> > at
>> > mx.rpc.AsyncRequest.mx.messaging.AbstractProducer.channelFaultHandl
>> > er
>> > (http://localhost/mx/messaging/AbstractProducer.js:158:65)
>> > at
>> > mx.messaging.ChannelSet.org.apache.royale.events.EventDispatcher.fi
>> > reL
>> > isteners
>> > (http://localhost/org/apache/royale/events/EventDispatcher.js:102:23)
>> > at Function.goog.events.EventTarget.dispatchEventInternal_ (
>> > http://localhost/library/closure/goog/events/eventtarget.js:381:26)
>> > at
>> > mx.messaging.ChannelSet.org.apache.royale.events.EventDispatcher.di
>> > spa
>> > tchEvent
>> > (http://localhost/org/apache/royale/events/EventDispatcher.js7:77:37)
>> > at mx.messaging.ChannelSet.channelFaultHandler (
>> > http://localhost/mx/messaging/ChannelSet.js:618:10)
>> > at
>> > mx.messaging.channels.AMFChannel.org.apache.royale.events.EventDisp
>> > atc
>> > her.fireListeners
>> > (http://localhost/org/apache/royale/events/EventDispatcher.js:102:23)
>> > at Function.goog.events.EventTarget.dispatchEventInternal_ (
>> > http://localhost/library/closure/goog/events/eventtarget.js:381:26)
>> > at
>> > mx.messaging.channels.AMFChannel.org.apache.royale.events.EventDisp
>> > atc
>> > her.dispatchEvent
>> > (http://localhost/org/apache/royale/events/EventDispatcher.js77:37)
>> > at
>> > mx.messaging.channels.PollingChannel.PollCommandMessageResponder.st
>> > atu
>> > sHandler
>> > (http://localhost/mx/messaging/channels/PollingChannel.js:824:18)
>> >
>> >
>> > If there is anything I can provide to further assist, please let me
>> know.
>> >
>> > Thank you.
>> >
>> > Brian
>> >
>> >
>>
>

RE: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

[Brian Raymes]

Not a problem. I mostly just wanted others to be aware that release may be 
unusable for some.

Thank you!

-Original Message-
From: Greg Dove  
Sent: Monday, April 11, 2022 11:19 PM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

Sorry, free time is challenging right now, I didn't get this in yet, I will 
find some time at the end of my day tomorrow

On Mon, Apr 11, 2022 at 6:41 PM Greg Dove  wrote:

>
> Yeah, that would be a symptom of this (getting just a plain Event) 
> Looks like there are a whole bunch of event classes that were missing 
> the JS cloning support, although flash was being supported. I plan to 
> push a change tomorrow.
>
>
>
>
> On Fri, Apr 8, 2022 at 7:14 AM Brian Raymes 
> wrote:
>
>> Ah great. I've noticed that the event hitting that method is not 
>> actually of type ChannelFaultEvent, but just plain Event.
>>
>> I've occasionally noticed this behavior while working with Royale 
>> these last couple years -- where the expected event type is sometimes 
>> plain old Event instead of the actual type declared.
>>
>> -Original Message-
>> From: Greg Dove 
>> Sent: Thursday, April 7, 2022 12:00 PM
>> To: Apache Royale Development 
>> Subject: [EXTERNAL] Re: Problem with Release 0.9.9 and 
>> 0.9.10-SNAPSHOT
>>
>> Brian, I have an idea what it might be. There was a change for event 
>> redispatching to align more with the way flash does it natively. It 
>> could be incomplete or unimplemented event cloning support. I will 
>> look into this over the weekend.
>>
>> On Fri, 8 Apr 2022, 5:51 am Brian Raymes, 
>> wrote:
>>
>> > Hello all,
>> >
>> > It appears that something slipped through right before the 0.9.9 
>> > release that breaks MX RemoteObjects/Consumers.
>> >
>> > I've attempted rolling through and reverting various recent commits 
>> > to try to narrow down the problem, but have yet to be able to find 
>> > one
>> related.
>> >
>> > To provide context, I've been building on the 0.9.9-SHAPSHOT up to 
>> > and in the middle of the latest release. Sometime around when the 
>> > release came out, this method, from MessageAgent.as (MX), now fails:
>> >
>> > public function channelFaultHandler(event:ChannelFaultEvent):void
>> > {
>> > if (Log.isWarn())
>> > _log.warn("'{0}' {1} channel faulted with {2} {3}", id, 
>> > _agentType, event.faultCode, event.faultDetail);
>> >
>> > if (!event.channel.connected) <--<--<--<--<-- HERE
>> <--<--<--<--<--
>> > {
>> > setConnected(false);
>> > // If we have remoteCredentials we need to send them on 
>> > reconnect.
>> > if (_remoteCredentials != null)
>> > {
>> > _sendRemoteCredentials = true;
>> > }
>> > }
>> > dispatchEvent(event);
>> > }
>> >
>> > If reverting my project to run off the 0.9.8 release, everything 
>> > runs as expected. If I were to revert the compiler/framework to 
>> > sometime before the release, everything worked as expected as well.
>> >
>> > Exception has occurred: TypeError: Cannot read properties of 
>> > undefined (reading 'connected')
>> >   at 
>> > mx.rpc.AsyncRequest.mx.messaging.MessageAgent.channelFaultHandler
>> > (
>> > http://localhost/mx/messaging/MessageAgent.js:464:22)
>> > at
>> > mx.rpc.AsyncRequest.mx.messaging.AbstractProducer.channelFaultHandl
>> > er
>> > (http://localhost/mx/messaging/AbstractProducer.js:158:65)
>> > at
>> > mx.messaging.ChannelSet.org.apache.royale.events.EventDispatcher.fi
>> > reL
>> > isteners
>> > (http://localhost/org/apache/royale/events/EventDispatcher.js:102:23)
>> > at Function.goog.events.EventTarget.dispatchEventInternal_ (
>> > http://localhost/library/closure/goog/events/eventtarget.js:381:26)
>> > at
>> > mx.messaging.ChannelSet.org.apache.royale.events.EventDispatcher.di
>> > spa
>> > tchEvent
>> > (http://localhost/org/apache/royale/events/EventDispatcher.js7:77:37)
>> > at mx.messaging.ChannelSet.channelFaultHandler (
>> > http://localhost/mx/messaging/ChannelSet.js:618:10)
>> > at
>> > mx.messaging.channels.AMFChannel.org.apache.royale.events.EventDisp
>> > atc
>> > her.fireListeners
>> > (http://localhost/org/apache/royale/events/EventDispatcher.js:102:23)
>> > at Function.goog.events.EventTarget.dispatchEventInternal_ (
>> > http://localhost/library/closure/goog/events/eventtarget.js:381:26)
>> > at
>> > mx.messaging.channels.AMFChannel.org.apache.royale.events.EventDisp
>> > atc
>> > her.dispatchEvent
>> > (http://localhost/org/apache/royale/events/EventDispatcher.js77:37)
>> > at
>> > mx.messaging.channels.PollingChannel.PollCommandMessageResponder.st
>> > atu
>> > sHandler
>> > (http://localhost/mx/messaging/channels/PollingChannel.js:824:18)
>> >
>> >
>> > If there is anything I can provide to further assist, please let me
>> know.
>> >
>> > Thank you.
>> >
>> > Brian
>> >
>> >
>>
>

RE: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

[Brian Raymes]

Ah great. I've noticed that the event hitting that method is not actually of 
type ChannelFaultEvent, but just plain Event.

I've occasionally noticed this behavior while working with Royale these last 
couple years -- where the expected event type is sometimes plain old Event 
instead of the actual type declared.

-Original Message-
From: Greg Dove  
Sent: Thursday, April 7, 2022 12:00 PM
To: Apache Royale Development 
Subject: [EXTERNAL] Re: Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

Brian, I have an idea what it might be. There was a change for event 
redispatching to align more with the way flash does it natively. It could be 
incomplete or unimplemented event cloning support. I will look into this over 
the weekend.

On Fri, 8 Apr 2022, 5:51 am Brian Raymes,  wrote:

> Hello all,
>
> It appears that something slipped through right before the 0.9.9 
> release that breaks MX RemoteObjects/Consumers.
>
> I've attempted rolling through and reverting various recent commits to 
> try to narrow down the problem, but have yet to be able to find one related.
>
> To provide context, I've been building on the 0.9.9-SHAPSHOT up to and 
> in the middle of the latest release. Sometime around when the release 
> came out, this method, from MessageAgent.as (MX), now fails:
>
> public function channelFaultHandler(event:ChannelFaultEvent):void
> {
> if (Log.isWarn())
> _log.warn("'{0}' {1} channel faulted with {2} {3}", id, 
> _agentType, event.faultCode, event.faultDetail);
>
> if (!event.channel.connected) <--<--<--<--<-- HERE <--<--<--<--<--
> {
> setConnected(false);
> // If we have remoteCredentials we need to send them on 
> reconnect.
> if (_remoteCredentials != null)
> {
> _sendRemoteCredentials = true;
> }
> }
> dispatchEvent(event);
> }
>
> If reverting my project to run off the 0.9.8 release, everything runs 
> as expected. If I were to revert the compiler/framework to sometime 
> before the release, everything worked as expected as well.
>
> Exception has occurred: TypeError: Cannot read properties of undefined 
> (reading 'connected')
>   at mx.rpc.AsyncRequest.mx.messaging.MessageAgent.channelFaultHandler 
> (
> http://localhost/mx/messaging/MessageAgent.js:464:22)
> at 
> mx.rpc.AsyncRequest.mx.messaging.AbstractProducer.channelFaultHandler
> (http://localhost/mx/messaging/AbstractProducer.js:158:65)
> at 
> mx.messaging.ChannelSet.org.apache.royale.events.EventDispatcher.fireL
> isteners
> (http://localhost/org/apache/royale/events/EventDispatcher.js:102:23)
> at Function.goog.events.EventTarget.dispatchEventInternal_ (
> http://localhost/library/closure/goog/events/eventtarget.js:381:26)
> at 
> mx.messaging.ChannelSet.org.apache.royale.events.EventDispatcher.dispa
> tchEvent
> (http://localhost/org/apache/royale/events/EventDispatcher.js7:77:37)
> at mx.messaging.ChannelSet.channelFaultHandler (
> http://localhost/mx/messaging/ChannelSet.js:618:10)
> at
> mx.messaging.channels.AMFChannel.org.apache.royale.events.EventDispatc
> her.fireListeners
> (http://localhost/org/apache/royale/events/EventDispatcher.js:102:23)
> at Function.goog.events.EventTarget.dispatchEventInternal_ (
> http://localhost/library/closure/goog/events/eventtarget.js:381:26)
> at
> mx.messaging.channels.AMFChannel.org.apache.royale.events.EventDispatc
> her.dispatchEvent
> (http://localhost/org/apache/royale/events/EventDispatcher.js77:37)
> at
> mx.messaging.channels.PollingChannel.PollCommandMessageResponder.statu
> sHandler
> (http://localhost/mx/messaging/channels/PollingChannel.js:824:18)
>
>
> If there is anything I can provide to further assist, please let me know.
>
> Thank you.
>
> Brian
>
>

Problem with Release 0.9.9 and 0.9.10-SNAPSHOT

[Brian Raymes]

Hello all,

It appears that something slipped through right before the 0.9.9 release that 
breaks MX RemoteObjects/Consumers.

I've attempted rolling through and reverting various recent commits to try to 
narrow down the problem, but have yet to be able to find one related.

To provide context, I've been building on the 0.9.9-SHAPSHOT up to and in the 
middle of the latest release. Sometime around when the release came out, this 
method, from MessageAgent.as (MX), now fails:

public function channelFaultHandler(event:ChannelFaultEvent):void
{
if (Log.isWarn())
_log.warn("'{0}' {1} channel faulted with {2} {3}", id, _agentType, 
event.faultCode, event.faultDetail);

if (!event.channel.connected) <--<--<--<--<-- HERE <--<--<--<--<--
{
setConnected(false);
// If we have remoteCredentials we need to send them on reconnect.
if (_remoteCredentials != null)
{
_sendRemoteCredentials = true;
}
}
dispatchEvent(event);
}

If reverting my project to run off the 0.9.8 release, everything runs as 
expected. If I were to revert the compiler/framework to sometime before the 
release, everything worked as expected as well.

Exception has occurred: TypeError: Cannot read properties of undefined (reading 
'connected')
  at mx.rpc.AsyncRequest.mx.messaging.MessageAgent.channelFaultHandler 
(http://localhost/mx/messaging/MessageAgent.js:464:22)
at mx.rpc.AsyncRequest.mx.messaging.AbstractProducer.channelFaultHandler 
(http://localhost/mx/messaging/AbstractProducer.js:158:65)
at 
mx.messaging.ChannelSet.org.apache.royale.events.EventDispatcher.fireListeners 
(http://localhost/org/apache/royale/events/EventDispatcher.js:102:23)
at Function.goog.events.EventTarget.dispatchEventInternal_ 
(http://localhost/library/closure/goog/events/eventtarget.js:381:26)
at 
mx.messaging.ChannelSet.org.apache.royale.events.EventDispatcher.dispatchEvent 
(http://localhost/org/apache/royale/events/EventDispatcher.js7:77:37)
at mx.messaging.ChannelSet.channelFaultHandler 
(http://localhost/mx/messaging/ChannelSet.js:618:10)
at 
mx.messaging.channels.AMFChannel.org.apache.royale.events.EventDispatcher.fireListeners
 (http://localhost/org/apache/royale/events/EventDispatcher.js:102:23)
at Function.goog.events.EventTarget.dispatchEventInternal_ 
(http://localhost/library/closure/goog/events/eventtarget.js:381:26)
at 
mx.messaging.channels.AMFChannel.org.apache.royale.events.EventDispatcher.dispatchEvent
 (http://localhost/org/apache/royale/events/EventDispatcher.js77:37)
at 
mx.messaging.channels.PollingChannel.PollCommandMessageResponder.statusHandler 
(http://localhost/mx/messaging/channels/PollingChannel.js:824:18)


If there is anything I can provide to further assist, please let me know.

Thank you.

Brian

RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

[Brian Raymes]

Feel free to disregard the timestamp stuff. That is my attempt at defeating the 
browser caches.

I have this plugin for development:

  
com.google.code.maven-replacer-plugin
replacer
1.5.3

  
package

  replace

  


  false
  ${basedir}/target/javascript/bin/js-debug/index.html
  

  

  
  

  


  

  
  

  


  

  
  

  

  

  

And this setup for release:

  
com.google.code.maven-replacer-plugin
replacer
1.5.3

  
prepare-package

  replace

  


  false
  ${compiler.output-dir}/index.html
  

  

  
  

  


  

  
  

  


  

  
  

  

  

  

-Original Message-
From: Maria Jose Esteve  
Sent: Wednesday, October 20, 2021 1:09 PM
To: dev@royale.apache.org
Subject: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

First I tried it only in this script and then I added it to the body script "to 
test" but it didn't work either.
Can you pass me the text you put in the pom to replace?

-Mensaje original-
De: Brian Raymes  Enviado el: miércoles, 20 de 
octubre de 2021 20:44
Para: dev@royale.apache.org
Asunto: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

I do not see anything wrong with what you just provided. Same as what I have 
been using.

In the previous email, it looks like you may have added it to the "new 
App().start();" as well?


-Original Message-
From: Maria Jose Esteve 
Sent: Wednesday, October 20, 2021 11:19 AM
To: dev@royale.apache.org
Subject: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

Hi,
Yes, I understand the parameters... Well, I must be doing something wrong...
If I assign "manually" the defer ... It doesn't work for me:
...
  
  
// generated by Royale
goog.addDependency('../../../App.js', ['App'], 
['org.apache.royale.community.beads.models
...

See anything wrong?

Thx
Hiedra

-Mensaje original-
De: Brian Raymes <brian.ray...@teotech.com> Enviado el: miércoles, 20 de 
octubre de 2021 19:01
Para: dev@royale.apache.org
Asunto: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

I have only added a single defer, specifically this one (as well as in the 
release version):

  <script type="text/javascript" defer>
// generated by Royale

That should force all other (external, and other) scripts to load first, 
leaving the Royale app as the final load.

When you think about the order of operations, we want external and other 
scripts to load before the Royale script is parsed (before we even ask it to 
start).

Hope that helps.

-Original Message-
From: Maria Jose Esteve <mjest...@iest.com>
Sent: Tuesday, October 19, 2021 4:10 PM
To: dev@royale.apache.org
Subject: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

I had not read... "only for external scripts"…. how do you specify @Brian?

Thx
Hiedra

De: Maria Jose Esteve <mjest...@iest.com> Enviado el: miércoles, 20 de octubre 
de 2021 0:52
Para: dev@royale.apache.org
Asunto: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component


Hello,

I wish I could get to an "end" point with this problem, although it seems it 
won't be today 😝

I've read Harb's article (with some tests, none of them definitive) and I've 
added, manually, the "defer" attribute to the script where the dependencies are 
added and, to test, also to the body script where the App.Start() is launched 
but nothing seems to work for me. (It only works in Firefox, but before 
including "defer" it also worked 98% of the time)

I keep getting errors when running from localhost:


  <script type="text/javascript" src="./library/closure/goog/base.js">
  
// generated by Royale
goog.addDependency('../../../App.js', ['

RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

[Brian Raymes]

I do not see anything wrong with what you just provided. Same as what I have 
been using.

In the previous email, it looks like you may have added it to the "new 
App().start();" as well?


-Original Message-
From: Maria Jose Esteve  
Sent: Wednesday, October 20, 2021 11:19 AM
To: dev@royale.apache.org
Subject: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

Hi,
Yes, I understand the parameters... Well, I must be doing something wrong...
If I assign "manually" the defer ... It doesn't work for me:
...
  
  
// generated by Royale
goog.addDependency('../../../App.js', ['App'], 
['org.apache.royale.community.beads.models
...

See anything wrong?

Thx
Hiedra

-Mensaje original-
De: Brian Raymes <brian.ray...@teotech.com> Enviado el: miércoles, 20 de 
octubre de 2021 19:01
Para: dev@royale.apache.org
Asunto: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

I have only added a single defer, specifically this one (as well as in the 
release version):

  <script type="text/javascript" defer>
// generated by Royale

That should force all other (external, and other) scripts to load first, 
leaving the Royale app as the final load.

When you think about the order of operations, we want external and other 
scripts to load before the Royale script is parsed (before we even ask it to 
start).

Hope that helps.

-Original Message-
From: Maria Jose Esteve <mjest...@iest.com>
Sent: Tuesday, October 19, 2021 4:10 PM
To: dev@royale.apache.org
Subject: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

I had not read... "only for external scripts"…. how do you specify @Brian?

Thx
Hiedra

De: Maria Jose Esteve <mjest...@iest.com> Enviado el: miércoles, 20 de octubre 
de 2021 0:52
Para: dev@royale.apache.org
Asunto: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component


Hello,

I wish I could get to an "end" point with this problem, although it seems it 
won't be today 😝

I've read Harb's article (with some tests, none of them definitive) and I've 
added, manually, the "defer" attribute to the script where the dependencies are 
added and, to test, also to the body script where the App.Start() is launched 
but nothing seems to work for me. (It only works in Firefox, but before 
including "defer" it also worked 98% of the time)

I keep getting errors when running from localhost:


  <script type="text/javascript" src="./library/closure/goog/base.js">
  
// generated by Royale
goog.addDependency('../../../App.js', ['App'], 
['org.apache.royale.community.beads.models


<body>
  <script type="text/javascript" defer>
new App().start();
  




[cid:image001.png@01D7C549.CA63EDB0]



@Brian, could you specify how you have implemented it in the pom?



Thx.



Hiedra.



-Mensaje original-
De: Brian Raymes mailto:brian.ray...@teotech.com>>
Enviado el: martes, 19 de octubre de 2021 23:42
Para: dev@royale.apache.org<mailto:dev@royale.apache.org>
Asunto: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component



What I have done to solve this issue is simply added the "defer" attribute to 
the script block for App.js (using maven-replacer-plugin with maven at package 
time).



https://www.w3schools.com/tags/att_script_defer.asp



"The script is downloaded in parallel to parsing the page, and executed after 
the page has finished parsing"





Brian



-Original Message-

From: Yishay Weiss mailto:yish...@apache.org>>

Sent: Tuesday, October 19, 2021 3:43 AM

To: dev@royale.apache.org<mailto:dev@royale.apache.org>

Subject: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component



> Maybe there is a way to make App.start() wait until all the js are loaded?



FWIW, this has already been discussed [1] extensively. I think the conclusion 
was that in most cases loading order will not be so so important, unless a JS 
lib is called right at the start. The easiest workaround for now I think is to 
time the methods calls carefully, e.g. after a user click.



[1] 
https://lists.apache.org/thread.html/r2f2d8f68936f9bbf061a80a8ff996bc0398e74c6349ad6e28402d4d0%40%3Cdev.royale.apache.org%3E



On 2021/10/19 10:18:03, Maria Jose Esteve 
mailto:mjest...@iest.com>> wrote:

> Exactly, that's what happens to me when I launch against localhost, the js 
> hasn't loaded yet but I don't know how to fix it. I tried monitoring the 
> network and I see it loads but App loads before In theory the scripts 
> inside the "body" shouldn't they run after all the js have loaded?

> I've tried to force it, with a custom loader in js but nothing worked,

> probably because I'm not doing it correct

RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

[Brian Raymes]

I have only added a single defer, specifically this one (as well as in the 
release version):

  
// generated by Royale

That should force all other (external, and other) scripts to load first, 
leaving the Royale app as the final load.

When you think about the order of operations, we want external and other 
scripts to load before the Royale script is parsed (before we even ask it to 
start).

Hope that helps.

-Original Message-
From: Maria Jose Esteve <mjest...@iest.com> 
Sent: Tuesday, October 19, 2021 4:10 PM
To: dev@royale.apache.org
Subject: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

I had not read... "only for external scripts"…. how do you specify @Brian?

Thx
Hiedra

De: Maria Jose Esteve <mjest...@iest.com> Enviado el: miércoles, 20 de octubre 
de 2021 0:52
Para: dev@royale.apache.org
Asunto: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component


Hello,

I wish I could get to an "end" point with this problem, although it seems it 
won't be today 😝

I've read Harb's article (with some tests, none of them definitive) and I've 
added, manually, the "defer" attribute to the script where the dependencies are 
added and, to test, also to the body script where the App.Start() is launched 
but nothing seems to work for me. (It only works in Firefox, but before 
including "defer" it also worked 98% of the time)

I keep getting errors when running from localhost:


  <script type="text/javascript" src="./library/closure/goog/base.js">
  
// generated by Royale
goog.addDependency('../../../App.js', ['App'], 
['org.apache.royale.community.beads.models


<body>
  <script type="text/javascript" defer>
new App().start();
  




[cid:image001.png@01D7C549.CA63EDB0]



@Brian, could you specify how you have implemented it in the pom?



Thx.



Hiedra.



-Mensaje original-
De: Brian Raymes mailto:brian.ray...@teotech.com>>
Enviado el: martes, 19 de octubre de 2021 23:42
Para: dev@royale.apache.org<mailto:dev@royale.apache.org>
Asunto: RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component



What I have done to solve this issue is simply added the "defer" attribute to 
the script block for App.js (using maven-replacer-plugin with maven at package 
time).



https://www.w3schools.com/tags/att_script_defer.asp



"The script is downloaded in parallel to parsing the page, and executed after 
the page has finished parsing"





Brian



-Original Message-

From: Yishay Weiss mailto:yish...@apache.org>>

Sent: Tuesday, October 19, 2021 3:43 AM

To: dev@royale.apache.org<mailto:dev@royale.apache.org>

Subject: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component



> Maybe there is a way to make App.start() wait until all the js are loaded?



FWIW, this has already been discussed [1] extensively. I think the conclusion 
was that in most cases loading order will not be so so important, unless a JS 
lib is called right at the start. The easiest workaround for now I think is to 
time the methods calls carefully, e.g. after a user click.



[1] 
https://lists.apache.org/thread.html/r2f2d8f68936f9bbf061a80a8ff996bc0398e74c6349ad6e28402d4d0%40%3Cdev.royale.apache.org%3E



On 2021/10/19 10:18:03, Maria Jose Esteve 
mailto:mjest...@iest.com>> wrote:

> Exactly, that's what happens to me when I launch against localhost, the js 
> hasn't loaded yet but I don't know how to fix it. I tried monitoring the 
> network and I see it loads but App loads before In theory the scripts 
> inside the "body" shouldn't they run after all the js have loaded?

> I've tried to force it, with a custom loader in js but nothing worked,

> probably because I'm not doing it correctly :( Maybe there is a way to make 
> App.start() wait until all the js are loaded?

>

> Hiedra

>

> -Mensaje original-

> De: Yishay Weiss 
> mailto:yishayj...@hotmail.com>> Enviado el: 
> martes, 19 de

> octubre de 2021 12:05

> Para: dev@royale.apache.org<mailto:dev@royale.apache.org>

> Asunto: RE: Strangled with a new Royale wrapper component

>

> *method later

>

> From: Yishay Weiss<mailto:yishayj...@hotmail.com>

> Sent: Tuesday, October 19, 2021 1:04 PM

> To: 
> dev@royale.apache.org<mailto:dev@royale.apache.org<mailto:dev@royale.a
> pache.org%3cmailto:dev@royale.apache.org>>

> Subject: RE: Strangled with a new Royale wrapper component

>

> Are you sure "resources/office/office.js" is being loaded in time? IIRC you 
> can look in the html elements panel and look for the 

RE: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

[Brian Raymes]

What I have done to solve this issue is simply added the "defer" attribute to 
the script block for App.js (using maven-replacer-plugin with maven at package 
time).

https://www.w3schools.com/tags/att_script_defer.asp

"The script is downloaded in parallel to parsing the page, and executed after 
the page has finished parsing"


Brian

-Original Message-
From: Yishay Weiss  
Sent: Tuesday, October 19, 2021 3:43 AM
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: RE: Strangled with a new Royale wrapper component

> Maybe there is a way to make App.start() wait until all the js are loaded?

FWIW, this has already been discussed [1] extensively. I think the conclusion 
was that in most cases loading order will not be so so important, unless a JS 
lib is called right at the start. The easiest workaround for now I think is to 
time the methods calls carefully, e.g. after a user click.

[1] 
https://lists.apache.org/thread.html/r2f2d8f68936f9bbf061a80a8ff996bc0398e74c6349ad6e28402d4d0%40%3Cdev.royale.apache.org%3E

On 2021/10/19 10:18:03, Maria Jose Esteve  wrote: 
> Exactly, that's what happens to me when I launch against localhost, the js 
> hasn't loaded yet but I don't know how to fix it. I tried monitoring the 
> network and I see it loads but App loads before In theory the scripts 
> inside the "body" shouldn't they run after all the js have loaded?
> I've tried to force it, with a custom loader in js but nothing worked, 
> probably because I'm not doing it correctly :( Maybe there is a way to make 
> App.start() wait until all the js are loaded?
> 
> Hiedra
> 
> -Mensaje original-
> De: Yishay Weiss  Enviado el: martes, 19 de 
> octubre de 2021 12:05
> Para: dev@royale.apache.org
> Asunto: RE: Strangled with a new Royale wrapper component
> 
> *method later
> 
> From: Yishay Weiss
> Sent: Tuesday, October 19, 2021 1:04 PM
> To: dev@royale.apache.org
> Subject: RE: Strangled with a new Royale wrapper component
> 
> Are you sure "resources/office/office.js" is being loaded in time? IIRC you 
> can look in the html elements panel and look for the 

Crux Not Cleaning Up EventHandlers Upon Tear Down?

[Brian Raymes]

Hi all,

I have a puzzling situation. I am dynamically adding crux views that contain 
reusable components that contain EventHandler tags. When I remove said 
component and add another, the previous instance of the Crux EventHandler is 
not removed. Instead, another is added.

Destroying that view by tearing down the bean does not seem to remove the 
EventHandler that was previously associated. Instead, the new view adds 
another, then subsequent dispatched events now invoke the EventHandler twice. 
Destroy and add another, then three times, etc.

Is this expected? Is there away to force the EventHandler to cleanup? Should I 
be using the Prototype class to instantiate single instances? If so, can 
someone point me towards how that can be done on the fly?


Thank you.

Brian

RE: [EXTERNAL] Re: Hudson Nightly build as-js failure

[Brian Raymes]

Is it safe to build the project for maven use at the moment given the 
0.9.8-SNAPSHOT and 0.9.9-SNAPSHOT discrepancies?

My project is linked to 0.9.9-SNAPSHOT given the start of the new release, and 
the compiler and typedefs is still at 0.9.9-SNAPSHOT as well. I know I can 
update my pom to use both, but isn't it a bit weird to leave them out of sync?

Also, shouldn't they not be changed on a whim? Doesn't that impact all 
developers using nightly, which is the suggested path at this point?

Speaking of releases, does anyone know when it can be finished? We're over a 
year past the previous release, and there is a critical as3mxml-vscode update 
my project desperately needs to avoid seeing thousands of errors of duplicate 
getters/setters.


Brian

-Original Message-
From: Josh Tynjala  
Sent: Friday, June 18, 2021 4:40 PM
To: Apache Royale Development 
Subject: [EXTERNAL] Re: Hudson Nightly build as-js failure

I don't claim to be a Maven expert, but I think I understand how the recursion 
is happening.

The main pom.xml has these values:

0.9.8-SNAPSHOT
${project.version}

And the child module distribution/jars/**/pom.xml files had this value (these 
were the only poms in royale-asjs where the version was not concrete, by the 
way):

${project.royale.compiler.version}

The parent's project.version is 0.9.8-SNAPSHOT, but project.version is 
${project.royale.compiler.version} in the child modules.
When 
${project.version}
is interpreted by the child module, it doesn't use the parent's 
project.version. Instead, it uses its own, so it's essentially becoming 
something like this:

${project.royale.compiler.version}

That's definitely recursion.

We didn't have recursion in the past because the parent pom.xml used to have 
this:

0.9.8-SNAPSHOT

My original motivation for changing it to ${project.version} was because 
creating a release branch left project.royale.compiler.version referencing the 
old version, which put the new 0.9.9-SNAPSHOT in a bad state. Now, 
${project.version} is a sensible default that keeps things updated 
automatically, but anyone can also change it to a concrete version locally, if 
they need to do that for any reason (either on the command line or by modifying 
the main pom.xml on their computer).

--
Josh Tynjala
Bowler Hat LLC 


On Fri, Jun 18, 2021 at 11:57 AM Yishay Weiss 
wrote:

> Did you understand why the version was considered to be recursive? I 
> assumed it should be picked up from these lines in the main pom.xml
>
>   0.9.8-SNAPSHOT
> …
>
> ${project.version} mpiler.version>
>
> Also, what was your original motivation for reverting
> b8d136a1644f5de2a14b9185c48637e1089313b4 ?
>
> FWIW, I’m fine with giving concrete version names, just curious.
>
>
> From: Josh Tynjala
> Sent: Friday, June 18, 2021 1:09 AM
> To: Apache Royale Development
> Subject: Re: Hudson Nightly build as-js failure
>
> I was able to reproduce the issue locally, and the changes in commit 
> 87a9c7281458789e511a1178331b24dd71a0dcdd fixed it for me.
>
> Looking back at the history a bit, it seems that I essentially 
> reverted commit b8d136a1644f5de2a14b9185c48637e1089313b4. That commit 
> was perfectly valid at the time, but some recent tweaks to the Maven 
> pom make it a less ideal solution now.
>
> --
> Josh Tynjala
> Bowler Hat LLC 
>
>
> On Thu, Jun 17, 2021 at 9:31 AM Josh Tynjala 
> 
> wrote:
>
> > You're welcome to revert my commits, if you think it will help. 
> > However, I'm not sure that's the correct solution.
> >
> > We're in a weird state right now because royale-compiler and 
> > royale-typedefs are both on 0.9.9-SNAPSHOT, and royale-asjs was just 
> > reverted to 0.9.8-SNAPSHOT. With that in mind, it probably shouldn't 
> > be surprising if builds are failing.
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC 
> >
> >
> > On Thu, Jun 17, 2021 at 5:41 AM Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
> > wrote:
> >
> >> When I run Maven build locally I got errors related to this Josh's
> commit
> >> -> f752231aeb22a82d740dbb410d1d4deac84eb6e5
> >>
> >> I changed both lines from
> >> {project.version}
> >>  to 
> >>  >> >0.9.8-SNAPSHOT - and build 
> >> >started to
> >> running. It's in progress - I will let you know what's the results.
> >>
> >> czw., 17 cze 2021 o 14:18 Piotr Zarzycki 
> >> 
> >> napisał(a):
> >>
> >> > Maybe revert issue and in one of the pom there are Git leftovers.
> >> >
> >> > czw., 17 cze 2021 o 13:45 Yishay Weiss 
> >> > napisał(a):
> >> >
> >> >> We are getting this in log [1]
> >> >>
> >> >>
> >> >> [EnvInject] - Variables injected successfully.
> >> >>
> >> >> No emails were triggered.
> >> >>
> >> >> Parsing POMs
> >> >>
> >> >> SSH: Connecting from host [jenkins-win-he-de-6]
> >> >>
> >> >> SSH: Connecting with configuration [Nightlies] ...
> >> >>
> >> >> SSH: Disconnecting configuration [Nightlies] ...
> >> >>
> >> >>

RE: [EXTERNAL] Re: about releasing 0.9.8

[Brian Raymes]

Great, thanks all for the prompt help. Most appreciated!

Now, if I can only wrap my head around mysterious binding failures, or how to 
debug them, I'd be set.

-Original Message-
From: Josh Tynjala  
Sent: Friday, May 7, 2021 10:17 AM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: about releasing 0.9.8

That is my understanding as well.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Fri, May 7, 2021 at 10:01 AM Alex Harui  wrote:

> IIRC, royale-config.xml does not include the MXRoyale swc but 
> flex-config.xml does.
>
> HTH,
> -Alex
>
> On 5/7/21, 9:30 AM, "Brian Raymes"  wrote:
>
> Okay, that worked. Thank you!
>
> Was this changed somewhat recently? I haven't needed this 
> js-library-path before.
>
> -Original Message-
> From: Josh Tynjala 
> Sent: Friday, May 7, 2021 9:20 AM
> To: Apache Royale Development 
> Subject: Re: [EXTERNAL] Re: about releasing 0.9.8
>
> I think that you need to manually add MXRoyaleJS.swc (and 
> MXRoyale.swc if you are targeting SWF too) to your compiler options in 
> asconfig.json, just like in this example:
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fapache%2Froyale-asjs%2Fblob%2Fdevelop%2Fexamples%2Fmxroyale%2
> FRemoteObjectAMFTest%2Fasconfig.json&data=04%7C01%7Caharui%40adobe
> .com%7C35efef06af86480192d708d911755db6%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C637560018057283451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdat
> a=7n3lX8iIPiag7%2BsSVRno9J1EANwNNwbabv4352E8izw%3D&reserved=0
>
> The MX classes are not included automatically in the default "royale"
> config, and you need to opt into using them.
>
> --
> Josh Tynjala
> Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowl
> erhat.dev%2F&data=04%7C01%7Caharui%40adobe.com%7C35efef06af8648019
> 2d708d911755db6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637560018
> 057283451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DiLQulH8C2HA9AzUp1h4I7
> 0sWF5zKtEUyWRZ6VUplcg%3D&reserved=0
> >
>
>
> On Fri, May 7, 2021 at 9:05 AM Brian Raymes 
> wrote:
>
> > Here is my asconfig.json file. Perhaps I'm missing how this is used.
> I
> > don't use this to compile, but it's necessary for source completion,
> > etc. I would imagine this can even be smaller in the cases where 
> Maven is used?
> >
> > {
> > "config": "royale",
> > "type": "app",
> > "compilerOptions": {
> > "debug": true,
> > "targets": [
> > "JSRoyale"
> > ],
> > "source-map": true,
> > "source-path": [
> > "src/main/royale"
> > ]
> > },
> > "additionalOptions": "-remove-circulars
> > -js-output-optimization=skipAsCoercions
> > -js-dynamic-access-unknown-members=true -js-default-initializers=true
> >
> -keep-as3-metadata+=Inject,Dispatcher,EventHandler,PostConstruct,PreDe
> > -keep-as3-metadata+stroy,ViewAdded,ViewRemoved,Bindable,Transient
> > -keep-code-with-metadata=Inject",
> > "files": [
> > "src/main/royale/App.mxml"
> > ],
> > "mainClass": "App"
> > }
> >
> > -Original Message-
> > From: Josh Tynjala 
> > Sent: Friday, May 7, 2021 8:44 AM
> > To: Apache Royale Development 
> > Subject: Re: [EXTERNAL] Re: about releasing 0.9.8
> >
> > What does your asconfig.json file look like?
> >
> > --
> > Josh Tynjala
> > Bowler Hat LLC <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowl
> erhat.dev%2F&data=04%7C01%7Caharui%40adobe.com%7C35efef06af8648019
> 2d708d911755db6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637560018
> 057283451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DiLQulH8C2HA9AzUp1h4I7
> 0sWF5zKtEUyWRZ6VUplcg%3D&reserved=0
> >
> >
> >
> > On Thu, May 6, 2021 at 6:17 PM Brian Raymes < 
> brian.ray...@teotech.com>
> > wrote:
> >
> > > I c

RE: [EXTERNAL] Re: about releasing 0.9.8

[Brian Raymes]

Okay, that worked. Thank you!

Was this changed somewhat recently? I haven't needed this js-library-path 
before.

-Original Message-
From: Josh Tynjala  
Sent: Friday, May 7, 2021 9:20 AM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: about releasing 0.9.8

I think that you need to manually add MXRoyaleJS.swc (and MXRoyale.swc if you 
are targeting SWF too) to your compiler options in asconfig.json, just like in 
this example:

https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/RemoteObjectAMFTest/asconfig.json

The MX classes are not included automatically in the default "royale"
config, and you need to opt into using them.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Fri, May 7, 2021 at 9:05 AM Brian Raymes 
wrote:

> Here is my asconfig.json file. Perhaps I'm missing how this is used. I 
> don't use this to compile, but it's necessary for source completion, 
> etc. I would imagine this can even be smaller in the cases where Maven is 
> used?
>
> {
> "config": "royale",
> "type": "app",
> "compilerOptions": {
> "debug": true,
> "targets": [
> "JSRoyale"
> ],
> "source-map": true,
> "source-path": [
> "src/main/royale"
> ]
> },
> "additionalOptions": "-remove-circulars 
> -js-output-optimization=skipAsCoercions
> -js-dynamic-access-unknown-members=true -js-default-initializers=true
> -keep-as3-metadata+=Inject,Dispatcher,EventHandler,PostConstruct,PreDe
> -keep-as3-metadata+stroy,ViewAdded,ViewRemoved,Bindable,Transient
> -keep-code-with-metadata=Inject",
> "files": [
> "src/main/royale/App.mxml"
> ],
> "mainClass": "App"
> }
>
> -Original Message-
> From: Josh Tynjala 
> Sent: Friday, May 7, 2021 8:44 AM
> To: Apache Royale Development 
> Subject: Re: [EXTERNAL] Re: about releasing 0.9.8
>
> What does your asconfig.json file look like?
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Thu, May 6, 2021 at 6:17 PM Brian Raymes 
> wrote:
>
> > I can compile just fine with Maven, , and have never needed to do 
> > anything like that in the past. It's VSCode that is complaining that 
> > these imports do not exist.
> >
> > Assuming the new royale-sdk I built is missing something? Or my 
> > asconfig may need to be adjusted for the new sdk changes?
> >
> > I followed what Josh explained below, removed 
> > "-DdistributionTargetFolder= (including the path) option" and 
> > replaced my previously built royale-sdk with the one from a fresh build:
> >
> > royale-asjs\distribution\target\apache-royale-0.9.9-SNAPSHOT-bin.zip
> >
> > Simply unzipped the above and replace my previous. After doing so, 
> > all mx imports are reporting as missing (squiggly underlines).
> >
> > -Original Message-
> > From: Greg Dove 
> > Sent: Thursday, May 6, 2021 5:59 PM
> > To: Apache Royale Development 
> > Subject: Re: [EXTERNAL] Re: about releasing 0.9.8
> >
> > I wonder if you mean the automatic imports
> >
> > with maven I often have something like this:
> >
> > -compiler.mxml.imports=
> > mx.resources.ResourceManager,
> > org.apache.royale.events.Event,
> > org.apache.royale.events.EventDispatcher,
> > org.apache.royale.events.IEventDispatcher,
> > mx.events.MouseEvent,
> > mx.events.FocusEvent,
> > mx.events.KeyboardEvent,
> > org.apache.royale.geom.*,
> > org.apache.royale.core.ClassFactory,
> > org.apache.royale.core.IFactory;
> >
> > In the  nested section of the royale 
> > compiler  tag
> >
> > Is it more that, do you think, or more that you are actually missing 
> > the MXRoyale dependency?
> >
> >
> > On Fri, May 7, 2021 at 12:49 PM Brian Raymes 
> > 
> > wrote:
> >
> > > I should have mentioned, I use Maven to compile.
> > >
> > > -Original Message-
> > > From: Brian Raymes 
> > > Sent: Thursday, May 6, 2021 5:32 PM
> > > To: dev@royale.apache.org
> > > Subject: RE: [EXTERNAL] Re: about releasing 0.9.8
> > >
> > > Hi Josh,
> > >
> > > I've done what you've said, and I can now build successfully, 
> > > thank
> you.
> &g

RE: [EXTERNAL] about releasing 0.9.8

[Brian Raymes]

I do not have "as3mxml.sdk.editor" set, but I do have "as3mxml.sdk.framework" 
set in my vscode workspace.

-Original Message-
From: Harbs  
Sent: Thursday, May 6, 2021 10:08 PM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] about releasing 0.9.8

> It's VSCode that is complaining that these imports do not exist.

Do you have as3mxml.sdk.editor set in your settings?

> On May 7, 2021, at 4:17 AM, Brian Raymes  wrote:
> 
> I can compile just fine with Maven, , and have never needed to do anything 
> like that in the past. It's VSCode that is complaining that these imports do 
> not exist.
> 
> Assuming the new royale-sdk I built is missing something? Or my asconfig may 
> need to be adjusted for the new sdk changes?
> 
> I followed what Josh explained below, removed "-DdistributionTargetFolder= 
> (including the path) option" and replaced my previously built royale-sdk with 
> the one from a fresh build:
> 
> royale-asjs\distribution\target\apache-royale-0.9.9-SNAPSHOT-bin.zip
> 
> Simply unzipped the above and replace my previous. After doing so, all mx 
> imports are reporting as missing (squiggly underlines).
> 
> -Original Message-
> From: Greg Dove 
> Sent: Thursday, May 6, 2021 5:59 PM
> To: Apache Royale Development 
> Subject: Re: [EXTERNAL] Re: about releasing 0.9.8
> 
> I wonder if you mean the automatic imports
> 
> with maven I often have something like this:
> 
> -compiler.mxml.imports=
>mx.resources.ResourceManager,
>org.apache.royale.events.Event,
>org.apache.royale.events.EventDispatcher,
>org.apache.royale.events.IEventDispatcher,
>mx.events.MouseEvent,
>mx.events.FocusEvent,
>mx.events.KeyboardEvent,
>org.apache.royale.geom.*,
>org.apache.royale.core.ClassFactory,
>org.apache.royale.core.IFactory;
> 
> In the  nested section of the royale 
> compiler  tag
> 
> Is it more that, do you think, or more that you are actually missing the 
> MXRoyale dependency?
> 
> 
> On Fri, May 7, 2021 at 12:49 PM Brian Raymes 
> 
> wrote:
> 
>> I should have mentioned, I use Maven to compile.
>> 
>> -Original Message-
>> From: Brian Raymes 
>> Sent: Thursday, May 6, 2021 5:32 PM
>> To: dev@royale.apache.org
>> Subject: RE: [EXTERNAL] Re: about releasing 0.9.8
>> 
>> Hi Josh,
>> 
>> I've done what you've said, and I can now build successfully, thank you.
>> But.. Now, all MX imports cannot be found in my project. I rely 
>> heavily on AMF with my current project, and now my project within 
>> VSCode is showing hundreds of errors, but can compile successfully.
>> 
>> What could I be missing? I compared the previously built SDK with the 
>> new, and they are definitely structured differently. The MX SWCs are 
>> found within the new.
>> 
>> Thoughts?
>> 
>> Brian
>> 
>> -Original Message-
>> From: Josh Tynjala 
>> Sent: Thursday, April 29, 2021 9:11 AM
>> To: Apache Royale Development 
>> Subject: Re: [EXTERNAL] Re: about releasing 0.9.8
>> 
>> Unfortunately, Adobe no longer provides AIR SDK 20.0. The only 
>> version they still offer is AIR 32.0. On macOS, I believe AIR 32.0 is 
>> also only downloadable in a .dmg format that the Maven plugin doesn't 
>> know how to process, which makes things even harder. Older versions 
>> of the macOS AIR SDK used to be available in a different format, like 
>> .tbz2 or .tar.gz or something like that, but Adobe changed to .dmg 
>> only at some point. Anyway, this is why building the distribution is failing.
>> Those who can still build are lucky enough to have it in their cache 
>> from before Adobe removed all of the files from the servers.
>> 
>> But, there's hope! If you build the distribution without specifying a 
>> target folder, it won't try to include Adobe artifacts. It's only 
>> when you build to a folder that the AIR SDK is used in the build process.
>> When you don't specify a target folder, the distribution will go into 
>> a zip or tar.gz file instead. When the build completes, you can just 
>> extract that into a folder, and it's basically the same thing. If you 
>> need playerglobal.swc and the AIR SDK, you can merge them manually 
>> (like we used to do with the Adobe Flex SDK before the Apache installer).
>> 
>> Basically, in your distribution build command, just remove the 
>> -DdistributionTargetFolder= (including the path) option, and it 
>> should work 

RE: [EXTERNAL] Re: about releasing 0.9.8

[Brian Raymes]

Here is my asconfig.json file. Perhaps I'm missing how this is used. I don't 
use this to compile, but it's necessary for source completion, etc. I would 
imagine this can even be smaller in the cases where Maven is used?

{
"config": "royale",
"type": "app",
"compilerOptions": {
"debug": true,
"targets": [
"JSRoyale"
],
"source-map": true,
"source-path": [
"src/main/royale"
]
},
"additionalOptions": "-remove-circulars 
-js-output-optimization=skipAsCoercions -js-dynamic-access-unknown-members=true 
-js-default-initializers=true 
-keep-as3-metadata+=Inject,Dispatcher,EventHandler,PostConstruct,PreDestroy,ViewAdded,ViewRemoved,Bindable,Transient
 -keep-code-with-metadata=Inject",
"files": [
"src/main/royale/App.mxml"
],
"mainClass": "App"
}

-Original Message-
From: Josh Tynjala  
Sent: Friday, May 7, 2021 8:44 AM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: about releasing 0.9.8

What does your asconfig.json file look like?

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Thu, May 6, 2021 at 6:17 PM Brian Raymes 
wrote:

> I can compile just fine with Maven, , and have never needed to do 
> anything like that in the past. It's VSCode that is complaining that 
> these imports do not exist.
>
> Assuming the new royale-sdk I built is missing something? Or my 
> asconfig may need to be adjusted for the new sdk changes?
>
> I followed what Josh explained below, removed 
> "-DdistributionTargetFolder= (including the path) option" and replaced 
> my previously built royale-sdk with the one from a fresh build:
>
> royale-asjs\distribution\target\apache-royale-0.9.9-SNAPSHOT-bin.zip
>
> Simply unzipped the above and replace my previous. After doing so, all 
> mx imports are reporting as missing (squiggly underlines).
>
> -Original Message-
> From: Greg Dove 
> Sent: Thursday, May 6, 2021 5:59 PM
> To: Apache Royale Development 
> Subject: Re: [EXTERNAL] Re: about releasing 0.9.8
>
> I wonder if you mean the automatic imports
>
> with maven I often have something like this:
>
> -compiler.mxml.imports=
> mx.resources.ResourceManager,
> org.apache.royale.events.Event,
> org.apache.royale.events.EventDispatcher,
> org.apache.royale.events.IEventDispatcher,
> mx.events.MouseEvent,
> mx.events.FocusEvent,
> mx.events.KeyboardEvent,
> org.apache.royale.geom.*,
> org.apache.royale.core.ClassFactory,
> org.apache.royale.core.IFactory;
>
> In the  nested section of the royale 
> compiler  tag
>
> Is it more that, do you think, or more that you are actually missing 
> the MXRoyale dependency?
>
>
> On Fri, May 7, 2021 at 12:49 PM Brian Raymes 
> 
> wrote:
>
> > I should have mentioned, I use Maven to compile.
> >
> > -Original Message-
> > From: Brian Raymes 
> > Sent: Thursday, May 6, 2021 5:32 PM
> > To: dev@royale.apache.org
> > Subject: RE: [EXTERNAL] Re: about releasing 0.9.8
> >
> > Hi Josh,
> >
> > I've done what you've said, and I can now build successfully, thank you.
> > But.. Now, all MX imports cannot be found in my project. I rely 
> > heavily on AMF with my current project, and now my project within 
> > VSCode is showing hundreds of errors, but can compile successfully.
> >
> > What could I be missing? I compared the previously built SDK with 
> > the new, and they are definitely structured differently. The MX SWCs 
> > are found within the new.
> >
> > Thoughts?
> >
> > Brian
> >
> > -Original Message-
> > From: Josh Tynjala 
> > Sent: Thursday, April 29, 2021 9:11 AM
> > To: Apache Royale Development 
> > Subject: Re: [EXTERNAL] Re: about releasing 0.9.8
> >
> > Unfortunately, Adobe no longer provides AIR SDK 20.0. The only 
> > version they still offer is AIR 32.0. On macOS, I believe AIR 32.0 
> > is also only downloadable in a .dmg format that the Maven plugin 
> > doesn't know how to process, which makes things even harder. Older 
> > versions of the macOS AIR SDK used to be available in a different 
> > format, like .tbz2 or .tar.gz or something like that, but Adobe 
> > changed to .dmg only at some point. Anyway, this is why building the 
> > distribution is failing.
> > Those who can still build are lucky enough to have i

RE: [EXTERNAL] Re: about releasing 0.9.8

[Brian Raymes]

I can compile just fine with Maven, , and have never needed to do anything like 
that in the past. It's VSCode that is complaining that these imports do not 
exist.

Assuming the new royale-sdk I built is missing something? Or my asconfig may 
need to be adjusted for the new sdk changes?

I followed what Josh explained below, removed "-DdistributionTargetFolder= 
(including the path) option" and replaced my previously built royale-sdk with 
the one from a fresh build:

royale-asjs\distribution\target\apache-royale-0.9.9-SNAPSHOT-bin.zip

Simply unzipped the above and replace my previous. After doing so, all mx 
imports are reporting as missing (squiggly underlines).

-Original Message-
From: Greg Dove  
Sent: Thursday, May 6, 2021 5:59 PM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: about releasing 0.9.8

I wonder if you mean the automatic imports

with maven I often have something like this:

-compiler.mxml.imports=
mx.resources.ResourceManager,
org.apache.royale.events.Event,
org.apache.royale.events.EventDispatcher,
org.apache.royale.events.IEventDispatcher,
mx.events.MouseEvent,
mx.events.FocusEvent,
mx.events.KeyboardEvent,
org.apache.royale.geom.*,
org.apache.royale.core.ClassFactory,
org.apache.royale.core.IFactory;

In the  nested section of the royale compiler 
 tag

Is it more that, do you think, or more that you are actually missing the 
MXRoyale dependency?


On Fri, May 7, 2021 at 12:49 PM Brian Raymes 
wrote:

> I should have mentioned, I use Maven to compile.
>
> -Original Message-----
> From: Brian Raymes 
> Sent: Thursday, May 6, 2021 5:32 PM
> To: dev@royale.apache.org
> Subject: RE: [EXTERNAL] Re: about releasing 0.9.8
>
> Hi Josh,
>
> I've done what you've said, and I can now build successfully, thank you.
> But.. Now, all MX imports cannot be found in my project. I rely 
> heavily on AMF with my current project, and now my project within 
> VSCode is showing hundreds of errors, but can compile successfully.
>
> What could I be missing? I compared the previously built SDK with the 
> new, and they are definitely structured differently. The MX SWCs are 
> found within the new.
>
> Thoughts?
>
> Brian
>
> -Original Message-
> From: Josh Tynjala 
> Sent: Thursday, April 29, 2021 9:11 AM
> To: Apache Royale Development 
> Subject: Re: [EXTERNAL] Re: about releasing 0.9.8
>
> Unfortunately, Adobe no longer provides AIR SDK 20.0. The only version 
> they still offer is AIR 32.0. On macOS, I believe AIR 32.0 is also 
> only downloadable in a .dmg format that the Maven plugin doesn't know 
> how to process, which makes things even harder. Older versions of the 
> macOS AIR SDK used to be available in a different format, like .tbz2 
> or .tar.gz or something like that, but Adobe changed to .dmg only at 
> some point. Anyway, this is why building the distribution is failing. 
> Those who can still build are lucky enough to have it in their cache 
> from before Adobe removed all of the files from the servers.
>
> But, there's hope! If you build the distribution without specifying a 
> target folder, it won't try to include Adobe artifacts. It's only when 
> you build to a folder that the AIR SDK is used in the build process. 
> When you don't specify a target folder, the distribution will go into 
> a zip or tar.gz file instead. When the build completes, you can just 
> extract that into a folder, and it's basically the same thing. If you 
> need playerglobal.swc and the AIR SDK, you can merge them manually 
> (like we used to do with the Adobe Flex SDK before the Apache installer).
>
> Basically, in your distribution build command, just remove the 
> -DdistributionTargetFolder= (including the path) option, and it should 
> work without the AIR SDK. I don't know whether there are other issues 
> on the develop branch that might also cause the Maven distribution 
> build to fail, but this is how you deal with the AIR SDK part at least.
>
> --
> Josh Tynjala
> Bowler Hat LLC <https://bowlerhat.dev>
>
>
> On Wed, Apr 28, 2021 at 6:17 PM Brian Raymes 
> 
> wrote:
>
> > +1 for fixing current state of repo.
> >
> > I haven't been able to successfully build with Maven for quite a 
> > long while now due to what looks to be shifts with this release.
> >
> > For one, it seems to repeat ask to install the AIR SDK, but fails to 
> > notify something, then fails to download as they can't be found. 
> > This happens about 20 times.
> >
> > Example:
> >
> > [INFO]  - Installing Adobe AIR SDK 20.0 Your System-Id: .

RE: [EXTERNAL] Re: about releasing 0.9.8

[Brian Raymes]

I should have mentioned, I use Maven to compile. 

-Original Message-
From: Brian Raymes  
Sent: Thursday, May 6, 2021 5:32 PM
To: dev@royale.apache.org
Subject: RE: [EXTERNAL] Re: about releasing 0.9.8

Hi Josh,

I've done what you've said, and I can now build successfully, thank you. But.. 
Now, all MX imports cannot be found in my project. I rely heavily on AMF with 
my current project, and now my project within VSCode is showing hundreds of 
errors, but can compile successfully.

What could I be missing? I compared the previously built SDK with the new, and 
they are definitely structured differently. The MX SWCs are found within the 
new.

Thoughts?

Brian

-Original Message-
From: Josh Tynjala 
Sent: Thursday, April 29, 2021 9:11 AM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: about releasing 0.9.8

Unfortunately, Adobe no longer provides AIR SDK 20.0. The only version they 
still offer is AIR 32.0. On macOS, I believe AIR 32.0 is also only downloadable 
in a .dmg format that the Maven plugin doesn't know how to process, which makes 
things even harder. Older versions of the macOS AIR SDK used to be available in 
a different format, like .tbz2 or .tar.gz or something like that, but Adobe 
changed to .dmg only at some point. Anyway, this is why building the 
distribution is failing. Those who can still build are lucky enough to have it 
in their cache from before Adobe removed all of the files from the servers.

But, there's hope! If you build the distribution without specifying a target 
folder, it won't try to include Adobe artifacts. It's only when you build to a 
folder that the AIR SDK is used in the build process. When you don't specify a 
target folder, the distribution will go into a zip or tar.gz file instead. When 
the build completes, you can just extract that into a folder, and it's 
basically the same thing. If you need playerglobal.swc and the AIR SDK, you can 
merge them manually (like we used to do with the Adobe Flex SDK before the 
Apache installer).

Basically, in your distribution build command, just remove the 
-DdistributionTargetFolder= (including the path) option, and it should work 
without the AIR SDK. I don't know whether there are other issues on the develop 
branch that might also cause the Maven distribution build to fail, but this is 
how you deal with the AIR SDK part at least.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Apr 28, 2021 at 6:17 PM Brian Raymes 
wrote:

> +1 for fixing current state of repo.
>
> I haven't been able to successfully build with Maven for quite a long 
> while now due to what looks to be shifts with this release.
>
> For one, it seems to repeat ask to install the AIR SDK, but fails to 
> notify something, then fails to download as they can't be found. This 
> happens about 20 times.
>
> Example:
>
> [INFO]  - Installing Adobe AIR SDK 20.0 Your System-Id: ...
> The Adobe SDK license agreement applies to the Adobe AIR SDK. Do you 
> want to install the Adobe AIR SDK? Adobe AIR SDK License:
> http://www.adobe.com/products/air/sdk-eula.html
> (In a non-interactive build such as a CI server build, alternatively 
> to typing y or yes you can also set a system property containing your 
> system which is interpreted as equivalent to accepting by typing y or yes:
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=...
> )
> Do you accept (Yes/No) ? Yes
> [WARNING] Failed to notify spy
> org.apache.flex.utilities.converter.mavenextension.FlexEventSpy: 
> Caught exception while downloading and converting artifact.
> [INFO] Couldn't find artifact: com.adobe.air:20.0:runtime:pom [INFO] 
> ===
>
> Then, it fails to build the distribution because of a potentially all 
> of these unresolved artifacts for 0.9.9-SNAPSHOT.
>
> -Original Message-
> From: Piotr Zarzycki 
> Sent: Tuesday, April 27, 2021 6:33 AM
> To: Apache Royale Development 
> Subject: [EXTERNAL] Re: about releasing 0.9.8
>
> Hi Yishay,
>
> Where are you with release now ? Build is failing on Maven sight for 
> several days, cause it was switched to 0.9.9. Are you going to make 
> another attempt this week ?
>
> Thanks,
> Piotr
>
> niedz., 21 mar 2021 o 11:00 Harbs  napisał(a):
>
> > I think what I started was reverted.
> >
> > Thanks for picking up the slack for me…
> >
> > Let me know if you need help from me.
> >
> > Harbs
> >
> > > On Mar 21, 2021, at 11:00 AM, Yishay Weiss 
> > > 
> > wrote:
> > >
> > > Hi,
> > >
> > > I'd like to start a release again, maybe Harbs will pick this up 
> > > later
> >

RE: [EXTERNAL] Re: about releasing 0.9.8

[Brian Raymes]

Hi Josh,

I've done what you've said, and I can now build successfully, thank you. But.. 
Now, all MX imports cannot be found in my project. I rely heavily on AMF with 
my current project, and now my project within VSCode is showing hundreds of 
errors, but can compile successfully.

What could I be missing? I compared the previously built SDK with the new, and 
they are definitely structured differently. The MX SWCs are found within the 
new.

Thoughts?

Brian

-Original Message-
From: Josh Tynjala  
Sent: Thursday, April 29, 2021 9:11 AM
To: Apache Royale Development 
Subject: Re: [EXTERNAL] Re: about releasing 0.9.8

Unfortunately, Adobe no longer provides AIR SDK 20.0. The only version they 
still offer is AIR 32.0. On macOS, I believe AIR 32.0 is also only downloadable 
in a .dmg format that the Maven plugin doesn't know how to process, which makes 
things even harder. Older versions of the macOS AIR SDK used to be available in 
a different format, like .tbz2 or .tar.gz or something like that, but Adobe 
changed to .dmg only at some point. Anyway, this is why building the 
distribution is failing. Those who can still build are lucky enough to have it 
in their cache from before Adobe removed all of the files from the servers.

But, there's hope! If you build the distribution without specifying a target 
folder, it won't try to include Adobe artifacts. It's only when you build to a 
folder that the AIR SDK is used in the build process. When you don't specify a 
target folder, the distribution will go into a zip or tar.gz file instead. When 
the build completes, you can just extract that into a folder, and it's 
basically the same thing. If you need playerglobal.swc and the AIR SDK, you can 
merge them manually (like we used to do with the Adobe Flex SDK before the 
Apache installer).

Basically, in your distribution build command, just remove the 
-DdistributionTargetFolder= (including the path) option, and it should work 
without the AIR SDK. I don't know whether there are other issues on the develop 
branch that might also cause the Maven distribution build to fail, but this is 
how you deal with the AIR SDK part at least.

--
Josh Tynjala
Bowler Hat LLC <https://bowlerhat.dev>


On Wed, Apr 28, 2021 at 6:17 PM Brian Raymes 
wrote:

> +1 for fixing current state of repo.
>
> I haven't been able to successfully build with Maven for quite a long 
> while now due to what looks to be shifts with this release.
>
> For one, it seems to repeat ask to install the AIR SDK, but fails to 
> notify something, then fails to download as they can't be found. This 
> happens about 20 times.
>
> Example:
>
> [INFO]  - Installing Adobe AIR SDK 20.0 Your System-Id: ...
> The Adobe SDK license agreement applies to the Adobe AIR SDK. Do you 
> want to install the Adobe AIR SDK? Adobe AIR SDK License:
> http://www.adobe.com/products/air/sdk-eula.html
> (In a non-interactive build such as a CI server build, alternatively 
> to typing y or yes you can also set a system property containing your 
> system which is interpreted as equivalent to accepting by typing y or yes:
> -Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=...
> )
> Do you accept (Yes/No) ? Yes
> [WARNING] Failed to notify spy
> org.apache.flex.utilities.converter.mavenextension.FlexEventSpy: 
> Caught exception while downloading and converting artifact.
> [INFO] Couldn't find artifact: com.adobe.air:20.0:runtime:pom [INFO] 
> ===
>
> Then, it fails to build the distribution because of a potentially all 
> of these unresolved artifacts for 0.9.9-SNAPSHOT.
>
> -Original Message-
> From: Piotr Zarzycki 
> Sent: Tuesday, April 27, 2021 6:33 AM
> To: Apache Royale Development 
> Subject: [EXTERNAL] Re: about releasing 0.9.8
>
> Hi Yishay,
>
> Where are you with release now ? Build is failing on Maven sight for 
> several days, cause it was switched to 0.9.9. Are you going to make 
> another attempt this week ?
>
> Thanks,
> Piotr
>
> niedz., 21 mar 2021 o 11:00 Harbs  napisał(a):
>
> > I think what I started was reverted.
> >
> > Thanks for picking up the slack for me…
> >
> > Let me know if you need help from me.
> >
> > Harbs
> >
> > > On Mar 21, 2021, at 11:00 AM, Yishay Weiss 
> > > 
> > wrote:
> > >
> > > Hi,
> > >
> > > I'd like to start a release again, maybe Harbs will pick this up 
> > > later
> > when he's less loaded, so if anyone wants to update the release 
> > notes this might be a good time.
> > >
> > > I'd like to start afresh, so Harbs, let me know if there are RCs 
>

RE: [EXTERNAL] Re: about releasing 0.9.8

[Brian Raymes]

+1 for fixing current state of repo.

I haven't been able to successfully build with Maven for quite a long while now 
due to what looks to be shifts with this release.

For one, it seems to repeat ask to install the AIR SDK, but fails to notify 
something, then fails to download as they can't be found. This happens about 20 
times.

Example:

[INFO]  - Installing Adobe AIR SDK 20.0
Your System-Id: ...
The Adobe SDK license agreement applies to the Adobe AIR SDK. Do you want to 
install the Adobe AIR SDK? Adobe AIR SDK License: 
http://www.adobe.com/products/air/sdk-eula.html
(In a non-interactive build such as a CI server build, alternatively to typing 
y or yes you can also set a system property containing your system which is 
interpreted as equivalent to accepting by typing y or yes: 
-Dcom.adobe.systemIdsForWhichTheTermsOfTheAdobeLicenseAgreementAreAccepted=...
 )
Do you accept (Yes/No) ? Yes
[WARNING] Failed to notify spy 
org.apache.flex.utilities.converter.mavenextension.FlexEventSpy: Caught 
exception while downloading and converting artifact.
[INFO] Couldn't find artifact: com.adobe.air:20.0:runtime:pom
[INFO] ===

Then, it fails to build the distribution because of a potentially all of these 
unresolved artifacts for 0.9.9-SNAPSHOT.

-Original Message-
From: Piotr Zarzycki  
Sent: Tuesday, April 27, 2021 6:33 AM
To: Apache Royale Development 
Subject: [EXTERNAL] Re: about releasing 0.9.8

Hi Yishay,

Where are you with release now ? Build is failing on Maven sight for several 
days, cause it was switched to 0.9.9. Are you going to make another attempt 
this week ?

Thanks,
Piotr

niedz., 21 mar 2021 o 11:00 Harbs  napisał(a):

> I think what I started was reverted.
>
> Thanks for picking up the slack for me…
>
> Let me know if you need help from me.
>
> Harbs
>
> > On Mar 21, 2021, at 11:00 AM, Yishay Weiss 
> wrote:
> >
> > Hi,
> >
> > I'd like to start a release again, maybe Harbs will pick this up 
> > later
> when he's less loaded, so if anyone wants to update the release notes 
> this might be a good time.
> >
> > I'd like to start afresh, so Harbs, let me know if there are RCs for
> Royale or for compiler-build-tools that need cancelling.
> >
> > Thanks
> > 
> > From: Carlos Rovira 
> > Sent: Friday, November 20, 2020 3:51 PM
> > To: Apache Royale Development 
> > Subject: Re: about releasing 0.9.8
> >
> > Hi! just finished my list of updates for 0.9.8
> >
> > Others are welcome to add to it for upcoming release! :)
> >
> > El mar., 17 nov. 2020 a las 20:07, Josh Tynjala (<
> joshtynj...@bowlerhat.dev>)
> > escribió:
> >
> >> I just updated the RELEASE_NOTES.md files in both royale-compiler 
> >> and royale-asjs with my changes for the 0.9.8 release. Everyone 
> >> should also
> add
> >> their own changes to these files.
> >>
> >> --
> >> Josh Tynjala
> >> Bowler Hat LLC 
> >>
> >>
> >> On Tue, Nov 17, 2020 at 5:25 AM Carlos Rovira 
> >> 
> >> wrote:
> >>
> >>> Thanks Harbs!
> >>>
> >>> @Andrew I think we should all try to add to the list of new 
> >>> features,
> >> fixes
> >>> and more. If you could prepare different place holders for 
> >>> compiler-typedefs-asjs, we can all try to fill it
> >>>
> >>> thanks
> >>>
> >>> El lun., 16 nov. 2020 a las 19:47, Andrew Wetmore (<
> cottag...@gmail.com
> >>> )
> >>> escribió:
> >>>
>  Is there a list of new features and fixes since 0.9.7? I would 
>  like to
> >>> see
>  if i can at least get good documentation in place about those changes.
> 
>  a
> 
>  On Mon, Nov 16, 2020 at 1:23 PM Harbs  wrote:
> 
> > OK. I’ll start tomorrow.
> >
> > (fingers crossed)
> >
> >> On Nov 16, 2020, at 5:55 PM, Carlos Rovira <
> >> carlosrov...@apache.org>
> > wrote:
> >>
> >> Hi,
> >>
> >> I think the time zone problems Chris warned are now behind us, 
> >> and
> >>> want
> > to
> >> open this thread about releasing 0.9.8. Many months have passed
> >> and I
> > think
> >> we need to push a new release soon, I think before the end of 
> >> the
> >>> year
> > will
> >> be the best for us if possible.
> >>
> >> What do you think? Harbs can we count on you to do the task?
> >>
> >> Thanks in advance
> >>
> >> --
> >> Carlos Rovira
> >> Apache Member & Apache Royale PMC *Apache Software Foundation* 
> >> http://about.me/carlosrovira
> >
> >
> 
>  --
>  Andrew Wetmore
> 
>  http://cottage14.blogspot.com/
> 
> >>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>> Apache Member & Apache Royale PMC
> >>> *Apache Software Foundation*
> >>> http://about.me/carlosrovira
> >>>
> >>
> >
> >
> > --
> > Carlos Rovira
> > Apache Member & Apache Royale PMC
> > *Apache Software Foundation*
> > http://about.me/carlosrovira
>
>

-- 

Piotr Zarzycki

RE: [EXTERNAL] Re: Royale & NPE Behavior

[Brian Raymes]

The null pointer in this case is in the framework, not my code. I am using 
VSCode, pausing on exceptions is enabled, as well as pausing on uncaught 
exceptions.

The problem is, no exception is thrown. No error exists. Rendering just stops 
for whatever component encounters the NP.

To see what I'm talking about, try creating a VirtualList (jewel) without a 
ListPresentationModel. It will not render at all due to the NP. No errors, no 
exceptions.

Perhaps my first email was a bit misleading because I kept using NPE, when 
really it's NPs without the E.

I've noticed this same behavior within my own code. It's as is something is 
catching these and suppressing them.

The following will show my issue:










-Original Message-
From: Yishay Weiss  
Sent: Thursday, March 11, 2021 4:21 AM
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Royale & NPE Behavior

You got:

>Without, the code will throw a null pointer exception resulting in an empty 
>list being displayed.

And you expect:

>Bare minimum, it would be nice to at least see an uncaught exception with the 
>debugger.

Can you explain the difference? If what you need is for the debugger to halt 
execution with a stack trace, then you can switch on 'pause on exceptions' in 
the dev tools. I must be missing something...
____
From: Brian Raymes 
Sent: Wednesday, March 10, 2021 7:16 PM
To: dev@royale.apache.org 
Subject: Royale & NPE Behavior

Hi all,

I've been noticing a problem with Royale that I think is time to bring up with 
the greater audience.

What is the expected behavior when encountering an NPE within a Royale 
application? I've notice that NPEs seem to break the UI with no notice of any 
kind.

For example, I recently started trying out VirtualLists. For quite some time, I 
could not figure out why they would not render any of my data. It turns out, 
Virtual list requires the bead ListPresentationModel with a non-null rowHeight. 
This is due to VirtualListVerticalLayout's layout method assuming the existence 
of an IListPresentationModel. Without, the code will throw a null pointer 
exception resulting in an empty list being displayed.

The problem I want to highlight is that as a developer, without diving through 
the framework code, and ultimately guessing on trying various things 
beforehand, there was no way for me to know that happened. There is no console 
log output stating the error, no uncaught exception for the debugger to catch, 
and no visible reasoning for what is occurring.

Is this the expected behavior, or can this be improved? I've wasted a 
surprising amount of time chasing these issues in the past year while working 
with Royale.

Bare minimum, it would be nice to at least see an uncaught exception with the 
debugger.

Brian

Royale & NPE Behavior

[Brian Raymes]

Hi all,

I've been noticing a problem with Royale that I think is time to bring up with 
the greater audience.

What is the expected behavior when encountering an NPE within a Royale 
application? I've notice that NPEs seem to break the UI with no notice of any 
kind.

For example, I recently started trying out VirtualLists. For quite some time, I 
could not figure out why they would not render any of my data. It turns out, 
Virtual list requires the bead ListPresentationModel with a non-null rowHeight. 
This is due to VirtualListVerticalLayout's layout method assuming the existence 
of an IListPresentationModel. Without, the code will throw a null pointer 
exception resulting in an empty list being displayed.

The problem I want to highlight is that as a developer, without diving through 
the framework code, and ultimately guessing on trying various things 
beforehand, there was no way for me to know that happened. There is no console 
log output stating the error, no uncaught exception for the debugger to catch, 
and no visible reasoning for what is occurring.

Is this the expected behavior, or can this be improved? I've wasted a 
surprising amount of time chasing these issues in the past year while working 
with Royale.

Bare minimum, it would be nice to at least see an uncaught exception with the 
debugger.

Brian

RE: [EXTERNAL] Re: Configuring source maps on Royale with new compiler options

[Brian Raymes]

I'm not sure this is working properly. Here are some observations:

I'm seeing a very strange error with my Royale application Firefox (see 
initially in a release build), and I have no idea how/where it is coming from:

Uncaught TypeError: Error #1034: Type Coercion failed: cannot convert "function 
Function() {
[native code]
}" to Class.

I switched back to debug and noticed the same error with Firefox. When trying 
to click on the console class/line numbers, I see the follow paths for all of 
the files:
 
http://localhost/frameworks/projects/%7B$project.artifactId%7D/org/apache/royale/utils/Language.as

I was able to set " -source-map-source-root=/;", and that seemed to resolve the 
path issue with my project, but the "as" files are not within the debug output. 
FYI, this only seemed to work for debug mode. Attempting to build source-maps 
for my release mode was doing something even stranger.. injecting the full 
absolute path to my project files in the js map file -- making it even less 
usable.

How are we supposed to debug things like this? Do I need to host the framework 
in my webserver and set "-source-map-source-root=/;" 
to make this work?

How can I use "source-map-source-root" for release mode to help identify build 
issues?


Thank you,

Brian



-Original Message-
From: Carlos Rovira  
Sent: Thursday, January 7, 2021 11:12 AM
To: Apache Royale Development 
Subject: [EXTERNAL] Re: Configuring source maps on Royale with new compiler 
options

Hi,

just fyi I added:

-source-map-source-root=/frameworks/projects/{$project.artifactId}/

at frameworks/projects/pom.xml
so now we have setup source maps in all libraries

but while that seems ok, I'm not getting lib debugging as I stated in my last 
email.




El jue, 7 ene 2021 a las 20:07, Carlos Rovira ()
escribió:

> Ok Josh,
>
> so all seems ok, but debug is not working in classes from Jewel lib.
> I see the jewel.swc has the js.map files in the same way I related, so 
> that's ok as you stated.
> I'm setting breakpoints in the same VSCode window for Jewel and TDJ 
> files, but only TDJ files (in the root or subfolders) are making execution 
> stop.
> If I set up a breakpoint in let's say Jewel Button.as, that appears 
> empty on execution and doesn't have effect, while TDJ appears red and works 
> ok.
>
> Do you know  what could be happening?
>
>
>
> El jue, 7 ene 2021 a las 19:57, Josh Tynjala 
> ()
> escribió:
>
>>  The path of the .js.map file is relative to the .js file. Since the 
>> .js.map file is supposed to be in the same folder as the .js file, 
>> that looks correct to me.
>>
>> --
>> Josh Tynjala
>> Bowler Hat LLC 
>>
>>
>> On Thu, Jan 7, 2021 at 10:28 AM Carlos Rovira 
>> 
>> wrote:
>>
>> > Hi Josh,
>> >
>> > I'm trying to debug jewel classes in TDJ and for example
>> AlertController.js
>> > has at the end:
>> >
>> > //# sourceMappingURL=./AlertController.js.map
>> >
>> > It's ok? I expect it to reference the concrete subfolder:
>> > org/apache/royale/jewel/beads/controllers
>> >
>> >
>> >
>> > El jue, 7 ene 2021 a las 18:23, Josh Tynjala (<
>> joshtynj...@bowlerhat.dev>)
>> > escribió:
>> >
>> > > Yes, you're right that +royalelib should not be required for 
>> > > framework libs. I wasn't paying close enough attention to see 
>> > > that you had added
>> > > +royalelib to both Jewel and TDJ.
>> > >
>> > > So, to summarize, you should use source-map-source-root when 
>> > > building framework libs, and you should use +royalelib when 
>> > > building
>> > examples/apps.
>> > > +royalelib is not necessary for framework libs, and
>> > source-map-source-root
>> > > is (generally) not necessary for examples/apps.
>> > >
>> > > --
>> > > Josh Tynjala
>> > > Bowler Hat LLC 
>> > >
>> > >
>> > > On Thu, Jan 7, 2021 at 7:43 AM Carlos Rovira 
>> > > > >
>> > > wrote:
>> > >
>> > > > Hi Josh,
>> > > >
>> > > > I discover right now that I was understanding wrong how all 
>> > > > this
>> works.
>> > > > I thought we needed +royalelib in framework libs, but it's not 
>> > > > the
>> > case.
>> > > > Just need to add +royalelib to a final project, so that can be 
>> > > > left
>> to
>> > > the
>> > > > user.
>> > > >
>> > > > That means that we can add to all libs this:
>> > > >   -source-map-source-root=/frameworks/projects/XXX/target/
>> > > > (Where XXX is the root libraryfolder) -> For this I'll be 
>> > > > adding in
>> a
>> > > > commit soon
>> > > >
>> > > > So, Chris, we don't need anything more to implement, as I 
>> > > > commit the -source-map-source-root line in all framework poms.
>> > > >
>> > > > Another thing is if we should upload all source maps (js.map 
>> > > > files)
>> of
>> > > all
>> > > > framework libs to some r.a.o url (for example /debug), and if 
>> > > > people
>> > can
>> > > > point with +royalelib (i.e: +royalelib=
>> http://royale.apache.org/debug
>> > )
>> > > >
>> > > > What do you think?
>> > > >
>> > > >
>> > > >
>> > > > El mié, 6 ene 20

RE: About the cumbersome random compilation issue

[Brian Raymes]

I want to say I may have seen the behavior once since the changes were made -- 
but I didn't compare the output to see if it was the same binding issue that I 
was seeing.

If I ever see it again, I'll compare and report back. Otherwise, I must be 
lucky 😉

-Original Message-
From: Carlos Rovira  
Sent: Monday, September 7, 2020 1:13 AM
To: Apache Royale Development 
Subject: Re: About the cumbersome random compilation issue

Hi Greg,

thanks for getting back this thread, I had in mind various times, but always 
other things come up and avoid to report.

I'm sorry to say that the problem is not solved 100%, but the issue happens 
much less than before.
I still can get the behaviour from time to time. I think the problem could be 
now much more hard to find and fix.
Did you know the cause so I can know more about it? At first glance, I thought 
we had some java thread problem in the compiler, since having different results 
sometimes is something that can be related to synchronization of thread. Could 
be that the case?. Maybe your solution made the code run more synchronously but 
we still need to add some thread safe code. Since I don't know much more about 
the problem maybe I'm saying nonsense here...

Thanks, anyway, the problem now is seen less times, which is far better from 
what we had 4 months ago :)



El lun., 7 sept. 2020 a las 6:25, Greg Dove ()
escribió:

> Carlos, Brian, I am just curious whether there was an improvement/fix 
> for the original problem from this thread.
> I have fingers crossed that it was fixed with the change I made 
> earlier, but I did not hear anything to confirm that. (I am hopeful 
> that 'no news is good news').
>
> The original problem was these:
> Carlos: 'weird random compilation issue where, from time to time, 
> renderers has no content'
>
> Brian: missing 'prototype._bindings = [...' in the corresponding debug 
> build js output )
>
>
>
>
> On Sat, May 23, 2020 at 10:39 AM Brian Raymes 
> 
> wrote:
>
> > No problem. I'm happy to assist. I'll update and let you know if I 
> > run into any issues.
> >
> > Brian
> >
> > -Original Message-
> > From: Greg Dove 
> > Sent: Friday, May 22, 2020 2:03 PM
> > To: Apache Royale Development 
> > Subject: Re: About the cumbersome random compilation issue
> >
> > Thanks again, I believe it should be fixed now, Brian.
> > I think there was some unnecessary declaration output being written 
> > previously that should not have been - for the generated 'operations'
> > Object of the RemoteObject in this case, but perhaps there could 
> > have
> been
> > other cases where this was happening.
> >
> >
> > On Sat, May 23, 2020 at 7:50 AM Greg Dove  wrote:
> >
> > >
> > > Ok I repro'ed that. Not sure how I missed it at all... unless 
> > > maybe I made some minor changes after my last test of the 
> > > examples. Will figure
> > this out.
> > >
> > >
> > > On Sat, May 23, 2020 at 7:40 AM Greg Dove  wrote:
> > >
> > >> Thanks for letting me know Brian. I had run all the examples 
> > >> locally as part of my testing before pushing the changes, and 
> > >> wasn't seeing any problems so I must have missed something. Will 
> > >> take a look very
> > shortly.
> > >> Usually I wait for the remote builds to run as a final check but 
> > >> I wasn't able to do that this time.
> > >>
> > >>
> > >> On Sat, May 23, 2020 at 6:44 AM Brian Raymes 
> > >> 
> > >> wrote:
> > >>
> > >>> I will keep you updated over the coming weeks if I run into the 
> > >>> same or similar issue.
> > >>>
> > >>> In the meantime,
> > >>> https://github.com/apache/royale-compiler/commit/96b42e5a980c1d9
> > >>> 19d0 c3a620c500f7a0aff2e9d seems to be breaking my ability to 
> > >>> build royale-asjs with examples:
> > >>>
> > >>> Specifically, MXRoyale / RemoteObjectAMFTest errors for the 
> > >>> following reason causing the rest of the build to fail:
> > >>>
> > >>> Executing MXMLC in tool group Royale with args:
> > >>> [-load-config=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObj
> > >>> ectA MFTest/target/compile-app-config.xml,
> > >>> -js-output=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObject
> > >>> AMFT
> > >>> est/target/javascript,
> > >>> -compiler.t

RE: About the cumbersome random compilation issue

[Brian Raymes]

In my case, no news has been great news. At the time, it was happening in 5-10% 
of all builds. It's been great since the change. 

Thanks again for your support!


Brian

-Original Message-
From: Greg Dove  
Sent: Sunday, September 6, 2020 9:25 PM
To: Apache Royale Development 
Subject: Re: About the cumbersome random compilation issue

Carlos, Brian, I am just curious whether there was an improvement/fix for the 
original problem from this thread.
I have fingers crossed that it was fixed with the change I made earlier, but I 
did not hear anything to confirm that. (I am hopeful that 'no news is good 
news').

The original problem was these:
Carlos: 'weird random compilation issue where, from time to time, renderers has 
no content'

Brian: missing 'prototype._bindings = [...' in the corresponding debug build js 
output )




On Sat, May 23, 2020 at 10:39 AM Brian Raymes 
wrote:

> No problem. I'm happy to assist. I'll update and let you know if I run 
> into any issues.
>
> Brian
>
> -Original Message-
> From: Greg Dove 
> Sent: Friday, May 22, 2020 2:03 PM
> To: Apache Royale Development 
> Subject: Re: About the cumbersome random compilation issue
>
> Thanks again, I believe it should be fixed now, Brian.
> I think there was some unnecessary declaration output being written 
> previously that should not have been - for the generated 'operations'
> Object of the RemoteObject in this case, but perhaps there could have 
> been other cases where this was happening.
>
>
> On Sat, May 23, 2020 at 7:50 AM Greg Dove  wrote:
>
> >
> > Ok I repro'ed that. Not sure how I missed it at all... unless maybe 
> > I made some minor changes after my last test of the examples. Will 
> > figure
> this out.
> >
> >
> > On Sat, May 23, 2020 at 7:40 AM Greg Dove  wrote:
> >
> >> Thanks for letting me know Brian. I had run all the examples 
> >> locally as part of my testing before pushing the changes, and 
> >> wasn't seeing any problems so I must have missed something. Will 
> >> take a look very
> shortly.
> >> Usually I wait for the remote builds to run as a final check but I 
> >> wasn't able to do that this time.
> >>
> >>
> >> On Sat, May 23, 2020 at 6:44 AM Brian Raymes 
> >> 
> >> wrote:
> >>
> >>> I will keep you updated over the coming weeks if I run into the 
> >>> same or similar issue.
> >>>
> >>> In the meantime,
> >>> https://github.com/apache/royale-compiler/commit/96b42e5a980c1d919
> >>> d0 c3a620c500f7a0aff2e9d seems to be breaking my ability to build 
> >>> royale-asjs with examples:
> >>>
> >>> Specifically, MXRoyale / RemoteObjectAMFTest errors for the 
> >>> following reason causing the rest of the build to fail:
> >>>
> >>> Executing MXMLC in tool group Royale with args:
> >>> [-load-config=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjec
> >>> tA MFTest/target/compile-app-config.xml,
> >>> -js-output=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAM
> >>> FT
> >>> est/target/javascript,
> >>> -compiler.targets=JSRoyale,
> >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/m
> >>> ai
> >>> n/royale/App.mxml]
> >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/m
> >>> ai n/royale/App.mxml line 20 column 0 Error: Internal error in 
> >>> ASBlockWalker subsystem, when generating code for:
> >>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/m
> >>> ai n/royale/App.mxml line 20 column 0: 
> >>> java.lang.NullPointerException
> >>> at
> >>>
> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmit
> ter.emitPropertyDecls(MXMLRoyaleEmitter.java:1475)
> >>> at
> >>>
> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmit
> ter.emitDocument(MXMLRoyaleEmitter.java:884)
> >>> at
> >>>
> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleBloc
> kWalker.visitDocument(MXMLRoyaleBlockWalker.java:69)
> >>> at
> >>>
> org.apache.royale.compiler.internal.visitor.mxml.MXMLNodeSwitch.handle
> (MXMLNodeSwitch.java:89)
> >>> at
> >>>
> org.apache.royale.compiler.internal.codegen.mxml.MXMLBlockWalker.walk(
> MXMLBlockWalker.java:156)
> >>> at
> >>>
> org.apache.roy

RE: Royale Echarts (was Re: Charts)

[Brian Raymes]

I don't see it as commented out in either of the pom.xml files within the git 
repo that you shared:


  App.mxml
  SWF,JSRoyale  <-- This is what I would 
change to simply JSRoyale



Brian

-Original Message-
From: Maria Jose Esteve  
Sent: Friday, August 14, 2020 12:30 PM
To: dev@royale.apache.org
Subject: RE: Royale Echarts (was Re: Charts)

Hi Brian,
Thanks for the help.
I have deleted the .mvn directory as you indicate and the  tag had it 
"Commented / * * /". Do I have to uncomment it and leave only JSRoyale?

Thx.
Hiedra

RE: Royale Echarts (was Re: Charts)

[Brian Raymes]

The flex-sdk-converter-maven-extension is not used for building Royale 
projects. Instead, it is used for converting Flex/AIR SDKs to Maven artifacts.

Remove extensions.xml (and the .mvn folder) as it is declaring this unneeded 
artifact.

I also see that you are targeting both SWF and JSRoyale. With echarts, isn't 
JSRoyale be the only usable option? May be a good idea to change 
SWF,JSRoyale to simply JSRoyale to only 
focus on JS output.


Hope this helps,

Brian


-Original Message-
From: Maria Jose Esteve  
Sent: Friday, August 14, 2020 5:35 AM
To: dev@royale.apache.org
Subject: RE: Royale Echarts (was Re: Charts)

Sorry, The image of the error is not seen ... I paste text

PS D:\Desarrollo_Royale\Proyectos\WPNetSuitePlus\Royale-echarts\royale-echarts> 
mvn clean install -DskipTests [WARNING] The POM for 
org.apache.royale.utilities.converter:flex-sdk-converter-maven-extension:jar:1.0.0-SNAPSHOT
 is missing, no dependency information available [WARNING] Failed to read 
extensions descriptor 
D:\Desarrollo_Royale\Proyectos\WPNetSuitePlus\Royale-echarts\royale-echarts\.mvn\extensions.xml:
 Plugin 
org.apache.royale.utilities.converter:flex-sdk-converter-maven-extension:1.0.0-SNAPSHOT
 or one of its dependencies could not be resolved: Could not find artifact 
org.apache.royale.utilities.converter:flex-sdk-converter-maven-extension:jar:1.0.0-SNAPSHOT
[INFO] Scanning for projects...
[INFO]
[INFO] --< com.proj.example:royale-echarts >--- 
[INFO] Building royale-echarts 1.0-SNAPSHOT [INFO] 
[ swf ]-
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ royale-echarts --- 
[INFO] Deleting 
D:\Desarrollo_Royale\Proyectos\WPNetSuitePlus\Royale-echarts\royale-echarts\target
[INFO]
[INFO] --- maven-resources-plugin:3.2.0:resources (default-resources) @ 
royale-echarts --- [WARNING] Using platform encoding (UTF-8 actually) to copy 
filtered resources, i.e. build is platform dependent!
[INFO] Using 'null' encoding to copy filtered properties files.
[INFO] skip non existing resourceDirectory 
D:\Desarrollo_Royale\Proyectos\WPNetSuitePlus\Royale-echarts\royale-echarts\src\main\resources
[INFO]
[INFO] --- royale-maven-plugin:0.9.8-SNAPSHOT:compile-app (default-compile-app) 
@ royale-echarts --- [WARNING] The POM for 
com.adobe.flash.framework:playerglobal:swc:20.0 is missing, no dependency 
information available [INFO] 

[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  1.053 s
[INFO] Finished at: 2020-08-14T14:33:59+02:00 [INFO] 

[ERROR] Failed to execute goal 
org.apache.royale.compiler:royale-maven-plugin:0.9.8-SNAPSHOT:compile-app 
(default-compile-app) on project royale-echarts: Could not resolve dependencies 
for project com.proj.example:royale-echarts:swf:1.0-SNAPSHOT: The following 
artifacts could not be resolved: 
org.apache.royale.framework:Core:swc:0.9.8-SNAPSHOT, 
com.adobe.flash.framework:playerglobal:swc:20.0,
org.apache.royale.framework:HTML:swc:0.9.8-SNAPSHOT: Could not find artifact 
org.apache.royale.framework:Core:swc:0.9.8-SNAPSHOT -> [Help 1] [ERROR] [ERROR] 
To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
PS D:\Desarrollo_Royale\Proyectos\WPNetSuitePlus\Royale-echarts\royale-echarts>

De: Maria Jose Esteve  Enviado el: viernes, 14 de agosto de 
2020 14:26
Para: dev@royale.apache.org
Asunto: RE: Royale Echarts (was Re: Charts)


Hello,

I already have a few examples assembled and a shuttle for them 😝

As I have no experience with Maven or with compiling swc, etc, etc, I mounted 
them in a project, from my work, that "I had up and running" to do the initial 
tests, and everything OK.



To create the final project I have followed the steps indicated here [1] but I 
can't compile it ☹

The [2] instruction doesn't work for me because I don't have the 
settings-template.xml file.

I have launched the compilation, from the vscode Terminal, with the following 
instruction [3] it starts to compile but it gives me an error because it cannot 
find the artifacts ...



[cid:image001.png@01D67245.02877530]



I have included a .vscode/settings.json file with the 0.9.8 SDK settings but it 
doesn't work. Can you help me?

The repository [4] is made up of two projects, one for echarts and one for the 
examples.

I have not tried to compile the project with the examples, I have only copied 
the sample files that I had but I imagine that if I mounted it it would give me 
the same problem.

RE: About the cumbersome random compilation issue

[Brian Raymes]

No problem. I'm happy to assist. I'll update and let you know if I run into any 
issues.

Brian

-Original Message-
From: Greg Dove  
Sent: Friday, May 22, 2020 2:03 PM
To: Apache Royale Development 
Subject: Re: About the cumbersome random compilation issue

Thanks again, I believe it should be fixed now, Brian.
I think there was some unnecessary declaration output being written previously 
that should not have been - for the generated 'operations'
Object of the RemoteObject in this case, but perhaps there could have been 
other cases where this was happening.


On Sat, May 23, 2020 at 7:50 AM Greg Dove  wrote:

>
> Ok I repro'ed that. Not sure how I missed it at all... unless maybe I 
> made some minor changes after my last test of the examples. Will figure this 
> out.
>
>
> On Sat, May 23, 2020 at 7:40 AM Greg Dove  wrote:
>
>> Thanks for letting me know Brian. I had run all the examples locally 
>> as part of my testing before pushing the changes, and wasn't seeing 
>> any problems so I must have missed something. Will take a look very shortly.
>> Usually I wait for the remote builds to run as a final check but I 
>> wasn't able to do that this time.
>>
>>
>> On Sat, May 23, 2020 at 6:44 AM Brian Raymes 
>> 
>> wrote:
>>
>>> I will keep you updated over the coming weeks if I run into the same 
>>> or similar issue.
>>>
>>> In the meantime,
>>> https://github.com/apache/royale-compiler/commit/96b42e5a980c1d919d0
>>> c3a620c500f7a0aff2e9d seems to be breaking my ability to build 
>>> royale-asjs with examples:
>>>
>>> Specifically, MXRoyale / RemoteObjectAMFTest errors for the 
>>> following reason causing the rest of the build to fail:
>>>
>>> Executing MXMLC in tool group Royale with args:
>>> [-load-config=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectA
>>> MFTest/target/compile-app-config.xml,
>>> -js-output=/mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFT
>>> est/target/javascript,
>>> -compiler.targets=JSRoyale,
>>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/mai
>>> n/royale/App.mxml] 
>>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/mai
>>> n/royale/App.mxml line 20 column 0 Error: Internal error in 
>>> ASBlockWalker subsystem, when generating code for:
>>> /mnt/c/dev/royale-asjs/examples/mxroyale/RemoteObjectAMFTest/src/mai
>>> n/royale/App.mxml line 20 column 0: java.lang.NullPointerException
>>> at
>>> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmitter.emitPropertyDecls(MXMLRoyaleEmitter.java:1475)
>>> at
>>> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleEmitter.emitDocument(MXMLRoyaleEmitter.java:884)
>>> at
>>> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleBlockWalker.visitDocument(MXMLRoyaleBlockWalker.java:69)
>>> at
>>> org.apache.royale.compiler.internal.visitor.mxml.MXMLNodeSwitch.handle(MXMLNodeSwitch.java:89)
>>> at
>>> org.apache.royale.compiler.internal.codegen.mxml.MXMLBlockWalker.walk(MXMLBlockWalker.java:156)
>>> at
>>> org.apache.royale.compiler.internal.codegen.mxml.royale.MXMLRoyaleBlockWalker.visitFile(MXMLRoyaleBlockWalker.java:61)
>>> at
>>> org.apache.royale.compiler.internal.visitor.mxml.MXMLNodeSwitch.handle(MXMLNodeSwitch.java:95)
>>> at
>>> org.apache.royale.compiler.internal.codegen.mxml.MXMLBlockWalker.walk(MXMLBlockWalker.java:156)
>>> at
>>> org.apache.royale.compiler.internal.codegen.mxml.MXMLBlockWalker.visitCompilationUnit(MXMLBlockWalker.java:187)
>>> at
>>> org.apache.royale.compiler.internal.codegen.mxml.MXMLWriter.writeTo(MXMLWriter.java:69)
>>> at
>>> org.apache.royale.compiler.clients.MXMLJSCRoyale.compile(MXMLJSCRoyale.java:411)
>>> at
>>> org.apache.royale.compiler.clients.MXMLJSCRoyale._mainNoExit(MXMLJSCRoyale.java:259)
>>> at
>>> org.apache.royale.compiler.clients.MXMLJSCRoyale.mainNoExit(MXMLJSCRoyale.java:216)
>>> at
>>> org.apache.royale.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:363)
>>> at
>>> org.apache.royale.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:298)
>>> at
>>> org.apache.royale.compiler.clients.MXMLJSC.execute(MXMLJSC.java:228)
>>> at org.apache.royale.maven.BaseMojo.execute(BaseMojo.java:383)
>&

RE: About the cumbersome random compilation issue

[Brian Raymes]

 Message-
From: Carlos Rovira  
Sent: Friday, May 22, 2020 7:46 AM
To: Apache Royale Development 
Subject: Re: About the cumbersome random compilation issue

Hi,

if latest fixes as well fix this issue will be a great new for sure :) since is 
random we just can see if it not happen again in the next 1-2 weeks.
also maybe Brian can tell us about his experience too

thanks



El vie., 22 may. 2020 a las 13:27, Greg Dove ()
escribió:

> Carlos, please see if it still happens after the latest changes.
> I don't know if it will fix it or not, but it's worth a shot, based on 
> the symptom that Brian Raymes described.
>
>
>
> On Fri, May 22, 2020 at 11:18 PM Carlos Rovira 
> 
> wrote:
>
> > Hi Chris,
> >
> > maybe we're talking on different issues. The current problem is when 
> > compiling or building a final application, so the compiler behaves 
> > strangely sometimes doing things differently (for that reason I was 
> > pointing to some thread throttle issue). If I understand you right, 
> > I
> think
> > you're pointing to royale 3 repos building issues that from time to 
> > time can hang. That use to be less frecuent than the problem I raise here.
> >
> >
> >
> > El jue., 21 may. 2020 a las 8:43, Christofer Dutz (<
> > christofer.d...@c-ware.de>) escribió:
> >
> > > Hi folks,
> > >
> > > I think it might be a resource leak between multiple module
> compilations.
> > >
> > > I never had the issue when running only one module but hat it 
> > > quite regularly when doing the full build with all modules. So I 
> > > guess
> probably
> > > the modules coming later in the build have a higher chance of 
> > > running
> > into
> > > this problem.
> > >
> > > Things did improve when Greg fixed one of the leaks.
> > > But it hasn't gone away completely.
> > >
> > > Chris
> > > 
> > > Von: Carlos Rovira 
> > > Gesendet: Mittwoch, 20. Mai 2020 17:48
> > > An: Apache Royale Development 
> > > Betreff: Re: About the cumbersome random compilation issue
> > >
> > > Hi Greg,
> > >
> > > next time I'll get a fail compilation I'll store the results and
> comment.
> > > Other thing I'm wondering if is something only related to TDJ 
> > > (jewel
> > apps)
> > > and that's not happening for Basic, Express, or MXRoyale
> > >
> > >
> > > El mar., 19 may. 2020 a las 0:04, Greg Dove 
> > > ()
> > > escribió:
> > >
> > > > Carlos, it would be good to know if the issue you are seeing is 
> > > > the
> > same
> > > > thing.
> > > >
> > > > I know you test mainly in release builds, so if you experience 
> > > > that
> > issue
> > > > in a release build, can you confirm the issue is the same as 
> > > > Brian
> > > reported
> > > > (missing 'prototype._bindings = [...' in the corresponding debug
> build?
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, May 19, 2020 at 9:55 AM Carlos Rovira <
> carlosrov...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > Thanks Brian,
> > > > >
> > > > > I forgot you already sent similar info some weeks ago.
> > > > >
> > > > > @Greg, you that know that code better, maybe there's some 
> > > > > thread
> > issue
> > > > > here? For something that works sometime ok and others not, I 
> > > > > think
> > that
> > > > > random behaviour seems a thread issue where there's no syncing.
> Have
> > > that
> > > > > sense?
> > > > >
> > > > > Thanks
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > El lun., 18 may. 2020 a las 20:17, Greg Dove 
> > > > > ( >)
> > > > > escribió:
> > > > >
> > > > > > That's interesting Brian, thanks for sharing that.
> > > > > >
> > > > > > I have been working on a fix for inherited bindings, which 
> > > > > > is
> > > something
> > > > > > that has never worked but which I needed to work (I now have 
> > > > > > that
> > > > working
> > 

RE: About the cumbersome random compilation issue

[Brian Raymes]

I cannot speak for js-release, but it happens to me with js-debug in what seems 
like 1 in every 10 builds. Possibly more often.

I've made copies a couple times to compare the output. Each time, it appears 
that some "prototype._bindings" are missing. Here is example related to 
TourDeJewel:

In NavigationGroupExampleItemRenderer.js, the following is missing entirely in 
a bad build:

/**
 * @export
 */
itemRenderers.NavigationGroupExampleItemRenderer.prototype._bindings = [
 //
 // contents removed for brevity
 //
];

Several of these "x.prototype._bindings" sections were missing from the 
generated JavaScript.

Hope this helps.

Brian

-Original Message-
From: Alex Harui  
Sent: Sunday, May 17, 2020 8:26 AM
To: dev@royale.apache.org
Subject: Re: About the cumbersome random compilation issue

BTW, is this in js-debug or js-release?

On 5/17/20, 8:20 AM, "Alex Harui"  wrote:

Save a good build. When you think you have a bad build, compare the output.

On 5/17/20, 3:46 AM, "Carlos Rovira"  wrote:

Hi,

I want to open a thread about how to solve the weird random compilation
issue where, from time to time, renderers has no content.

Since is random, this is hard to find, but seems the problem is each 
time
more easy to get.

I suffer in compling TDJ from time to time. And the result is that some
times all compiles ok, and other times I get some Navigator itemrenders
without content (use to be per Navigator component, so all renders in a
control are affected), other times are TabBar items, other times are 
list
item renders inside List playground, and so on. Some times the problem
affects many of the before mentioned controls, and other times are less 
of
them.

I think as TDJ grows, the problem increases, and I end compiling the 
same
2-3 consecutive times until I get the compilation right.

For me this problem is one requirement to reach 1.0, since it reveals a
cumbersome issue, that seems to increase with size of the source code
involved.

I want to ask here if others are finding this issue too in their 
projects,
examples, etc..

As well what could be the problem. Any theory?

The problem should be in a compilation task that involve components that
uses renderers inside. A based renderer control can compile ok, but the
next one not, and the next could be right again...it's all random.

It seems a java thread issue where we need to sync better to endure 
things
are build properly.

Any idea or thing we could try to solve this problem?

Thanks

-- 
Carlos Rovira

https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C091b10b063f747ec4b8608d7fa75da82%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637253256395538387&sdata=xO5EaBe5pz6F0%2BICaCefem2z8siG4%2FaZqw6Kqpo0VBg%3D&reserved=0

RE: Royale compiler remove labels and/or icons randomly

[Brian Raymes]

Hi Carlos,

I've noticed this as well from time to time. This last time, I made a copy of 
the target build folder to compare with a subsequent build (using Beyond 
Compare). It appears that some bindings are missing in a "bad" build. Here is 
example related to TourDeJewel:

In NavigationGroupExampleItemRenderer.js, the following is missing entirely in 
a "bad" build:

/**
 * @export
 */
itemRenderers.NavigationGroupExampleItemRenderer.prototype._bindings = [
 // removed contents as I do not believe they are necessary in this 
case.
];

Also, this wasn't the only case where a "x.prototype._bindings" was missing 
from one of the javascript files.

Hope this helps narrow it down a bit.


Brian

-Original Message-
From: Carlos Rovira  
Sent: Thursday, April 2, 2020 4:47 PM
To: Apache Royale Development 
Subject: Royale compiler remove labels and/or icons randomly (was Re: Control 
over export/rename: Finally giving up)

Hi

I'm sorry to say that the Josh's fix I commented is not fixing the thing I 
suggested. The problem of labels removed is still there as you can see in the 
following image (I had it today again):

https://imgur.com/a/NEiUZXH

The labels or icons that are removed change, so I think this could be some 
thread problem since happens un one compilation from around other 15 or so...

If someone could take a look at this, would be great, since I think is an 
important problem.
I think we should detect what's happening if we can before 1.0

Thanks