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
