jvmarg is a JVM option for Ant tasks, not a compc option. You would need to
keep <jvmarg> as a child tag of the <compc> tag.
The bundles.properties file is right there in the project directory next to the
config file, so you don't even need a relative path.
As for ${FLEX_HOME}, I think in a config file this becomes {flexlib} but I'm
not sure.
- Gordon
-----Original Message-----
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, October 19, 2012 12:19 PM
To: flex-dev@incubator.apache.org
Subject: Re: compc config adjustements (was RE: ASC 2.0 and Falcon)
I did manage to do a prototype conversion this morning of the frameworks
compile target.
There are a couple things I am uncertain about,
-| resource-bundle-list="${basedir}/bundles.properties"
-| <jvmarg line="${compc.jvm.args}"/>
-| output="${FLEX_HOME}/frameworks/libs/framework.swc"
Tokens in flex-config are just {token} right or the dollar sign ${token}? It's
been awhile for me as well. And I was more with component dev than setting up
component builds with flex-config.
Other than the listed things above, it seems pretty straight forward with the
tags. If you want to create a list, you can or I will next week and we could
work it together and then I can commit when it all looks good and still
compiles the SWCs. :)
Mike
Quoting Chema Balsas <jbal...@gmail.com>:
> Hi Mike,
>
> I've dealt with the differences between compc and config files several
> times in my day to day work... now I wish I'd written them down... :D
>
> I think I could find some time to try and help with this. Have you
> already identified which builds need to be updated? We could compile a
> list of them, then start from different ends and try to meet somewhere
> halfway...
>
> @Gordon I don't know if this is a silly question, but is there a
> reliable way of telling if the resulting swc is exactly the same as the old
> one?
> Should something like size or md5 maintained so we could check for that?
>
> Cheers,
> Chema
>
> 2012/10/19 Michael Schmalle <apa...@teotigraphix.com>
>
>> Ok Gordon,
>>
>> I think I understand what you are saying, you want include files that
>> completely configure the target without the compc task so it can be
>> loaded from other clients.
>>
>> This is to be commited when changed in the develop branch.
>>
>> I will ask more questions if needed tomorrow as it sounds like that
>> is your Apache work day.
>>
>> Thanks for all your answers today it has been appreciated.
>>
>> Mike
>>
>>
>> Quoting Gordon Smith <gosm...@adobe.com>:
>>
>> Could you quickly elaborate on the "convert the <compc> tags" part for me?
>>>>
>>>
>>> Each project in sdk/trunk/frameworks/projects builds a SWC. For
>>> example, look at the build.xml file inside
>>> sdk/trunk/frameworks/projects/**framework,
>>> which builds framework.swc. Its "compile" target has the <compc>
>>> task
>>>
>>> <compc fork="true"
>>> output="${FLEX_HOME}/**
>>> frameworks/libs/framework.swc"
>>> resource-bundle-list="${**
>>> basedir}/bundles.properties">
>>> <jvmarg line="${compc.jvm.args}"/>
>>> <target-player>11.1</target-**player>
>>> <namespace
>>> uri="library://ns.adobe.com/**flex/mx<http://ns.adobe.com/flex/mx>"
>>> manifest="${basedir}/manifest.**xml"/>
>>> <namespace
>>> uri="http://www.adobe.com/**2006/mxml<http://www.adobe.com/2006/mxml>"
>>> manifest="${basedir}/manifest.**xml"/>
>>> <include-namespaces
>>> uri="library://ns.adobe.com/* *flex/mx <http://ns.adobe.com/flex/mx>"/>
>>>
>>> <include-classes>**FrameworkClasses</include-**
>>> classes>
>>> <source-path path-element="${basedir}/src"/**>
>>> <library-path/>
>>> <external-library-path dir="${FLEX_HOME}/frameworks/**libs">
>>> <include name="textLayout.swc"/>
>>> </external-library-path>
>>> <external-library-path dir="${env.PLAYERGLOBAL_HOME}"**>
>>> <include name="${playerglobal.version}/**
>>> playerglobal.swc"/>
>>> </external-library-path>
>>> <load-config filename="${FLEX_HOME}/**
>>> frameworks/flex-config.xml"/>
>>> <load-config filename="framework-config.**xml"/>
>>> <include-file name="defaults.css"
>>> path="${basedir}/defaults.css"**/>
>>> <include-file name="defaults-3.0.0.css"
>>> path="${basedir}/defaults-3.0.**0.css"/>
>>> <include-file name="Assets.swf"
>>> path="${basedir}/assets/**Assets.swf"/>
>>> <include-file name="assets/CalendarIcon.png"
>>> path="${basedir}/assets/**CalendarIcon.png"/>
>>> <locale/>
>>> <accessible>true</accessible>
>>> <keep-as3-metadata name="Bindable"/>
>>> <keep-as3-metadata name="Managed"/>
>>> <keep-as3-metadata name="ChangeEvent"/>
>>> <keep-as3-metadata name="**
>>> NonCommittingChangeEvent"/>
>>> <keep-as3-metadata name="Transient"/>
>>> </compc>
>>>
>>> I want it to look instead like
>>>
>>> <compc fork="true" load-config="framework-config.**xml"/>
>>>
>>> where you write the framework-config.xml file using the syntax in
>>> files like flex-config.xml.
>>>
>>> The difficulty is that the syntax for the XML you put inside the
>>> framework-config.xml file is different in various ways from the XML
>>> tags inside the <compc> tag (for one thing, XML config files don't
>>> use
>>> attributes) so the conversion isn't always obvious.
>>>
>>> I want the "compile" target for every project in the projects
>>> directory to use a config file for its compilation options.
>>>
>>> Then you or I can write JUnit tests that use Falcon to compile each
>>> SWC by invoking Falcon with this config file.
>>>
>>> - Gordon
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Michael Schmalle
>>> [mailto:apache@teotigraphix.**com<apa...@teotigraphix.com>
>>> ]
>>> Sent: Thursday, October 18, 2012 3:49 PM
>>> To: flex-dev@incubator.apache.org
>>> Subject: RE: ASC 2.0 and Falcon
>>>
>>> Quoting Gordon Smith <gosm...@adobe.com>:
>>>
>>> Gordon I can help with MXML once I get my feet wet in understanding
>>>>> exactly "What" needs to be implemented.
>>>>>
>>>>
>>>> Tomorrow I'll be working on eliminating the falcon/sdk directory,
>>>> since this violates Apache rules.
>>>>
>>>> Next week I'll check in the first few MXML parser tests for simple
>>>> tags like <Boolean> and <int>. At that point the pattern to follow
>>>> for MXML parser tests will be clear.
>>>>
>>>>
>>> I can help with further tests after this.
>>>
>>>
>>>> - Gordon
>>>>
>>>
>>>
>>> Ok, I understand and replied in my previous email that I realize
>>> MXML is
>>> #1 priority. I will be working on this sooner than later as I see
>>> what you do.
>>>
>>>
>>> In the meantime, you could learn XML config file syntax and convert
>>>> the <compc> tags.
>>>>
>>>
>>> I experimented with the config when I was porting my asdoc program
>>> that extended mxmlc.
>>>
>>> Could you quickly elaborate on the "convert the <compc> tags" part for me?
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Michael Schmalle
>>>> [mailto:apache@teotigraphix.**com<apa...@teotigraphix.com>
>>>> ]
>>>> Sent: Thursday, October 18, 2012 3:25 PM
>>>> To: flex-dev@incubator.apache.org
>>>> Subject: RE: ASC 2.0 and Falcon
>>>>
>>>> So in essence you are saying;
>>>>
>>>> 1. Gordon needs help implementing MXML.
>>>> 2. Flex is incompatible with the new VM that is stage3D based and a
>>>> new architecture for components needs to be created based on Stage3D.
>>>> 3. The ASC compiler of Falcon is going to need to be implemented to
>>>> produce bytecode that is compatible with the new AVM.
>>>>
>>>>
>>>> Correct?
>>>>
>>>>
>>>> Gordon I can help with MXML once I get my feet wet in understanding
>>>> exactly "What" needs to be implemented.
>>>>
>>>>
>>>> Mike
>>>>
>>>> Quoting Gordon Smith <gosm...@adobe.com>:
>>>>
>>>> Furthermore, the new runtime uses new bytecode that the Falcon
>>>>> compiler does not produce, and the new compiler that does produce
>>>>> it doesn't compile MXML.
>>>>>
>>>>> - Gordon
>>>>>
>>>>> -----Original Message-----
>>>>> From: Thibault Imbert [mailto:timb...@adobe.com]
>>>>> Sent: Thursday, October 18, 2012 3:16 PM
>>>>> To: flex-dev@incubator.apache.org
>>>>> Subject: Re: ASC 2.0 and Falcon
>>>>>
>>>>> Hi Om,
>>>>>
>>>>> The rendering architecture of the new runtime is Stage3D only. So
>>>>> essentially, there is not "native" DisplayObject.
>>>>> So your framework needs to leverage Stage3D, just like iOS is
>>>>> leveraging OpenGL for their components UI.
>>>>>
>>>>> That's why we have been funding Starling to help people transition
>>>>> to a full Stage3D model. Recently, the community has created a
>>>>> drawing API extension for Starling:
>>>>> http://www.bytearray.org/?p=**4832<http://www.bytearray.org/?p=483
>>>>> 2>and
>>>>> a few
>>>>> weeks back a skeleton bones extension was also created to create
>>>>> complex animations on top of Starling:
>>>>> https://github.com/**DragonBones/**SkeletonAnimationFramework<https://github.com/DragonBones/SkeletonAnimationFramework>.
>>>>> All of that
>>>>> is open source, you can fork it, create extensions, etc.
>>>>>
>>>>> Feathers is the right model and approach, lightweight UI framework
>>>>> on top of Starling (which does all the Stage3D work behind the scenes).
>>>>>
>>>>> Keep in mind Feathers "vision" is not to replace Flex, it is a
>>>>> lightweight UI framework for Uis in games, developed by a Flex
>>>>> developer who wanted to have some of the power of Flex (skinning,
>>>>> productivity) without reproducing the same mistakes as Flex (lots
>>>>> of dependencies and display list based).
>>>>>
>>>>> Thibault Imbert | sr. product manager gaming (Graphics, Language,
>>>>> VM,
>>>>> Compiler) | Monocle | adobe systems gaming.adobe.com
>>>>> <http://gaming.adobe.com/> | bytearray.org <http://bytearray.org/>
>>>>> | @thibault_imbert
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 10/18/12 3:01 PM, "Om" <bigosma...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>> Just a heads up, given the architecture changes of the next-gen
>>>>>>> runtime, Flex will not be able to run in it. I would "highly"
>>>>>>> recommend you guys having a look at Feathers (work from Josh
>>>>>>> Tynjala
>>>>>>> - feathersui.com) on top of Starling, which will run
>>>>>>> beautifully in our next runtime.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Could you please give us some technical details as to why Flex
>>>>>> wont be able to run in the new runtime? This would help us
>>>>>> figure out what we can/need to do given where we are currently.
>>>>>>
>>>>>> Of course, any other information you can provide to help us move
>>>>>> Flex towards Stage3D/Starling would be beneficial.
>>>>>>
>>>>>> Thanks,
>>>>>> Om
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 18, 2012 at 2:55 PM, Michael Schmalle
>>>>>> <apa...@teotigraphix.com>**wrote:
>>>>>>
>>>>>> Quoting Thibault Imbert <timb...@adobe.com>:
>>>>>>>
>>>>>>> Hi Mike,
>>>>>>>
>>>>>>>>
>>>>>>>> This is true, but ASC is already moving to ASNext targeting the
>>>>>>>> next generation runtime which is targeting game developers. So
>>>>>>>> our resources are assigned to that and the time we have to
>>>>>>>> take ASC
>>>>>>>> 2.0 changes to Falcon, are limited. Gordon will bring
>>>>>>>> key/showstopper bugs fixed in ASC
>>>>>>>> 2.0 to Falcon, we cannot commit to anything more.
>>>>>>>>
>>>>>>>> Just a heads up, given the architecture changes of the next-gen
>>>>>>>> runtime, Flex will not be able to run in it. I would "highly"
>>>>>>>> recommend you guys having a look at Feathers (work from Josh
>>>>>>>> Tynjala
>>>>>>>> - feathersui.com) on top of Starling, which will run
>>>>>>>> beautifully in our next runtime.
>>>>>>>>
>>>>>>>>
>>>>>>> I have just started working with Josh and this component
>>>>>>> architecture, it is very nice. I spoke of feathers earlier
>>>>>>> today and was talking with Josh about MXML support.
>>>>>>>
>>>>>>> So your saying there needs to be a component framework developed
>>>>>>> that will run in the new architecture to be cross compatible? I
>>>>>>> don't quite understand what you are saying.
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Some videos:
>>>>>>>
>>>>>>>>
>>>>>>>> https://vimeo.com/51010861
>>>>>>>>
>>>>>>>> http://www.youtube.com/watch?****v=DGRy7H17MkA&feature=youtu.**
>>>>>>>> *
>>>>>>>> *be&hd=<http://www.youtube.com/watch?**v=DGRy7H17MkA&feature=yo
>>>>>>>> utu.**be&hd=>
>>>>>>>> 1< htt
>>>>>>>> p://www.youtube.com/watch?v=**DGRy7H17MkA&feature=youtu.be&**hd
>>>>>>>> =1<http://www.youtube.com/watch?v=DGRy7H17MkA&feature=youtu.be&;
>>>>>>>> hd=1>
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>> Thibault Imbert | sr. product manager gaming (Graphics,
>>>>>>>> Language, VM,
>>>>>>>> Compiler) | Monocle | adobe systems gaming.adobe.com
>>>>>>>> <http://gaming.adobe.com/> | bytearray.org
>>>>>>>> <http://bytearray.org/>
>>>>>>>> | @thibault_imbert
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/18/12 11:36 AM, "labri...@digitalprimates.net"
>>>>>>>> <labri...@digitalprimates.net> wrote:
>>>>>>>>
>>>>>>>> We have no plans keeping ASC 2.0 (and above) in sync with
>>>>>>>> Falcon, as I
>>>>>>>>
>>>>>>>>> said previously, today the compilers are different projects
>>>>>>>>> and
>>>>>>>>>> targeting two different audiences.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Yeh, we totally get why parsing the AS language and generating
>>>>>>>>> bytecode will be very different for the game market. I can't
>>>>>>>>> imagine the amount of time you guys are spending on the
>>>>>>>>> differences in for loops alone....
>>>>>>>>>
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>>>> http://www.teotigraphix.com http://blog.teotigraphix.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>>
>>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>>
>>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>>
>
>
> --
> Chema
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
