Hi Carlos, regarding modules I was even thinking of introducing a little higher level support in the plugin. There are a lot of settings that apply for modules such as the variable_map_input_file and property_map_input_file. So perhaps it would even be worth introducing a new packaging type "module" (or similar name) to contain default configs for modules.
Chris Am 27.09.20, 10:47 schrieb "Carlos Rovira" <[email protected]>: 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
