Hi Carlos, The reason is that if I generate the sources for the Maven plugins configuration, then the maven-plugin-plugin (yes that's a thing) will find these and create the correct descriptors for this. And this again will allow IntelliJ to support you in configuring your plugin.
Chris Am 28.09.20, 10:40 schrieb "Carlos Rovira" <[email protected]>: Hi Greg, I understand it and it sounds good to me too. What I don't understand is the java automatic generation since it seems that it is the user who chooses to add one or another configuration option. So I think I'm sure I'm missing something. But better go and do the improvements planned since I'll be understanding for sure when using it when it's done :) El dom., 27 sept. 2020 a las 22:32, Greg Dove (<[email protected]>) escribió: > 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 > > > -- Carlos Rovira http://about.me/carlosrovira
