Hi all, While working on something else I just noticed that the type:
org.apache.royale.compiler.config.Configuration Contains most of what we would need in order to automatically support any compiler option in the maven plugin. Probably we could even do this at runtime, but this would have the disadvantage of not having tool support in any maven enabled IDE. So the option I see which could be better, would be to generated the maven configuration code from the code in the Configuration. So if a new option would be added to the compiler, then this needs to be added to the Configuration or one of its sub-types. Then the build would automatically adjust the maven plugin and we'd instantly support the new option. Possibly we might need to extend the meta-information in by adding some Annotation to tell the code generator how to generate the template for the config file. What do you think? Chris Am 27.09.20, 13:06 schrieb "Christofer Dutz" <[email protected]>: 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
