FlexUnit Compatibility (was FlexUnit 4.3)

["Michael A. Labriola" <la...@digitalprimates.net>]

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

RE: FlexUnit Compatibility (was FlexUnit 4.3)

["Michael A. Labriola" <la...@digitalprimates.net>]

Chris,

FlexUnit was an independent open source project with a bunch of contributors, so when I said, 'we', I mean the people that developed and maintained FlexUnit.

Here is a quick summary of the issue:

* Flash Builder ships with a couple of jars that include its FlexUnit support
* In those jars, they have buried some ActionScript templates which they use to generate a wrapper that wraps FlexUnit 1.x or 4.x so that it could use either
* The wrapper instantiates the FlexUnit core and stores it as a private variable
* The wrapper doesn't have any hooks to access the FlexUnit core directly

This causes a few issues.

* FlexUnit was designed to have configuration parameters passed to the core, which we can't access
* Without the ability to have information passed to the core, we get into a dependency lookup scenario, which becomes problematic with variable dependencies

As a concrete example of the latter:

In an AS-only application, we need to get a reference to the stage, and add a movieclip, to allow the UI testing to occur
In a Flex application, we need to get reference to the top level application, and add a container, to allow the UI testing to occur

The FlexUnit core doesn't really care, it allows you to pass whatever you like, however, since we can't pass config parameters to the core, FlexUnit tries to 'decide' what's going on, so if it doesn’t see any flex related classes, it assumes its AS only.... and there are actually issues trying to get to the stage. If it’s a Flex 3 application, it tries to add an mx..Container. If it’s a mixed mx/spark app, it tries to add an mx..Container. If it’s a Spark only app, it tries to add a Group. This is my major thorn in fixing the new application domain thing, because I can't do these checks anymore in this way and really wouldn't want to anyway.

This has been a thorn in my side since Flash Builder shipped with this support because it's made us have to compromise and work around things. Further, a good portion of the functionality isn't available to all users because they never have access to configure the core and I am not sure how we can get to the separate application domains. That said, I also assumed we wouldn't want to break Flash Builder support, but it means we would need to do one of two things:

1) Patch the jars that ship with Flash Builder to change this template and associated madness.
	a) If we did so, we would no longer have any issues regarding separate builds and application domains could work with minimal changes
 	b) there are also 5 or 6 known bugs that would effectively disappear and I would be much happier with the state of it all
2) Figure out a new way to 'lookup' our state but I fear that there will always be a caveat with this approach
	a) we could invent some new meta data on the suite which indicates the environment
	b) we could try to invent some new way to get the stage in an AS only application
	c) I am not sure we can ever eliminate all of the issues

Mike


-----Original Message-----
From: Christofer Dutz [mailto:christofer.dutz@c-ware.de] 
Sent: Sunday, April 19, 2015 2:55 AM
To: dev@flex.apache.org
Subject: AW: FlexUnit Compatibility (was FlexUnit 4.3)

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:labriola@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

AW: FlexUnit Compatibility (was FlexUnit 4.3)

[Christofer Dutz <ch...@c-ware.de>]

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:labriola@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