Ah, and a good way to start would be to create a JIRA ticket about the need for a better README and to attach a patch for that issue with the content of what you wrote in your original email. That should get you (and us) going on the road of coding and patching and will go some way towards getting you to committer-ship ;-)
EdB On Tue, Apr 9, 2013 at 6:46 AM, Erik de Bruin <e...@ixsoftware.nl> wrote: >> The other approach is to copy the DepsGenerator and PathUtil classes to >> FalconJX code base and fix it there. Technically this approach works, I >> tried it. The fix to PathUtil is trivial to do, only a few lines must be >> modified to make it handle Windows paths correctly. I did not need to touch >> DepsGenerator except to change the import to use 'our' fixed PathUtil. After >> the fix is applied compiling FlexJSTest_again works and produces correct >> deps.js on Windows and the example then runs fine in the browser. > > Forking the Google code to our project doesn't seem like the best > option. We may consider donating your solution to the Closure project, > which is Open Source... > >> Please let me know if what I am doing makes any sense or I should scrap what >> I did so far and wait for someone smarter than me to work on this. > > 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. > >> Is there any ToDo list for FalconJX so that I can go ahead and try to work >> on some outstanding issues? I now have Falcon projects in my Eclipse, git is >> configured and am now ready for a bit more serious work. > > 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. > > EdB > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
