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" <aha...@adobe.com.INVALID>:
On 5/15/17, 7:27 AM, "Christofer Dutz" <christofer.d...@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
