Hi Chris, I don't understand fully the workflow of what you're proposing. You mean the maven config will be auto generated? but what will be the input? some "config.xml"? If we want for example to add -js-default-initializers in something we do as users, so we need to do that manually, so don't follow what you have in mind
thanks El dom., 27 sept. 2020 a las 13:39, Christofer Dutz (< [email protected]>) escribió: > 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 > > > -- Carlos Rovira http://about.me/carlosrovira
