Flex3 HtmlWrapper Ant Task Fix
Who is the moron that thought this was a good idea?
getClass().getResourceAsStream(TEMPLATE_DIR + templates[0] +
WITH_HISTORY + INDEX_TEMPLATE_HTML);
And how do these geniuses get jobs? Much less hold them? Ugh.
Here’s the skinny. I was trying to use the HtmlWrapper task that ships with the Adobe Flex3 SDK. At first, I installed the .jar just like I would with any other Ant task. I dropped flexTasks.jar into /usr/share/ant/lib, and referenced the property file with a taskdef. Way too easy.
I managed to get mxmlc working with Ant 1.7 (forcing a fork=”true”), which was just fine, since I’ll be compiling multiple mxml files, and wanted to do it with a <foreach> (ant-contrib task) with parallel execution. I’m a bit of an Ant freak, in case you hadn’t noticed. So I was able to compile flash apps. Sweet. Now, I wanted to get the HtmlWrapper bits working, from the same ant script.
No go. I was getting NullPointerExceptions when it tried to read in the templates. Yikes.
There’s a few issues with the Flex3 SDK as it ships. Specifically there are problems in the HtmlWrapper task.
- The TEMPLATE_DIR constant is incorrect. It referenced a directory that does not exist in the flex3 SDK.
- The moron that wrote the code expected the template directories to be in the classpath of the java process running the Ant task.
Number one was careless. Number two was naive, ignorant, and so stupid that it goes beyond my comprehension.
So, I fixed it. Here’s an updated flexTasks.jar that you can use. Here’s an updated HtmlWrapperTask.java source for the Ant task. And here’s an explanation of what I changed.
- The TEMPLATE_DIR is correct. “/templates/” Ohhh, that was hard, right?
- I added a property, sdkHome, which can be set on the task. This should be the absolute path of the flex SDK on your system. On mine, it’s “/usr/share/flex_sdk_3″. This is pre-pended to the TEMPLATE_DIR path, which is then loaded with FileInputStream. So that you can load the templates from -anywhere- on the system, without them needing be in the current JVM classpath. I still can’t believe someone did that. Ugh.
With these changes, I’m getting the expected results. Yay!
