Occasional Thoughts

When reading through ActionScript code I frequently see two ActionScript mistakes that are likely to cause runtime misbehavior and confusions. Sometimes thing do not appear at first glance what you might think at the beginning. However both ActionScript bumps can easily be driven around. 

I'm glad to be able to depricate my own post Groovy++-with-Maven a couple of weeks ago. The Groovy++ team has already taken action and provides the groovvypp libraries in a commonly accessible repository. They also provide a preliminary version of the gmaven plugin that supports statically linked Groovy.

For details see Using-groovypp-with-maven  and also the related update Using-groovypp-with-maven (update).

Please see my update Official-Maven-support-for-Groovypp.

If you are already a fan of Groovy you probably will also be a fan of the rising star Groovy++. Even people that dislike the dynamic magic of Groovy must agree, that this is cool stuff, mixing the power of Groovy with the safety and performance of classical Java. Since Groovy++ is still brand new it lacks of any Maven support today. In the following I will show how you can tweak the GMaven plugin for using the Groovy++ extensions.

Please be aware that this is just a very quick work to get it running and might not be stable. For example I did not verify all the necessary dependencies. So further work has to be done.

Spring Actionscript is a great library - no question. It makes it much easier to mock Cairngorm service delegates and rewire them for testing with FlexUnit. Testing the full event/command/delegate workflow is pretty easy.

However today I had quite some "fun" with the Maven artifact and it's transitive dependencies in combination with Maven 2.2.1. Spring Actionscript has some dependencies to these artifacts:

• as3commons-lang
• as3commons-logging
• as3commons-reflect

Maven module structure of the project.

You can see that there is one high level library (library A) that is shared across all applications and a more specialized library (library B) that is providing components and classes to a certain subset of other applications.

Library A contains a couple of embedded images containing various icons and a lot of components, while Library B contained just a few components. So after compilation the obvious expected result would be to have an RSL file of library A that is much bigger than the RSL file of library B in case library B uses library A as RSL and not as statically linked SWC.

Well the dynamic linkage worked well for all the applications, which where just a couple of KBs in size after the change in contrast to more than 1 MB before the change. However this was not the case for the libraries. Library A had a size of 1.2 MB but library B had a size of 1.25 MB???