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: [LAST CALL] Release FlexJS/FalconJX 0.8.0
Date Fri, 12 May 2017 14:08:49 GMT
Maven is a lot more than pom files ... I would strongly object almost all options in this email.

Requiring ant to build Maven is a complete no-go for me.I didn't put that much effort in the
project just to let this dependency in again.

Re implementing Maven in falcon is also a no-go as it would require re implementing Maven
in falcon, which is also out of the question.

An option would be to finally clean up the config code of falcon and to inject a clean configuration
model from the outside. That could then be done from the Maven plugin. I didn't want to use
the config files, but the config code is such a mess with statics and strange code, that it
was the only option. My suggestions to clean up were reduced to simple itches only I was having.

Generally I would rather opt for finally going down the Maven-first path and to maintain the
ant build as a convenience package. Then we wouldn't have to re-sync all the time. The current
way (some writing on Ant, some on Maven) produces far too many pains.


Von meinem Samsung Galaxy Smartphone gesendet.

-------- Urspr√ľngliche Nachricht --------
Von: Alex Harui <aharui@adobe.com.INVALID>
Datum: 11.05.17 20:04 (GMT-05:00)
An: dev@flex.apache.org
Betreff: Re: [LAST CALL] Release FlexJS/FalconJX 0.8.0

Hmm.  How far off are they?  I'm not sure I have the cycles to try to
reconcile this if we want to have a release by the Summit.

AIUI, the maven -config files are generated by the Maven Mojos.  If we
generate the -config files as part of the Ant build, then you can't just
clone the repo, unpack the release and open the FB projects for the SWCs
and have them work without running a build to generate them.  That's a
different workflow, so we should make sure folks want that before we go
and do something like that, and that seems too risky this late in the
release cycle.

One idea I had in the future is to teach Falcon to read the pom.xml files
and do away with the -config.xml files.  I've already taught Falcon to
read Flash Builder project files so there is precedence for doing
something like this.  Volunteers are welcome to take this on, but again,
seems too risky for this release.


On 5/11/17, 2:09 PM, "Josh Tynjala" <joshtynjala@gmail.com> wrote:

>It seems that the Maven -config.xml files are not a simple copy/paste.
>They've been modified a bit. In a Maven distribution, the manifest XML
>files are copied to a different location. The Maven distribution does not
>include the original ActionScript source code and things from
>frameworks/projects, so I guess the manifests were moved to
>frameworks/manifests instead. The Maven build should probably copy all the
>ActionScript source code, though, and then it can use the same -config.xml
>files as the Ant build.
>- Josh
>On Thu, May 11, 2017 at 1:58 PM, Josh Tynjala <joshtynjala@gmail.com>
>> For some reason, the Maven build duplicates a number of files from
>> flex-asjs/frameworks in
>> It seems that these duplicates have gotten out of sync after the "dual"
>> changes.
>> It would probably be better if there were one canonical source for these
>> files that is used by both Ant and Maven builds because it seems easy to
>> forget to update both locations. A while back, when I was testing the
>> VSCode extension, I discovered that the Maven SDK contained some
>> *-config.xml files had some differences that caused issues too. I fixed
>> them at the time, but it's probably not good if this is becoming a
>> problem.
>> - Josh
>> On Fri, Apr 21, 2017 at 9:54 PM, Alex Harui <aharui@adobe.com> wrote:
>>> Hi,
>>> It's been six months or so since 0.7.0 and it would be nice to get a
>>> release out before/at ApacheCon.
>>> I have just seen the dual branch build successfully for both Ant and
>>> when merged with the develop branch as of yesterday.
>>> works ok, there are some sizing issues, and I will be going through the
>>> other examples and tuning them up.  In the mean time, it would be great
>>> for folks to poke at the dual branch before I merge it into develop.
>>> Once dual is merged with develop, I'll create the release branch and
>>> release builds.
>>> The only other "must do" I know of is to make sure we've removed the
>>> dependency on org.json.
>>> What else do we need to get done before we release 0.8.0?
>>> Thanks,
>>> -Alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message