Chris,
it seems we have already this in place in main pom:
<configuration>
<targetPlayer>${flash.version}</targetPlayer>
<debug>${royale.debug}</debug>
<keepAs3Metadata>
<name>Bindable</name>
<name>Managed</name>
<name>ChangeEvent</name>
<name>NonCommittingChangeEvent</name>
<name>Transient</name>
<name>Mixin</name>
</keepAs3Metadata>
</configuration>
So If we want to add to that list when using Crux how we should do it?
The following will keep the others? I guess the normal would be to remove
the previous list:
<configuration>
<keepAs3Metadata>
<name>Inject</name>
<name>Dispatcher</name>
<name>EventHandler</name>
<name>PostConstruct</name>
<name>PreDestroy</name>
<name>ViewAdded</name>
<name>ViewRemoved</name>
</keepAs3Metadata>
</configuration>
El dom., 27 sept. 2020 a las 10:47, Carlos Rovira (<[email protected]>)
escribió:
> Hi Chris,
>
> I'll be glad to join this effort (and hope others do so too). So if you
> add one compiler option in a single commit, I'll take a look and try to add
> another one myself. We need to use this or other thread to know if someone
> goes to add a compiler option to avoid duplianting work.
>
> For now I think we need to add:
>
> -source-map=true;
> -js-default-initializers=true;
> -js-dynamic-access-unknown-members=true;
>
> -compiler.exclude-defaults-css-files=MXRoyale-0.9.8-SNAPSHOT-js.swc:defaults.css;
>
> for modules:
> -js-compiler-option=--variable_map_input_file
> ../../../../../royaleapp/target/javascript/bin/js-release/gccvars.txt;
> -js-compiler-option+=--property_map_input_file
> ../../../../../royaleapp/target/javascript/bin/js-release/gccprops.txt
>
> I think I saw this one already:
>
> -keep-as3-metadata+=Inject,Dispatcher,EventHandler,PostConstruct,PreDestroy,ViewAdded,ViewRemoved,Bindable,Transient;
>
> but this one maybe not:
> -keep-code-with-metadata=Inject;
>
>
> El dom., 27 sept. 2020 a las 0:51, Christofer Dutz (<
> [email protected]>) escribió:
>
>> Hi folks,
>>
>> today I invested about 8 hours in tracking down a problem I was having
>> with using Crux with a main instance in the main application and
>> sub-instances in dynamically loaded modules.
>>
>> In the end it turned out the problem was, that the metadata was stripped
>> out at compilation, even if I thought I had configured it as I explicitly
>> did so in the main pom.
>>
>> In Maven you usually configure general purpose settings in the higher
>> level poms and then fine-tune the configuration while going down the module
>> tree.
>> Unfortunately passing everything in “additionalCompilerSettings” makes
>> this pattern impossible.
>>
>> As in my application for modules I add a setting for the “module-output”,
>> it doesn’t add this setting to the existing settings, it replaces them
>> completely keeping only the module-output.
>> If the settings were implemented as configuration options of the maven
>> plugin, this would have worked nicely.
>> Then specifying a <module-output>lalala</module-output> would work
>> additive and not replace any other settings.
>>
>> When I built the royale-maven-plugin the additionalCompilerOptions was
>> sort of a workaround for situations in which a new compiler setting was
>> needed, but it hadn’t been added to the configuration yet.
>>
>> Guess when Royale forked and I stopped working on the plugin, only very
>> few config options were added and usage of the additionalCompilerOptions
>> became the default.
>>
>> I would like to start adding the most important compiler options to the
>> plugin in order to reduce the additionalCompilerOptions usage (It will
>> always stay in there as it’s useful).
>>
>> So it would be cool, if you could reply to this thread with which
>> settings you usually use in conjunction with additionalCompilerOptions that
>> I add those first that have the greatest impact.
>>
>> Thanks,
>> Chris
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
