> Forking the Google code to our project doesn't seem like the best option. Yes, that what concerns me too.
> We may consider donating your solution to the Closure project, which is > Open Source... That may be a solution in the long term but I am not sure that helps to fix the bug in Falcon compiler right now. Anyway submitting a patch to Closure will require more work on my part. Although the bug fix I propose is generic for PathUtil I still did not examine all the dependencies from that class in the Closure itself and am not sure my patch is generic enough and correct for the Closure itself. Honestly I would rather not digress and stay concentrated on contributing to Flex. > Keep what you have, please, but don't push it to the 'develop' branch. > You're probably the smartest person that will work on it, but we need to > take care that we don't end up with a dependency on a fork of the closure > tools where we actually want to be able to use their releases. I guess that means I will keep my patch for myself only until either somebody else needs it or a better way to fix this bug is found. > For FalconJX the main goal is to write tests for both MXML and AS parsing. At > the moment there are some areas that are written specifically to allow for > the correct parsing of the FlexJSTest_again example. This obviously is not > "ideal" ;-) We need to make sure that all code is generic (or as much as > possible) and that all output is properly tested so we don't kill any existing > output when refactoring or adding code. Right now, there is only 2 tests > specific for FlexJS MXML output, and those are "@Ignore"d. > > > But first, just look around, review what's there and see if what I/we did > makes sense. OK, I will spend a few more days just getting familiar with the code base and see if I can find and fix some other bugs before trying to make functional changes to the compiler. Tigran.
