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
