Oh I see that issue I mentioned below was only a change that happened today.
"js-config-template (plus jquery and node): added missing reference to Core.swc, which is required for org.apache.flex.utils.Language" So if the above change is necessary then the ant build scripts should probably change to avoid for the framework build, or maybe the lower level configs could specify the dependency on GCL.swc alone (without setting the append attribute - I think there is that option here, which overrides?). I hope that makes sense On Fri, Jul 15, 2016 at 3:34 PM, Greg Dove <[email protected]> wrote: > Thanks Harbs, I am on windows, but did something similar with a windows > batch file. > > Instructions here [1] are also similar but include a couple of differences: > 1. playerglobal seems to be required as 11.1. > When I tried using a more recent playerglobal version as per those > instructions I had to update the ant scripts which did not handle the more > recent swfversion conversions in task "playerglobal-setswfversion" > 2. Also mention the need to set GOOG-HOME envar. which I actually set to > point inside my flex-asjs install, like so: > set GOOG_HOME=%BASE_DIR%/flex-asjs/js/lib/google/closure-library > I did not try without GOOG_HOME set, so not sure if it is absolutely > required or not > > > I finally got it to build, but not without making some changes.... > > It was breaking at the step when trying to build CoreJS.swc. > Actually I am a bit confused here, because it seems that somewhere the > script is changing the js-config.xml inside flex-asjs/frameworks by copying > from js-config-template.xml. The updated js-config.xml inside frameworks > now specifies a dependency on Core.swc see [2] (which does not yet exist) > and is used to attempt to build CoreJS.swc which fails (Core.swc and others > look to be built following the JS.swc versions in the frameworks ant > script). > > > I commented out this dependency > <!--<path-element>libs/Core.swc</path-element>--> > inside the 3 config.template.xml files that have that and the 'ant all' > build then made it through to completion, so I am assuming/hoping all is > well. > > > This above issue may not be apparent to you if you are doing work on the > isolated parts where the build scripts in the deeper directories do not > change the configs, but I suspect it will be there for you if you did a > full build. It's not the most encouraging experience for someone trying > this for the first time, and I don't think I did anything wrong (although > perhaps that is wrong!). Anyhow I think I might be set up to look into the > BinaryData/ByteArray stuff now :) > > > 1. https://github.com/apache/flex-asjs/blob/develop/READme > > 2. > https://github.com/apache/flex-asjs/blob/develop/frameworks/js-config-template.xml#L73 > > > On Thu, Jul 14, 2016 at 8:59 PM, Harbs <[email protected]> wrote: > >> Monkey patching does not work very well. >> >> Here’s my setup (on Mac — Windows is similar): >> >> 1) Follow the instructions here to get your basic environment setup: >> https://cwiki.apache.org/confluence/display/FLEX/FlexJS+Developer+Setup >> >> 2) If you want to use Flash Builder, read the section on Flash Builder on >> the above page and this as well: >> https://cwiki.apache.org/confluence/display/FLEX/Using+FlexJS+with+Adobe+Flash+Builder >> >> 3) I have a shell script to set all my environment variables in each >> shell like this: >> #!/bin/sh >> >> export FALCON_HOME=/Users/harbs/Documents/ApacheFlex/flex-falcon/compiler >> export FLEXUNIT_HOME=/Users/harbs/Documents/ApacheFlex/flex-flexunit >> export FLEX_HOME=/Users/harbs/Documents/ApacheFlex/flex-sdk >> export >> AIR_HOME=/Users/harbs/Documents/ApacheFlex/frameworks/AIRSDK_Compiler >> export >> PLAYERGLOBAL_HOME=/Users/harbs/Documents/ApacheFlex/frameworks/libs/player >> export >> FLASHPLAYER_DEBUGGER=/Users/harbs/Documents/ApacheFlex/frameworks/Flash\ >> Player\ Debugger.app/Contents/MacOS/Flash\ Player\ Debugger >> export FLEXJS_HOME=/Users/harbs/Documents/ApacheFlex/flex-asjs >> >> 4) You can then run ant on either flex-asjs or any one of the individual >> Projects such as Core. For doing incremental builds of the projects, that >> is highly recommended. >> >> 5) To use the changes with a nightly build, I run the following script >> which copies the changed files: >> rsync -r -u --include="*.swc" >> /Users/harbs/Documents/ApacheFlex/flex-asjs/frameworks/libs >> /Users/harbs/Documents/Apache\ Flex\ Dist/FlexJSNightly/frameworks >> rsync -r -u --include="*.js" >> /Users/harbs/Documents/ApacheFlex/flex-asjs/frameworks/js/FlexJS/generated-sources >> /Users/harbs/Documents/Apache\ Flex\ Dist/FlexJSNightly/frameworks/js/FlexJS >> >> HTH, >> Harbs >> >> On Jul 14, 2016, at 9:33 AM, Greg Dove <[email protected]> wrote: >> >> > Harbs and Alex, thanks for your explanations. >> > >> > I guess 'drop-in' replacement is quite unrealistic. But I think if >> could be >> > closer to the IDataInput/IDataOutput, and given that ByteArray is a >> common >> > utility class in many libraries, particularly for low-level parsing of >> > various formats, the closer the better imo. >> > >> > In my experience most ByteArray use seems to be mostly sequential >> reading >> > or writing which uses the flash class' read/write methods instead of >> array >> > access. So in terms of migration effort, swapping array access out >> wherever >> > it is used to the method-based getByteAt, setByteAt is not so bad. >> > >> > Harbs, I picked up the recent updates from nightly and there is more >> there >> > than what I had for sure, but more to do I think - perhaps I can help - >> I >> > will try to work on this over the next day or so and share where I get >> to. >> > After using Flex for 8 years I am kinda struggling with my setup for >> > FlexJS, and I'm not sure if I can use monkey-patching for checking the >> > additions I have in mind.... which I could do in the past with the >> regular >> > flex sdk. >> > >> > >> > cheers >> > Greg >> > >> > >> > On Wed, Jul 13, 2016 at 6:46 PM, Alex Harui <[email protected]> wrote: >> > >> >> >> >> >> >> On 7/12/16, 3:57 PM, "Greg Dove" <[email protected]> wrote: >> >> >> >>> I have dipped my toes into FlexJS for the first time. I am evaluating >> >>> FlexJS for a migration away from Flex4/flash and figured I would try >> to >> >>> cross compile an isolated a3 library that is a core dependency for my >> >>> client's project. >> >>> >> >>> It seems there is no direct substitute for flash.utils.ByteArray on >> the js >> >>> side, The nearest I could find was org.apache.flex.utils.BinaryData >> which >> >>> seems to be a partial proxy implementation for ByteArray. >> >>> >> >>> BinaryData does not implement IDataInput and IDataOutput and therefore >> >>> cannot simply be used in place of the original ByteArray in arbitrary >> >>> code. >> >>> >> >>> Is this intentional? Or is this WIP, with a plan to get to the >> original >> >>> interfaces? Or am I looking in the wrong place for what I am trying >> to do >> >>> (entirely possible!). >> >> >> >> IMO, FlexJS is a WIP, but there is no "plan" per-se. >> >> >> >> Unlike Flex, FlexJS is intended to support multiple component sets. >> The >> >> Basic set we have released so far is meant to thinly wrap >> Browser/HTML/JS >> >> APIs so that when you compose an application, the result has as little >> >> overhead as possible when compared to writing an HTML/JS app directly >> in >> >> JS. It isn't a goal for these components to emulate Flash. Instead, >> the >> >> SWF versions of those components are trying to emulate the browser. >> >> >> >> There is an experiment under way to try to see how hard it would be to >> >> make a component set that supports most (but not all) Flex APIs. We >> >> received several opinions that the Basic set is too big of a migration >> >> step for existing Flex code bases. Flex is already heavy so making a >> >> heavy component set that lowers migration pain by spending code on >> >> emulating more of Flex in the browser might be viable. This component >> set >> >> is a ton of work and isn't a top priority on my list right now and >> could >> >> use more volunteers to help. >> >> >> >> ByteArray isn't even a Flex API. But it is often used so I suppose a >> >> component set that emulates Flex will likely have to support most of >> >> ByteArray. The Basic set is supposed to be pay-as-you-go and use >> plugins >> >> for additional functionality, so IDataInput/IDataOutput might be >> replaced >> >> by plug-ins that support similar APIs. >> >> >> >> But really, what actually happens is often up to the person that codes >> it. >> >> We don't have resources to mark every API as needing implementation, >> and >> >> since we want to make many implementations as plugins, the API may not >> be >> >> the same anyway, so we just need folks to jump in and deal with holes >> in >> >> the documentation and code and help make things better for the next >> person >> >> who jumps in. >> >> >> >> HTH, >> >> -Alex >> >> >> >> >> >> >
