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.d...@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: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
