Re: library-path and external-library-path fixes

I quick look seems to indicate that these are coming from Jewel (which I'm not using). > On Jul 16, 2019, at 6:58 PM, Harbs wrote: > > These warnings look new: > > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager > println > WARNING: externs/dialogPolyfill.js:15:

Re: library-path and external-library-path fixes

Closure compiler is giving a minor warning about the externs JS files that externc is generating. Nothing has changed recently about the way we generate code with externc, as far as I know. I think it has actually always complained about our externs JS. It's just that the build is discovering a

Re: AMF and class aliases

Thanks Carlos & Greg, we'll take a look.. -Original Message- From: Greg Dove Sent: 15 July 2019 21:40 To: dev@royale.apache.org Subject: [EXTERNAL] Re: AMF and class aliases Also, before I forget: If your legacy flex app includes [Transient] metadata anywhere, don't forget to

Re: library-path and external-library-path fixes

Oh yeah, the Maven "distribution" has its own separate versions of files like frameworks/royale-config.xml and frameworks/js-config.xml, doesn't it? I guess that those need to be updated to use external-library-path too. -- Josh Tynjala Bowler Hat LLC On Tue, Jul 16,

Re: library-path and external-library-path fixes

Thanks for this. :-) I just wanted to let you know that I successfully compiled all my libraries and app (after making the necessary changes). It all seems to work correctly. Good work! :-) Harbs > On Jul 15, 2019, at 10:32 PM, Josh Tynjala wrote: > > Hey folks, > > I just pushed some

Re: library-path and external-library-path fixes

In the end I think this is something on my sight, cause example build on the server is working fine. When I build framework locally and than example is during run I'm getting error mentioned in previous emails. However if you check on your sight and everything will be working I will dive deeper to

Re: library-path and external-library-path fixes

Oh, yes. Sorry. In this case, it's not externc, but our code in the Royale compiler is still generating the JS externs. -- Josh Tynjala Bowler Hat LLC On Tue, Jul 16, 2019 at 9:19 AM Harbs wrote: > OK. > > FWIW, it seems like it’s being generated by an @externs comment

Build failed in Jenkins: royale-asjs_MXTests #943

See -- [...truncated 866.40 KB...] [mxmlc] scanning for overrides: ObjectUtil [mxmlc] scanning for overrides: SolidBorderUtil [mxmlc] scanning

Re: library-path and external-library-path fixes

Hi Carlos, Did you check whether you can run TourDeJewel ? I have build SDK using Maven and than TourDeJewel and I couldn't run application. I'm getting [1]. When I build HelloWorld and run I got the same. [1] https://ibb.co/NKjNBMJ Thanks, Piotr wt., 16 lip 2019 o 16:10 Carlos Rovira

Re: library-path and external-library-path fixes

These warnings look new: Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager println WARNING: externs/dialogPolyfill.js:15: WARNING - accessing name dialogPolyfill in externs has no effect. Perhaps you forgot to add a var keyword? dialogPolyfill = function() { ^^

Re: library-path and external-library-path fixes

I see that on the server I'm able to run TourDeJewel. [1] I will commit now one thing and see whether my code will be runnable. [1] https://builds.apache.org/job/Royale-asjs/1954/artifact/examples/royale/TourDeJewel/target/javascript/bin/js-debug/index.html wt., 16 lip 2019 o 16:33 Piotr

Re: library-path and external-library-path fixes

Before I committed my changes, I confirmed that dialogPolyfill seemed to be properly working in a release build of TourDeJewel. With that in mind, I don't think that it will cause any problems to keep dialogPolyfill and hljs in Jewel. However, I think that the best practice would be to move them

Re: library-path and external-library-path fixes

I thought that's what you meant when you said that you built the SDK with Maven. Well, regardless, I still need to update those files. I'll try to build TourDeJewel entirely with Maven. Maybe there's something that I need to tweak in the Maven build plugin that wasn't picked up by my changes.

Re: library-path and external-library-path fixes

Thanks. I'm investigating. I've figured out that the Maven build is still using library-path (or js-library-path) instead of external-library-path (or js-external-library-path) when building the framework SWCs. If I run "mvn clean install" in frameworks/projects/Jewel, I can see that a

Re: [MAVEN-BUILD] Royale-asjs - Build # 1955 - Failure

Hi, Could this be caused for the latest changes about library-path / eexternal-library-path? thanks El mar., 16 jul. 2019 a las 14:18, Apache Jenkins Server (< jenk...@builds.apache.org>) escribió: > The Apache Jenkins build system has built Royale-asjs (build #1955) > > Status: Failure > >

Re: library-path and external-library-path fixes

OK. FWIW, it seems like it’s being generated by an @externs comment in the AS3 class. > On Jul 16, 2019, at 7:13 PM, Josh Tynjala wrote: > > Closure compiler is giving a minor warning about the externs JS files that > externc is generating. Nothing has changed recently about the way we >

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

See

Re: library-path and external-library-path fixes

Hi Josh, El mar., 16 jul. 2019 a las 17:02, Josh Tynjala () escribió: > Before I committed my changes, I confirmed that dialogPolyfill seemed to be > properly working in a release build of TourDeJewel. With that in mind, I > don't think that it will cause any problems to keep dialogPolyfill and

Re: Crux Branch

Ok thanks for clarifying Carlos, I will merge into develop as-is (with required updates following Josh's changes) later today. On Tue, Jul 16, 2019 at 8:05 PM Carlos Rovira wrote: > Hi Greg, > > agree with all you say. > > As a user of Swiz on Flex, I know Swiz was a "sub-framework" and used

Re: library-path and external-library-path fixes

Thanks for taking a look at this Josh, I could try that build tomorrow as I do a full rebuild with maven as usual thanks El mar., 16 jul. 2019 a las 18:47, Josh Tynjala () escribió: > Thanks. I'm investigating. > > I've figured out that the Maven build is still using library-path (or >

Re: library-path and external-library-path fixes

Hi Harbs, no, I think that warnings was already appearing before that changes. So seems GCC is still complaining and throwing warnings El mar., 16 jul. 2019 a las 17:58, Harbs () escribió: > These warnings look new: > > Jul 16, 2019 6:55:16 PM com.google.javascript.jscomp.LoggerErrorManager >

Re: library-path and external-library-path fixes

Turns out I needed the JAVA_TOOL_OPTIONS environment variable set to -Dfile.encoding=UTF8 to get the release build working. Closure compiler doesn't seem to like files that are not UTF-8. It seemed strange to me that an environment variable was necessary to work around the issue, so I fixed the

Re: library-path and external-library-path fixes

Hi Josh, just let you now that currently Maven distribution (to make an SDK) is not working. when run it does not fails, but does not generate a valid SDK, something must be tweaked to get that working. I tried long time ago but didn't get it to work Currently we build maven and then SDK with

Re: library-path and external-library-path fixes

Hi, thanks Josh for the update! One question about it: should separate the @extern classes in Jewel (dialogPollyfill and hljs classes) or with this change now can live in that library? Just to know it, although for other organizational purposes I think it should be probably separated. @Greg Dove

Re: library-path and external-library-path fixes

Hi Josh, Do you refer to my post by mentioning "distribution"? - I don't use distribution for Maven. I will rebuild everything once again. Maybe I'm missing something. Thanks, Piotr wt., 16 lip 2019 o 17:04 Josh Tynjala napisał(a): > Oh yeah, the Maven "distribution" has its own separate

Re: library-path and external-library-path fixes

Josh, It looks like something is happened actually. Latest build on server failed, but was able to build all examples and TourDeJewel is not running [1] [1] https://builds.apache.org/job/Royale-asjs/1956/artifact/examples/royale/TourDeJewel/target/javascript/bin/js-debug/index.html Thanks,

Re: library-path and external-library-path fixes

I made some tweaks to the royale-maven-plugin to make it properly use external-library-path (and js-external-library-path). Now, I can successfully create a debug build of TourDeJewel with Maven. However, it looks like App.js in the release build is empty except for the source mapping URL. I'm

Re: library-path and external-library-path fixes

Hi Piotr, I couldn't try, probably could not until tomorrow. Sorry El mar., 16 jul. 2019 a las 16:34, Piotr Zarzycki (< piotrzarzyck...@gmail.com>) escribió: > Hi Carlos, > > Did you check whether you can run TourDeJewel ? I have build SDK using > Maven and than TourDeJewel and I couldn't run

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

See

Build failed in Jenkins: royale-asjs_MXTests #948

See Changes: [greg.dove] initial WIP on Crux [greg.dove] Partial tidyup [greg.dove] Fix Jewel Crux quickstart example [greg.dove] EventHandler processing of event properties

Re: Crux Branch

Alex, I think that java framework is unlikely to be important for the same reasons you give for 3rd party Basic or Jewel. Firstly I don't think it has been widely used. Although it is never a perfect assessment, I tend to look at things like that by first checking how active they are (commits,

Build failed in Jenkins: royale-asjs_MXTests #942

See -- [...truncated 865.76 KB...] [mxmlc] scanning for overrides: ObjectUtil [mxmlc] scanning for overrides: SolidBorderUtil [mxmlc] scanning

Re: Crux Branch

Hi Greg, agree with all you say. As a user of Swiz on Flex, I know Swiz was a "sub-framework" and used by a "subset" of teams and developers in the world. So in the end is a piece of software needed, for using Royale in big projects, but for migration from Flex I expect few devs/teams, since