Hi Chris, that seems so cool :)
El dom., 27 sept. 2020 a las 13:06, Christofer Dutz (< [email protected]>) escribió: > 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 > > -- Carlos Rovira http://about.me/carlosrovira
