Sorry about breaking your workflow. It didn't occur to me that folks were
trying to update a FlexJS SDK by copying in JS files from a repo. That
would only work if you know you didn't change any AS code paths. IMO,
there are only two workflows I can think of that should work in all cases:
1) Shut down Flash Builder, copy in SWCs, re-open Flash Builder.
2) Don't use SWCs from a FlexJS SDK and set up the SWCs as library
projects in FB.
There may be issues with #2, but IMO, we should iron out the kinks in that
workflow as it is probably going to be the optimal one.
If you really want output JS files again, we could add another ant target
that generates them. The compiler still knows how, you just have to
specify an output folder instead of an output swc.
I'll be looking at your other issues today.
On 10/13/16, 2:05 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>We finally managed to get our project to build by extracting the js files
>from the SWC and copying them to where the JS files used to be in the
>nightly which we are building against.
>That’s a pretty poor work-around. We need instructions on how to get the
>new SWCs to work in Flash Builder.
>On Oct 13, 2016, at 11:24 AM, Harbs <harbs.li...@gmail.com> wrote:
>> It doesn’t “just work”. We’re having a lot of trouble figuring out
>>everything that changed.
>> This is really frustrating. We’ve wasted a couple of days chasing our
>>tails dues to things changing.
>> I don’t see any js files being generated in the latest version of
>>develop. I know there as some discussion about changing the JS SWCs for
>>easier use of libraries. Did that change using the Framework? We have
>>scripts which copy updated asjs files to use while we’re developing, but
>>they don’t seem to work anymore.
>> Right now, we cannot get anything done because we can’t get asjs to
>>compile and work right… :-(
>> On Oct 13, 2016, at 9:21 AM, Alex Harui <aha...@adobe.com> wrote:
>>> On 10/12/16, 11:12 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>> I obviously have not been following well enough.
>>>> What was the reason for this change?
>>> Lizhi found that the previous way of accessing the super setter or
>>> was significantly slower.
>>> But if everything was compiled with the same version of the compiler,
>>> should "just work".