flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: [FalconJx] Compiler Options (was Re: [5/5] git commit: [flex-asjs] [refs/heads/release0.8.0] - distribution: updated -config.xml files used by Maven distribution because they were out of date)
Date Mon, 15 May 2017 15:34:16 GMT
Hi Alex,

IntelliJ inspects maven plugins and hereby knows which config options there are and what default
values it uses. If you use a non-existing config option, it marks this as an error in the
editor. It doesn’t have an influence on the operation, but I don’t like the editor been
all red.

The additionalCompilerOptions is for adding command-line arguments to the compiler. It doesn’t
influence the configuration-xml, I was more thinking of XML content.

Well we have a lot of things we have to keep in sync … starting at the Ant and Maven build
of the project itself … which brings me back to my suggestion to make Maven the master build
system and drop maintaining the Ant one. Right now, this double build system situation is
causing most of the need to sync stuff. 

I think going down a hack-path is also not an option. We should start reducing technical debt,
not continue to add more.

The option I see is: Right now, we have no formal definition of the xml format used in the
config files. If we had such a formal definition (let’s say in form of an XML Schema), then
we could have the configuration code generated from that as part of the build. This would
also cleanup the configuration parser in the compiler greatly. And we would get immediate
feedback if a config file contains invalid input. Right now, the compiler tends to report
NullPointerExceptions for a lot of these cases, which is not very helpful in finding what
the problem is. Extending or changing the configuration would then mean changing the XML Schema
and re-building. The build would create/update the configuration classes and you could immediately
start using the config changes you just did. Then the Maven plugin could instantly pass in
the configuration directly without the need to generate the config-xml files. But this would
require a big cleanup in the compiler, but we need that anyway.

Chris


Am 15.05.17, 11:06 schrieb "Alex Harui" <aharui@adobe.com.INVALID>:

    
    
    On 5/15/17, 7:27 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:
    >
    >So now the problem is keeping these defaults in sync with changed done in
    >the templates used by FlashBuilder and Ant … correct?
    >
    >Alex correctly noticed that if you add non-existing config options to the
    >plugin configuration, Maven simply ignores that. However we shouldn’t use
    >that to pass though information. In IntelliJ a pom would be completely
    >red and it could be problematic to get access to the configuration
    >options as Maven is completely ignoring them.
    
    I'm not sure I understood what error/problem you would get.  We could
    teach the compiler to read IntelliJ project settings as well.
    
    >One option I see that could be interesting, would be to provide a
    >configuration option that we can add additional configuration to. So, in
    >the plugin config we would have an “additionalConfiguration” element that
    >can contain xml tags. This should be quite easy to implement and
    >maintain. But we should not rely on this to keep the maven configs in
    >sync with the ant ones. If the defaults change, these changes should be
    >forwarded to the maven plugins defaults as it’s one of Mavens base
    >principals that the default case should require almost no configuration
    >at all.
    
    You already added an "additionalCompilerOptions" element.
    
    
    IMO, it would be better if we didn't have to keep anything "in sync".  The
    words "in sync" imply that there are two copies of something.  So, I think
    the problem to discuss is how can we have one master file for default
    settings and have Ant and Maven and IDEs and command line users access
    them, without dependencies on Maven.
    
    And, the related problem is how we can add new compiler options without
    having to keep BaseMojo in sync.
    
    The only solution I can currently think of is my proposed "hack" that
    relies on the fact that the settings are described in a Maven pom and
    aren't so sophisticated that I can't just pull them out with an XML parser
    and no Maven dependencies.
    
    Other ideas are certainly welcome.  And no rush to close this discussion.
    I have no plans to actually write such code any time soon unless folks
    start asking me to.
    
    -Alex
    
    

Mime
View raw message