Hi Alex,
No IntelliJ doesn’t do that and it doesn’t need to do it. The
Maven-plugin-plugin (A maven plugin to compile maven plugins) does this. It
generates a file called META-INF/maven/plugin.xml which contains the parameters
and their types. Nothing more to it.
I’m definitely not asking not to support Ant for end-users. I’m suggesting to
have one single build to build the project. I would also be happy to provide a
Gradle plugin to build Flex applications, but not to move the build of
compiler, framework etc. to Gradle.
Also, I don’t quite get the problem with the config files. Why is it needed to
change anything here besides eventually updating the templates. Is it the
problem in the distribution? What I did there was an attempt to get the maven
distribution to work in IDEs … we can definitely change things here.
Chris
Am 15.05.17, 13:20 schrieb "Alex Harui" <aha...@adobe.com.INVALID>:
On 5/15/17, 8:34 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>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.
Just so I understand: IntelliJ introspects the classes in the jars and
looks for annotations like @Parameter?
>
>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.
IMO, I would happily add Gradle or some other build system if it would
attract more contributors, like from the Gradle-happy Cordova community.
We could drop the Ant build of the framework and compiler as long as there
is a way to test the Ant compatibility of the framework and compiler, and
there is a way for folks to use just an IDE to build the framework. We
should continue to allow our customers to use Ant and IDEs regardless of
whether we build every SWC with Ant. Building the SWCs with Ant is one
way to prove our Ant capabilities still work.
>
>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.
Well, you are welcome to show us how this can be done. In the meantime,
if the sync-up starts costing us too much and the hack is lower cost, the
hack might be a good interim solution.
-Alex
