On 11/7/14, 7:10 PM, "Justin Mclean" <jus...@classsoftware.com> wrote: > >> because that’s how it will behave when published to flex.a.o. > >It may not. It may be a browser issue? It may be due to configuration of >web server/CI windows box? For instance I'd guess that the build by the >CI is not the same as the release candidate as it's using a different >version of Apache Flex (ie the head of develop?)
Well, I suppose anything is possible. Since you are the committer doing the most work on TDF, have you set up your local testing to use http:// instead of file://? That will enable you to do local testing in an environment that better matches the security sandboxing when deployed to flex.a.o and have solid evidence before having the entire community read your doubts about my analysis. > >> Also, have you investigated the Squiggly issue brought up yesterday [2]? > >Yes I brought that issue up myself several days ago and said it doesn't >occur locally. > >> I also get the exception. It could just be a bug in the CI server setup. > >As far as I can see the the ant script is using all of the correct >libraries eg for spark as compiler.include-libraries includes all code >the swf is they are used or not right? So that exception would be >basically impossible. Looks like the issue was case-mismatch in the Ant script. The Squiggly examples now work on the CI server. I am now satisfied with the source packages and its results in the release branch. I’d suggest that we get a few more folks over the next day or so to pound on it and more PMC members to examine the sources. If Flexicious doesn’t respond with bitmaps for their demo during that time, we will remove them from 3rdparty.xml, cut the release and add them back into the version on flex.a.o when they respond. Thoughts? -Alex
