Home/ Questions/Q 6652873
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T01:11:47+00:00

I have a Flash builder project that I am migrating from SDK 4.1.0 to

  • 0

I have a Flash builder project that I am migrating from SDK 4.1.0 to 4.5.1. This has been a relatively easy change (we are using maven for our builds, and were able to get a successful build after updating to the 4.5.1 dependencies).

As said, the project builds fine with maven and flexmojos. The issue is when opening the project in flash builder. The maven project is imported and then set as a flex project by running the maven flexmojos:flexbuilder build command.

The issue lies when certain mx components that are specified with the s: namespace are no longer accepted by the IDE, and result in an error. For example, for the following to compile:

<s:states>
    <s:State name="normal" />
    <s:State name="disabled" />
</s:states>

s:State must be changed to the mx namespace:

<s:states>
    <mx:State name="normal" />
    <mx:State name="disabled" />
</s:states>

This is just one example, and only happens for certain spark-namespaced components. Why is this? Why does this compile OK with Flex SDK 4.1.0 but not with Flex SDK 4.5.1, and what is the cause of the necessary namespace change?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve found the same problems using FlexMojos because it seems that Adobe did a little trick of specifying the spark namespace for mx components (like State and Spacer).

    Also, if you’re using flexmojos:flexbuilder, it means you’re also using an old version of FlexMojos (3.8?). There’s version 4.0 now (RC2), however, the flexbuilder goal has been removed for now.

    Anywho, back to your question, I see it the other way in my project (s:Spacer works in Flash Builder, not in FlexMojos). Personally, I feel that these namespace shouldn’t intersect and as a developer it’s easier to just specify the exact namespace and not bother with the namespace trickery.

    • 0