[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)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[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)

Alex Harui-2
You know, it just occurred to me that I don't fully understand why Maven
is causing the compiler to read a flex-config.xml file.  It could have to
do with the fact that we simply haven't made a mapping of all compiler
options into pom.xml.  It should be trivial to have Maven only look for
the -config.xml that BaseMojo generates from the POM.

One pain point that would remain is that when you add a new option to the
compiler config, you also have to change BaseMojo.  That is what I was
proposing to solve by teaching the compiler to read the pom, but maybe if
BaseMojo can simply pass through all configuration options directly that
would eliminate that synchronization step.  But then the pom entries would
have "-" in them or BaseMojo could insert the dashes as necessary by
scanning for capital letters.

And that still doesn't solve how Ant, IDE, and command-line users would
pick up their configuration options.

Food for thought,
-Alex

On 5/14/17, 7:07 AM, "piotrz" <[hidden email]> wrote:

>Btw. If completely remove path-element to typedefs project didn't build
>either, but with different stack trace. So removing is not the option.
>
>Piotr
>
>
>
>-----
>Apache Flex PMC
>[hidden email]
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FRe-5-5-git-commit-flex-asjs-refs-hea
>ds-release0-8-0-distribution-updated-config-xml-files-used-by-Mae-tp61584p
>61588.html&data=02%7C01%7C%7Cbf98b3a329764c987b3608d49ad470cd%7Cfa7b1b5a7b
>34438794aed2c178decee1%7C0%7C0%7C636303684602850334&sdata=S2xvKEZMKIivtJ8n
>mWaq0NurHvHtUSxKAfV79rLFrQg%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

Josh Tynjala
I imagine that if you run mxmlc in a Maven distribution, it will use the
-config.xml files.

Or does building an app with Maven instead of mxmlc also read the
-config.xml files?

- Josh

On May 14, 2017 8:00 AM, "Alex Harui" <[hidden email]> wrote:

You know, it just occurred to me that I don't fully understand why Maven
is causing the compiler to read a flex-config.xml file.  It could have to
do with the fact that we simply haven't made a mapping of all compiler
options into pom.xml.  It should be trivial to have Maven only look for
the -config.xml that BaseMojo generates from the POM.

One pain point that would remain is that when you add a new option to the
compiler config, you also have to change BaseMojo.  That is what I was
proposing to solve by teaching the compiler to read the pom, but maybe if
BaseMojo can simply pass through all configuration options directly that
would eliminate that synchronization step.  But then the pom entries would
have "-" in them or BaseMojo could insert the dashes as necessary by
scanning for capital letters.

And that still doesn't solve how Ant, IDE, and command-line users would
pick up their configuration options.

Food for thought,
-Alex

On 5/14/17, 7:07 AM, "piotrz" <[hidden email]> wrote:

>Btw. If completely remove path-element to typedefs project didn't build
>either, but with different stack trace. So removing is not the option.
>
>Piotr
>
>
>
>-----
>Apache Flex PMC
>[hidden email]
>--
>View this message in context:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-development.2333347.n4.nabble.com%2FRe-5-5-git-commit-flex-asjs-refs-hea
>ds-release0-8-0-distribution-updated-config-xml-files-used-by-Mae-tp61584p
>61588.html&data=02%7C01%7C%7Cbf98b3a329764c987b3608d49ad470cd%7Cfa7b1b5a7b
>34438794aed2c178decee1%7C0%7C0%7C636303684602850334&sdata=S2xvKEZMKIivtJ8n
>mWaq0NurHvHtUSxKAfV79rLFrQg%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

piotrz
Josh,

I'm building app through the Moonshine pointing to distribution, as an SDK.

Piotr
Apache Flex PMC
piotrzarzycki21@gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

piotrz
Sorry not the right thread :)
Apache Flex PMC
piotrzarzycki21@gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

Josh Tynjala
That's good information for this thread, though, since Alex started it in
response to one of your messages. Since you're building through Moonshine,
that means it's probably calling mxmlc. In that case, the compiler should
read flex-config.xml.

- Josh

On Sun, May 14, 2017 at 8:08 AM, piotrz <[hidden email]> wrote:

> Sorry not the right thread :)
>
>
>
> -----
> Apache Flex PMC
> [hidden email]
> --
> View this message in context: http://apache-flex-
> development.2333347.n4.nabble.com/FalconJx-Compiler-Options-
> was-Re-5-5-git-commit-flex-asjs-refs-heads-release0-8-0-
> distribution-updat-tp61594p61599.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

Alex Harui-2
In reply to this post by piotrz


On 5/14/17, 8:07 AM, "piotrz" <[hidden email]> wrote:

>Josh,
>
>I'm building app through the Moonshine pointing to distribution, as an
>SDK.

Ah yes, that is in fact the reason the compiler is reading flex-config.
The "distribution" is an attempt to have Maven generate a package that is
Ant and command-line friendly.

I suppose it is nice to be able to generate such a thing, but the Ant
build not only knows how to do this, but it can also run some basic tests
on the Ant tasks via Ant along the way.

Seems to me like we could rely on the Ant build to generate Ant artifacts
and an SDK for IDE users that will be using Ant, and ponder what an SDK
would look like for IDE users that want to use Maven from their IDEs and
have the distribution generate that.  I think there are Maven builders
that might plug into Flash Builder's embedded Eclipse install.  Don't know
about the other IDEs.

Of course, I could be wrong...
-Alex

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

Christofer Dutz
Hi guys,

Having had my first coffee of the day I think I am ready to operate under normal parameters ;-)

Unfortunately, I seem to have missed quite a lot of discussion. So, let me please sum up what I understood.

There seems to be problems with the templates in the maven plugin (that are used to generate the config files). Initially I copied the config files of the frameworks and added configuration options to the plugin for only those options I saw being used in the Ant build. Over time I added more and more config options, but not all. Ideally all options should be available in the configuration, defaulting to the values in the original config files.

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. 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.

Chris


Am 14.05.17, 16:03 schrieb "Alex Harui" <[hidden email]>:

   
   
    On 5/14/17, 8:07 AM, "piotrz" <[hidden email]> wrote:
   
    >Josh,
    >
    >I'm building app through the Moonshine pointing to distribution, as an
    >SDK.
   
    Ah yes, that is in fact the reason the compiler is reading flex-config.
    The "distribution" is an attempt to have Maven generate a package that is
    Ant and command-line friendly.
   
    I suppose it is nice to be able to generate such a thing, but the Ant
    build not only knows how to do this, but it can also run some basic tests
    on the Ant tasks via Ant along the way.
   
    Seems to me like we could rely on the Ant build to generate Ant artifacts
    and an SDK for IDE users that will be using Ant, and ponder what an SDK
    would look like for IDE users that want to use Maven from their IDEs and
    have the distribution generate that.  I think there are Maven builders
    that might plug into Flash Builder's embedded Eclipse install.  Don't know
    about the other IDEs.
   
    Of course, I could be wrong...
    -Alex
   
   

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

Alex Harui-2


On 5/15/17, 7:27 AM, "Christofer Dutz" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

Christofer Dutz
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" <[hidden email]>:

   
   
    On 5/15/17, 7:27 AM, "Christofer Dutz" <[hidden email]> 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
   
   

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

Alex Harui-2


On 5/15/17, 8:34 AM, "Christofer Dutz" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

Christofer Dutz
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" <[hidden email]>:

   
   
    On 5/15/17, 8:34 AM, "Christofer Dutz" <[hidden email]> 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
   
   

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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)

Alex Harui-2


On 5/15/17, 11:13 AM, "Christofer Dutz" <[hidden email]> wrote:

>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.

Good to know.  Thanks.

>
>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.

AIUI, for years there has been one flex-config-template.xml in the
flex-asjs/frameworks folder.  When you want to change defaults you change
it there.  Now there is also one in flex-falcon as well, which doesn't
quite seem right to me.  Would be nice if there was just one canonical
copy.  Plus, I think what is in flex-config-template.xml also ends up in a
pom.xml somewhere as well, in order to set the defaults for Maven.

Of course, I could be wrong.

-Alex

Loading...