Carlos, this is to add the options to the recognised compiler config settings inside pom.xml so they don't need to be configured via 'additionalCompilerOptions' but they will have their own xml tags. That allows 'inheritance' rules to apply. The process Chris describes is to create the maven support for that automatically (and it sounds good to me). The generated config.xml is (afaik) just for reference, so you can see what settings were applied. I guess it is similar to dump-config...
On Mon, Sep 28, 2020 at 9:08 AM Carlos Rovira <[email protected]> wrote: > Hi Chris, > > I think maybe I'm a bit confused, sorry. > So the objective is to remove the need generated "compile-swf-config.xml"? > Maybe I need to visualize a project. Let's say we use TDJ as the App > example project, can you explain with it the workflow? We need to create a > Java class for it? so if we decide to use "js-default-initializers" in that > project we configure in that class and then when compile that create for > use the xml? > Sorry if I'm a bit dumb here still not catching this :) > > El dom., 27 sept. 2020 a las 18:28, Christofer Dutz (< > [email protected]>) escribió: > > > And as an example: > > > > The "js-default-initializers" is defined in the Class "JSConfiguration" > > (Lines 146-152) > > > > @Config > > @Mapping("js-default-initializers") > > public void setJsDefaultInitializers(ConfigurationValue cv, boolean > > value) > > throws ConfigurationException > > { > > jsDefaultInitializers = value; > > } > > > > So the generator could see that there is a configuration option (Due to > > the @Config) and that the name should be "js-default-initializers". > > Also it would see it's a "Boolean" value so it would use that config > > option and output a " js-default-initializers" option in the generated > XML. > > > > Similar, but a little more complicated with js-output-optimization: > > > > @Config(allowMultiple = true) > > @Mapping("js-output-optimization") > > @Arguments("optimization") > > @InfiniteArguments > > public void setJSOutputOptimizations(ConfigurationValue cv, > > List<String> value) > > throws ConfigurationException > > { > > jsOutputOptimizations.addAll(value); > > } > > > > Here it would be a config-option called "js-output-optimization" which > > would be a List of String values. When serializing we would wrap every > > value in an element called "optimization". > > Which then would produce the following output: > > > > <js-output-optimization> > > <optimization>skipAsCoercions</optimization> > > </js-output-optimization> > > > > For the nested configurations (like compiler settings): > > > > @Config(advanced = true) > > @Mapping({ "compiler", "keep-all-type-selectors" }) > > @RoyaleOnly > > public void setCompilerKeepAllTypeSelectors(ConfigurationValue cv, > > boolean keepAllTypeSelectors) > > { > > this.keepAllTypeSelectors = keepAllTypeSelectors; > > } > > > > It also looks as if it would contain all the information we need to > create > > a maven plugin that works completely without templates. > > > > Hope that explains things. > > > > Chris > > > > > > > > > > > > > > Am 27.09.20, 16:32 schrieb "Carlos Rovira" <[email protected]>: > > > > 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 > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira >
