[#SDK-15466] Embed asset source starting with "/" works in FlexBuilder, but not in mxmlc

Flex SDK

Embed asset source starting with "/" works in FlexBuilder, but not in mxmlc

Created: 05/06/08 02:49 AM Updated: Yesterday 05:11 PM

Component/s:

MXML Compiler

Security Level:

Public (All JIRA Users )

File Attachments:

BugDemo.zip (211 kb)

Severity:	Incorrectly Functioning with Workaround
Reproducibility:	Every Time
Discoverability:	Medium
Found in Version:	SDK Flex 3 (Released)
Milestone:	SDK Flex 3.1.0
Affected OS(s):	All OS Platforms - All
Steps to Reproduce:	« Hide Steps to reproduce: 1. Create a new project called BugDemo in FlexBuilder. Create a folder src and set it as the main source folder. Save the following as the file BugDemo.as in the src folder and set it as the default application file: package { import flash.display.Sprite; public class BugDemo extends Sprite { //using relative path works correctly in flex builder and mxmlc [Embed(source="../src_other/flex_header.jpg")] public static var embeddedAsset:Class; //absolute classpath works correctly in flex builder, not in mxmlc // [Embed(source="/flex_header.jpg")] // public static var embeddedAsset:Class; public function BugDemo() { var other:Other = new Other(); addChild(new embeddedAsset()); } } } 2. Create the folder src_other. And add it as an additional source folder. Save the file flex_header.jpg in the folder src_other. Save the following as the file Other.as in the folder src_other: package { public class Other { public function Other() { trace("Other Instantiated"); } } } 3. In a terminal window, navigate to the root project folder and the swf should compile successfully using the line mxmlc src/BugDemo.as -sp+=src_other 4. In the file BugDemo.as, comment out the definition for embeddedAsset:Class lines and uncomment the second definition. Try and compile again using mxmlc Actual Results: Project fails to compile with mxmlc, but will compile successfully using FlexBuilder. Expected Results: According to page 965 of the Flex Developer Guide: "If the path starts with a slash character, Flex first searches the directory of the MXML file for the asset, and then it searches the source path. You specify the source path to the Flex compiler by using the source-path compiler option. For example, you set the source-path option as the following code shows: -source-path=a1,a2,a3 The MXML file a1/testEmbed.mxml then uses the following code: <mx:Button label="Icon Button" icon="@Embed(source='/assets/logo.gif')"/> Flex first searches for the file in a1/assets, then in a2/assets, and then in a3/assets." mxmlc should check all the source paths for the embedded assets when using the slash notation. it appears to only support relative paths. Workaround (if any): Use relative paths instead of absolute paths for embedding assets. Show » Steps to reproduce: 1. Create a new project called BugDemo in FlexBuilder. Create a folder src and set it as the main source folder. Save the following as the file BugDemo.as in the src folder and set it as the default application file: package { import flash.display.Sprite; public class BugDemo extends Sprite { //using relative path works correctly in flex builder and mxmlc [Embed(source="../src_other/flex_header.jpg")] public static var embeddedAsset:Class; //absolute classpath works correctly in flex builder, not in mxmlc // [Embed(source="/flex_header.jpg")] // public static var embeddedAsset:Class; public function BugDemo() { var other:Other = new Other(); addChild(new embeddedAsset()); } } } 2. Create the folder src_other. And add it as an additional source folder. Save the file flex_header.jpg in the folder src_other. Save the following as the file Other.as in the folder src_other: package { public class Other { public function Other() { trace("Other Instantiated"); } } } 3. In a terminal window, navigate to the root project folder and the swf should compile successfully using the line mxmlc src/BugDemo.as -sp+=src_other 4. In the file BugDemo.as, comment out the definition for embeddedAsset:Class lines and uncomment the second definition. Try and compile again using mxmlc Actual Results: Project fails to compile with mxmlc, but will compile successfully using FlexBuilder. Expected Results: According to page 965 of the Flex Developer Guide: "If the path starts with a slash character, Flex first searches the directory of the MXML file for the asset, and then it searches the source path. You specify the source path to the Flex compiler by using the source-path compiler option. For example, you set the source-path option as the following code shows: -source-path=a1,a2,a3 The MXML file a1/testEmbed.mxml then uses the following code: <mx:Button label="Icon Button" icon="@Embed(source='/assets/logo.gif')"/> Flex first searches for the file in a1/assets, then in a2/assets, and then in a3/assets." mxmlc should check all the source paths for the embedded assets when using the slash notation. it appears to only support relative paths. Workaround (if any): Use relative paths instead of absolute paths for embedding assets.
Language Found:	English
Bugbase Id:	none
Triaged:	Yes
Regression:	No
QA Owner:	Gaurav Jain
Participants:	Gaurav Jain, Jonathan Marston, Jono, Jose Rojas, Lauren Park, Matt, Peter deHaan and Robert Ames
JDK:	Sun 1.5.x

All

Comments

Sort Order:

[ Permlink | « Hide ]

Jonathan Marston - [05/06/08 03:02 AM ]

The issue has been reported in the flexcoders list as well

http://tech.groups.yahoo.com/group/flexcoders/message/103050

[ Permlink | « Hide ]

Gaurav Jain - [05/07/08 09:40 PM ]

Not an injection.

A similar bug was fixed for css during flex 3 in changelist #181629

[ Permlink | « Hide ]

Matt - [05/09/08 05:16 PM ]

whats "Not an injection"?

[ Permlink | « Hide ]

Robert Ames - [05/09/08 05:22 PM ]

This prevents us from embedding assets in automated builds. Please to fix.

[ Permlink | « Hide ]

Peter deHaan - [05/09/08 05:24 PM ]

Matt,

"Injections" usually mean that something worked previously but then a changed caused something to break in a newer build.
Not an injection means that this behavior isnt new to Flex 3, and existed in earlier versions/builds.

Peter

[ Permlink | « Hide ]

Matt - [05/09/08 05:26 PM ]

I see. So why would this problem not occur when compiling with Flex Builder? I figured Flex Builder just uses mxmlc.

[ Permlink | « Hide ]

Jose Rojas - [05/17/08 01:06 PM ]

As Robert Ames mentions, this bug prevents automated build scripts, like Ant, to create embedded asset statements using resource paths from another directory other than the current source file. This is a very common action in automated builds scripts, so please fix these bug.

I'm running into the problem as well and noticed that a somewhat hacked workaround is to embed the absolute path into the Embed statement, instead of a proposed relative one that should be resolved via the -source-path compiler option.

I guess the code in the compiler is assuming that "/" at the beginning should really look at the absolute file path instead of a relative one.

[ Permlink | « Hide ]

Lauren Park - [06/18/08 08:27 PM ]

Opened to Jono.

[ Permlink | « Hide ]

Jono - [07/03/08 05:11 PM ]

Here's what's happening.

Overview:
---
FB provides a custom PathResolver (com.adobe.flexbuilder.project.ProjectSourcePathResolver) to MXMLC for resources/embeds. It uses Eclipse/FB's path resolution code and provides a real File object given a path. Paths that start with a "/" have special meaning, relevant "to page 965 of the Flex Developer Guide" as stated above -- they basically work that way in Eclipse, slash means root of the project and can be relative or on the source path. Which is why it works in FB.

In MXMLC, the code which does the same thing (for both Embed and @Embed, so we need to add test cases and fix it for @Embed too) has a very descriptive comment which explicitly does not provide this functionality. It only adds the relative source path of the main mxml/as file, and the 'owner' path, whatever that means (IFF the owner is a path resolver, if the owner is a SourceList, etc., then nothing happens).

I spent a while trying to get access to the source path (specified in Configuration), in EmbedUtil where the resolution code lives. Unless the 'owner' should encapsulate it somehow. Unless 'owner', Source, or CompilationUnit have access to source path, there's really no way to get at it in EmbedUtil without serious refactoring.

Commentary:
---
I don't know how these docs got written, but the code in MXMLC doesn't seem to ever have known it was supposed to do this. Further, I don't know if the syntax for this is workable...

Absolute paths on a mac start with a slash -- granted we could improve the logic in mxmlc, but it's currently written to only check if it starts with a slash.

Also, I'm not sure what the EXACT semantics are supposed to be. I assume we're supposed to search all source paths for a file name -- what if there are collisions in the name, you can surely have two jpgs of the same name in two different source paths. I don't know how FB resolves this situation, but there's a good chance there will be a disparity in functionality if we implement it here, unless we ask FB to NOT resolve resources anymore, and have mxmlc do it.

Is the workaround of "../" really not feasible? Can "./" be used for the current directory? I don't see why an image should be found "on some source path" -- is there a reason that someone cannot specify a relative path?

Resolution:
I feel like we should deprecate this functionality and update the docs. Or someone knows a technical reason that we can implement this feature in a desired way based on what I wrote above, and/or we come up with a better syntax like "sp:/".

[ Show » ]

Jono - [07/03/08 05:11 PM ] Here's what's happening. Overview: --- FB provides a custom PathResolver (com.adobe.flexbuilder.project.ProjectSourcePathResolver) to MXMLC for resources/embeds. It uses Eclipse/FB's path resolution code and provides a real File object given a path. Paths that start with a "/" have special meaning, relevant "to page 965 of the Flex Developer Guide" as stated above -- they basically work that way in Eclipse, slash means root of the project and can be relative or on the source path. Which is why it works in FB. In MXMLC, the code which does the same thing (for both Embed and @Embed, so we need to add test cases and fix it for @Embed too) has a very descriptive comment which explicitly does not provide this functionality. It only adds the relative source path of the main mxml/as file, and the 'owner' path, whatever that means (IFF the owner is a path resolver, if the owner is a SourceList, etc., then nothing happens). I spent a while trying to get access to the source path (specified in Configuration), in EmbedUtil where the resolution code lives. Unless the 'owner' should encapsulate it somehow. Unless 'owner', Source, or CompilationUnit have access to source path, there's really no way to get at it in EmbedUtil without serious refactoring. Commentary: --- I don't know how these docs got written, but the code in MXMLC doesn't seem to ever have known it was supposed to do this. Further, I don't know if the syntax for this is workable... Absolute paths on a mac start with a slash -- granted we could improve the logic in mxmlc, but it's currently written to only check if it starts with a slash. Also, I'm not sure what the EXACT semantics are supposed to be. I assume we're supposed to search all source paths for a file name -- what if there are collisions in the name, you can surely have two jpgs of the same name in two different source paths. I don't know how FB resolves this situation, but there's a good chance there will be a disparity in functionality if we implement it here, unless we ask FB to NOT resolve resources anymore, and have mxmlc do it. Is the workaround of "../" really not feasible? Can "./" be used for the current directory? I don't see why an image should be found "on some source path" -- is there a reason that someone cannot specify a relative path? Resolution: I feel like we should deprecate this functionality and update the docs. Or someone knows a technical reason that we can implement this feature in a desired way based on what I wrote above, and/or we come up with a better syntax like "sp:/".