Even later update on the "New Project" issue: I think I have successfully patched a jar in FlashBuilder to get around this problem.
The patched jar and a readme is up on http://people.apache.org/~aharui/FlashBuilder/ Can a few folks try it so we know it works? I think it will only work with FlashBuilder 4.7 (and not 4.6). Then we'll discuss what to do next. -Alex On 7/29/13 5:45 PM, "Alex Harui" <aha...@adobe.com> wrote: >Latest update on the "New Project" issue: > >I think I've found the offending code for real this time. There is code >for a version check that checks that the Flex version is less than 5.0.0 >by doing: > > major * 100 + minor * 10 + micro > >This means that we don't have the option to change to Apache Flex 5.0.0 to >get around this problem, and further means that someday when we really >mean to do 5.0 we'll have this problem again. > >There is a class called MXMLVersion2009.java that creates an instance of >org.osgi.Framework.Version like this: > > init(..., ..., > new Version(4,5,0), new Version(5,0,0), new Version(4,0,0)); > >It looks like the expectation was that these versions would get updated >when FB had synchronized releases with Adobe Flex SDKs. We need to go in >an change that 5 to something larger somehow. > > >I am passing the same information on to the FB team at Adobe. > >-Alex > >On 7/29/13 7:46 AM, "Scott Guthmann" <sc...@on3solutions.com> wrote: > >>>I am hoping we're going to release something other than RC3 which means >>>we have a few more days before we would release. Here's my latest >>>update on the 3 issues: >>> >>>1) ResourceModule via FlashVars: Yes it affects a small population of >>>the total Flex SWFs in the world, but at least two of folks who took the >>>time to try the RC found it. I have a fix ready to go. >>>2) This FB Issue. I am trying to get a response from the FB team. And >>>I'm looking through their source to try to find the actual cause. If we >>>cut another RC, we should at minimum update the release notes in the >>>>kits themselves to describe this issue and its workaround. But maybe >>>>by the time we get the next RC ready we'll have more information. >>>3) The Ilist issue. The bug author's workaround was to stop using >>>DataList. Not everyone has the luxury of doing that, so IMO, we really >>>don't have a workaround. And this will affect LCDS customers. I think >>>we >should revert the change to Ilist, but we don't have to revert the >>>change to ListCollectionView. >>> >>>So, I would prefer we cut another RC at least to address #1 and #3, and >>>maybe we'll come up with a better plan for #2 during that time. >>> >>>-Alex >> >>To release or not to release - that is the question.... >>+1 to Alex's approach. Strategically, it is better to release something >>that provides developers with a good user experience. Releasing something >>that requires deletion of files to work right or a patch to several of >>the IDEs that are standard is a bad idea. Some of the goals we should >>have when we test to determine if the RC should move forward: 1) Does the >>SDK RC work smoothly on mac, windows, and Linux? 2) Does the AIR >>installer work smoothly on mac, windows, and linux? 3) do the binary >>distributions work smoothly on each of these platforms? 4) Are the manual >>builds of the SDK and the binary versions supported by the top IDEs: >>IntelliJ, Flash Builder, Flash Develop, and FDT? >> >>My opinion is that we are not adequately evaluating if the RC versions >>are meeting these developer user experience questions when voting on an >>them. The community millions of devs are not as capable of the patching & >>work arounds as you guys are. The best marketing you can do is creating a >>feature rich product that is easy to use for any skill level - make it >>simple (which is difficult to do). >
