As mentioned by others FlashDevelop not only automatically fetches the
Adobe 23201B build for you, but more importantly they build both a template
for using the old compiler for Flash Applications and the new one for AIR
applications. When the Apache Flex framework is ready to go, they will
provide an option to download and integrate that with the most current AIR
release.
What they do not have in their vision is an automatic integration of the
Apache Flex framework with AIR that can use ASC2. What has become of
anything having to do with Gordon's getting it possible to compile an
ApacheFlex/AIR application with the new compiler so that we can take
advantage of the performance optimizations it enables? With all the
coverage that has beena dded to the nightly builds, where is the one that
shows what happens when you attempt to do it all with the new compiler?
We know that FlexJS depends upon the new compiler but desktop developers
who do not plan to port to a browser world also have been hoping to get the
enhancements that pure Adobe Flash developers and those willing to purchase
FlashBuilder have now had for close to a year.
On Wed, Jul 24, 2013 at 5:31 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 7/24/13 5:04 PM, "Mark Kessler" <kesslerconsult...@gmail.com> wrote:
>
> >Could be an interesting point if they stop hosting Adobe Flex 4.6 some day
> >:P
> Quite true, so it really should be on our task list to eliminate our
> dependencies on Adobe stuff over the next 3.5 years. Plus, every time I
> wait for Adobe Flex to download, my head starts to hurt.
>
> There are two issues though: prerequisites, and optional features.
>
> Regarding prerequisites:
>
> The current SDK will probably always be tied to the Flash Platform. The
> Flash/AIR SDKs will never be licensed in an Apache-compatible way and
> thus, it will always be important to have a configuration where the
> Flash/AIR stuff is downloaded first and can be used without being copied
> into the SDK folders. This is so anyone who really cares can feel safe
> about what files in the SDK folders are and aren't Apache-compatible.
> IMO, this is very important for folks submitting source back to Apache,
> otherwise, the wrong thing can get checked in by accident. I know I am
> very capable of making this mistake, so my local working copies do not get
> reconfigured for use in FB.
>
> The unfortunate problem is that FB doesn't recognize a Flex SDK without
> Flash/AIR copied into it, so we'll probably always have a tool that does
> that for you with the appropriate warnings, but who knows if IntelliJ and
> other IDEs will get smart about this and eliminate that step for their
> customers.
>
> And FlexJS? The AS side does have dependencies on Flash/AIR, but we
> should probably make sure there is a kit that somehow lets you build
> without those prerequisites.
>
> Regarding Optional Features:
>
> BlazeDS, OSMF and font embedding libraries make up a set of optional
> features because they are or have dependencies on non-compatible
> licensing. BlazeDS will eventually be donated to Apache. OSMF is a
> category B license so it should be ok as an option. And that leaves the
> font embedding libraries. Font embedding is not on the near term radar
> for FlexJS, so it won't have a problem, but eventually we need to rewrite
> the font embedding libraries ourselves for the current SDK and potentially
> for FlexJS's AS side as well.
>
>
> >
> >-Mark
> >
> >
> >On Wed, Jul 24, 2013 at 7:03 PM, Justin Mclean
> ><jus...@classsoftware.com>wrote:
> >
> >> HI,
> >>
> >> > when we execute "constructForIDE" script we need to provide an Adobe
> >>Flex
> >> > SDK 4.6.0 I think this dependency is not so good for our new Apache
> >>way
> >> out of Adobe.
> >> It's their for convenience we don't have to use it. :-)
> >>
> >> We don't have a way to compile all the missing bits so we still need to
> >> get then from somewhere, most peopel installing Apache Flex would have
> >> Adobe Flex 4.6 was the assumption.
> >>
> >> > does not seems really necessary. Moreover...why not flex-sdk is
> >>already
> >> > prepared to be an SDK to use in and IDE without the need to run this
> >> script?
> >> Alex can hopefully explain that better than I, but see the discussion
> >> about config files and {airHome} as one reason.
> >>
> >> Thanks,
> >> Justin
>
>
