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

Reply via email to