Hi Michael, I doubt that people here on the list will support the "dropping of FB compatability" as it still is one of the major IDEs for building Flex applications.
I have to admit that I didn't quite grasp the problem you were having. Did I get this correct: With "we" you are refering to you and the company you work for? Would It be possible to rearange things? Sort of having a nice and tidy core library and have one fb-compatability lib to make FB work with FlexUnit? If you could provide a little more details, perhaps we could work out an option 4 Chris -----Ursprüngliche Nachricht----- Von: Michael A. Labriola [mailto:labri...@digitalprimates.net] Gesendet: Sonntag, 19. April 2015 05:06 An: dev@flex.apache.org Betreff: FlexUnit Compatibility (was FlexUnit 4.3) Question for the group: The FlexUnit dependencies could be a lot cleaner but right now we have static classes that reach out to try to figure out if it's an AS only application or a Flex application among other things. The reason we do this is that Flash Builder has a wrapper for the FlexUnit classes they generate. It doesn't allow any direct access to the FlexUnit core which is where things are configured. So, as we tried to keep the FlashBuilder compatibility and add features, we had to do so knowing we couldn't get things passed in... so... here is the question: I can make this all cleaner and so much easier... but doing so will break compatibility with Flash Builder. Long ago, we actually decompiled the Flash Builder jars and provided Adobe a fix that would let us handle this better but there wasn't traction to ever get it released. So, we could 1) break compatibility and then subsequently provide some solution via a hacky flash builder change.... 2) drop compatibility altogether with flash builder 3) leave it alone and continue to build two versions of the project as we do now, one with and one without Flex dependencies Thoughts on impact in the current ecosystem? Mike
