On 8/15/12 6:29 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
> Hi Alex,
>
> I need more information than the brief sentence you gave describing the issue
> as I am not as familiar with Mustella as you are.
>
> Please raise a JIRA issue with the exact steps to reproduce and error message
> and I'll try and fix.
>
> I really don't think there is any need to revert code that was checked in
> before Mustella was donated especially when it's an issue with a test. Doing
> so it may break the SDK for anyone that happen to be using that feature.
>
> Thanks,
> Justin
Hi Justin,
As I said in the last post, it isn't an issue with the test. There is a
limitation in the linker that if two swcs have the same resource bundle
name, one will win and the other will lose. By adding an apache.swc with a
validator.properties bundle now all old MX and Spark validator.properties
bundles are not being linked in and tests are breaking.
If you run the mustella spark/validator/CurrencyValidator tests before your
commit they will pass, with your commit they will not. If we'd had mustella
and CI before your commit it would have caught you and you wouldn't have
committed.
I don't want to revert either, so let's choose one of the other two options:
1) rename the validator.properties bundle in apache.swc to something else
and fix up references
2) move the resources from apache.swc bundles to the framework.swc bundles.
The first option requires making up some less obvious name for a bundle of
validator resources. The second option needlessly fattens every app with
resource strings that may not be used and separates bundle management from
the swc. Which is not very modular, but I noticed we already cheated that
way for spark.swc.
I don't think this needs a JIRA issue. But it does raise an good question:
are we even supposed to create JIRA issues for problems found in commits?
Anyway, pick an option and if you are backlogged and can't get to it today
let me know and I will do it tomorrow so I can see what other validator
tests are breaking for other reasons.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
