 |
History
| Log In
|
|
|
|
Not an injection.
A similar bug was fixed for css during flex 3 in changelist #181629 This prevents us from embedding assets in automated builds. Please to fix.
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 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. 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:/". Jono:
I see the challenges that you bring up about the "/" functionality. I believe using a starting "/" in the resource patch to indicate a source path search conflicts with Mac and Linux operating systems where you may actually want to reference a file in an absolute path, not through the "-sourcepath" mechanism. I feel that the original functionality should have used a starting "/" to indicate absolute file paths (the way it does now in MXMLC) and ones without it to be relative paths. The default relative path should be the current directory. The "-sourcepath" should be an override to the default search path for relative paths, allowing you to indicate other directories to look in for cases where the starting "/" is not used. The order in the directories in the source path should indicate the search order preference... collisions are not considered, only the first matching path name is used. Of course this conflicts with FB's current functionality due to some Eclipse quirkiness. Something to consider though... if you are using MXMLC directly, you probably won't be using FB, so a functionality divergence may not affect many developers. I disagree that the functionality can diverge -- both tools should work the same way, and generate the same SWFs. Often ANT is used for automated builds whereas FB is used for development.
The source path doesn't work "in definition order" like many other compilers -- which I never agreed with, but that's how it works for now. Is there an argument that an absolute or relative path CANNOT be used in the use-case for this bug? If you are adding the folder to the source path, why can't you use that same folder in the embed? Jono:
Agreed... it's best that both tools should work the same way. IMO, a starting "/" should indicate an absolute path to file, just like on Linux,Unix, or Mac OSes. Relative searches without a starting "/" should use the source path for resolutions (or default to the current directory). This is contrary to the current docs of course, but that just seems to make the most sense with all things considered. As to why the use case for source path is handy, I can't speak for everyone, but it certainly is a useful feature in automated builds where you might store different binary assets in different directories but reuse the same file names. You might want to reskin Flex buttons globally by simply switching the source path directory to point to a different skin asset. With one easy step you can alter the global assets your SWF will use without having to re-path all of the assets in the source code. Doing so by hand is tedious and having Flex handle it is a convenience. Without it, my workaround was to do what you are suggesting... make my build manually add the absolute path prefix to each file path. The benefit to having multiple directories in the source path is as a fall back mechanism. In a real world case, you may want to port your SWF based on some extra criteria, like the web site it will appear on, or the resolution or quality of the Flash content. You will most likely have most of your common assets that are always the same in one directory and the special case overrides in another. In that case, you may want overriding assets in a primary directory on the source path, but fall back ones that are the most common denominator for all builds in a secondary path. The source path feature as described in the Flex docs helps implement something like this in a dynamic build very well. Without this, developers have to basically write this functionality on their own as preprocessing step. The use case which prompted this bug:
1) Developing multiple flex projects in a heterogenous environment, consisting of multiple developers who use different tools and operating systems. Some developers on the team are using flex builder, others use vi. Deployment is done with an Ant script. 2) Graphics and sound assets are shared between the different flex projects and stored in a common location, outside of the directory structure of each flex individual flex project. 3) Desire to have freedom to move/refactor views and other code which use the embeded assets. The problem with the current situation is that absolute paths don't work between different developers, and relative paths are cumbersome and prone to breakage when refactoring, much as how using relative paths to describe image locations on an html site can be a big problem. Sharing the assets between different projects means that the assets will outside of the project's main source path. At present, the only way to do this in our environment is to use relative paths. Agreed that using a leading '/' to indicate that the source paths should be checked is problematic because it does not leave a way to distinguish between checking source paths and an absolute path on *nix operating systems. Proposed solution: search all source paths for a specified assets, following any subdirectories used in the embed path. First matching asset found is used and don't worry about conflict resolution. The functionality described in the documentation would be the perfect solution for our use case, and allow us to have a robust development environment. Would it be possible to create a workaround for this issue by using the flex2.tools.oem.Application class and writing a custom PathResolver for it that mimics the behaviour of the way eclipse resolves the paths?
Unlikely. As I said before: "slash means root of the project and can be relative or on the source path. Which is why it works in FB." MXMLC has no idea what a project is -- nor what the path of one would be. You could certainly provide your own pathresolver locally, or try implementing Paul's suggestion above, and hack it to work. If it's general enough, submit a patch.
WTF! Flex 4! We can't wait that long. This isn't that hard to fix. This is a serious enough issue for development teams that you should fix it in Flex 3. It used to work in Flex 2. Why not fix this in Flex 3?
I'm trying to automate my compilation for my build server and automated deployment, and I'm running into this. If we don't have a fix for this we'll have to build our code manually using FB which is a real pain for us. There's a lot of wacky stuff being bantered around here on these comments. I think the requirements are pretty darn simple. Make it work like FB. The only thing that makes sense is to have mxmlc prefix source paths for all references starting with "/". Relative references (i.e. not starting with "/") would be relative to the current file being compiled. I don't know how that lines up with the documentation in the SDK so I defer to it if my relative suggestion isn't quite right. It's pretty simple implementation: public File resolveAssetPath( String assetPath, File fileYouFoundTheAssetReferenceIn, List<File> sourcePaths ) { if( assetPath.startsWith("/") ) { Iterator<File> sourcePathIterator = sourcePaths.iterator(); do { List<File> candiates = new ArrayList<File>(); File sourcePath = sourcePathIterator.next(); File asset = new File( sourcePath, assetPath ); if( asset.exists() ) { candiates.add( asset ); } } while( sourcePathIterator.hasNext() ); if( candiates.isEmpty() ) { throw new CompliationException("Could not resolve asset " + assetPath + " for transcoding." ); } else if( canidates.size() > 1 ) { System.out.println("Warning: We found two or more possible assets for " + assetPath + " in file " + fileYouFoundTheAssetReferenceIn + " located at: " + join( candiates, ", " ) + ". Using the first reference found: " + candiates.get(0) ); } return candiates.get(0); } else { return new File( fileYouFoundTheAssetReferenceIn, assetPath ); } } Conflicts could generate a warning, but I wouldn't let indecision around conflicts hold you up from fixing this. Consolidate/Encapsulate the code inside mxmlc so you can't run into these types of problems in the future. Make it work like FlexBuilder, and just fix it in Flex 3. It is not as simple as that. You have to realize that fundamentally FB is doing something the commandline cannot do -- it can emulate it, given extra information, but we cannot CHANGE shipped behavior. It will break compiles for *other* people. We can break compatibility in Flex 4 (though this is not a goal).
If you have a fix that works for you, patch your build machine's SDK -- that's definitely encouraged with open source. I'm sure others can use it too. My use case is exactly the one described by Jose. I'm reskinning an application by switching the source path; I've got a folder for each site, and under each folder is a matching set of resources. I just switch paths and rebuild with the new resources.
I wouldn't have done it this way had I known that MXMLC wouldn't support it (I don't use project dependencies for the same reason). I assumed that a source-path was a source-path. As to breaking existing functionality--were this introduced as a patch to Flex 3, couldn't it be only conditionally applied if another compiler option were set (e.g. --use-absolute-source-paths or whatever). That would enable those of us who can't build with MXMLC to do so, and it wouldn't affect the behavior for anyone who didn't want to use it that way. I realized that might be a hack and I've given it all of 30 seconds' thought, but there really ought to be a way to make this work. @jono http://bugs.adobe.com/jira/browse/SDK-15466#action_196026
The real bug is in your statement: """You have to realize that fundamentally FB is doing something the commandline cannot do.""" Howabout just fixing that? Or how / why did that come to pass in the first place? While rebuilding the SDK from source sounds like a lot of fun (and not something a lot of people are going to want to undertake), if you're so worried about backwards compatibility, why not just make it easier to mix-in resolver behaviour (--compiler.resolverClass foo.jar) on the command line or build it in (--compiler.optionalProjectRoot /blah/blah/blah). Obviously there are people who want / need this behaviour. --Robert I am not making these decisions. How it came to pass is that the compiler was specifically designed to not do this, but FB accidentally allowed it to work. FB has much more information about "projects" -- high level concepts. All those configuration settings that you have in FB, the compiler does *not* have. It doesn't have a concept of a project. It's only doing commandline bidding.
I'd like this to not turn into a battle. We understand the use case, and would like to implement it. If and when it gets implemented in Flex 4, you can take advantage of it since we are open source. Perhaps we find a novel way to get it to work in Flex3, we'll do it. But if it compromises existing functionality, we probably will not. You have to understand that even if we shipped something broken, if people rely on that behavior you cannot just pull out the supports. If you find solutions that work for you, please use them and share them. They don't need to be published in an update to *everyone* for them to work for you. Beyond that, we'll sort this out. Please be patient. "You have to realize that fundamentally FB is doing something the commandline cannot do." Obviously this fundamental discrepancy problem has to be deprecated at some point. But... I realize that FB is using the project root to resolve assets, but it also will use the source paths too which mxmlc isn't. I understand mxmlc would need extra information about the project root in order to imitate FB's behavior, but I think that's separate bug. You can deal with these issue in two parts without sacrificing compatibility. The part I'm asking to make work like FB is simply append the source paths to the asset path when they are preceded with a slash to find the assets. If you fix that, it's general enough to work for everybody, it doesn't break compatibility because absolute references are broken in mxmlc as it stands, and mxmlc can't support FB's project root idea without an extra option so there's nothing extra you're breaking by fixing it. I don't see why this breaks compatibility by fixing mxmlc and leaving FB alone. You might not be able to make them work exactly the same without breaking the rules, but you can at least address this very painful bug. Then address consolidating the way in which FB and mxmlc find resources in Flex 4. I can wait for code cleanup, but not missing functionality. Keep it simple, and you don't have to worry about backward compatibility. If you're really worried about developer backlash just add a special option to mxmlc to support that type of behavior (-compiler.project-root or whatever). Obviously people who are using it to mean project root aren't compiling with mxmlc anyway because it can't work, but people who are using the source path options are using mxmlc and FB. For people who want to have a workaround but don't want to create a patched version of the SDK: It is possible to get the desired behavior by implementing your own compiler script that uses the oem classes. (flex-compiler-oem.jar)
I've got a solution like that running in our continuous build -- it's not generic enough to share as a program but this code snippet shows how it works import flex2.tools.oem.Application; import flex2.tools.oem.Configuration; app = new Application(new File(file)); app.setPathResolver(new CustomPathResolver(resolveRoots)); Configuration c = app.getDefaultConfiguration(); c.addSourcePath(sourcepath); c.addLibraryPath(librarypath); app.setConfiguration(c); app.setOutput(new File(output)); // save the current contextclassloader (leave out if you don't use ant) ClassLoader origContextClassloader = Thread.currentThread().getContextClassLoader(); // set the contextclassloader to the one we need (leave out if you don't use ant) Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader()); // no incremental building app.build(false); // restore the classloader (leave out if you don't use ant) Thread.currentThread().setContextClassLoader(origContextClassloader); I've trimmed it down to only contain the most important bits. CustomPathResolver will contain your desired path resolving behavior (Do something smart with paths starting with '/') Note: the contextClassloader stuff is only important if you try to add this code to a custom ant (1.7) task -- and in that case you also need to remove the xerces libs from the SDK lib dir. The flex documents even state the correct behavior. Using a '/' in your assets will first search the directory of the file using it then look in the source-paths. It even references -source-path option provided in mxmlc and describes how you would invoke mxmlc to compile it. If the problem is true absolute path references ('/home/dummy/project/idiot.png' or 'c:/picture.png') vs. source-path. Just do both. First try it as described in the docs if you haven't found anything in the source-paths then just try resolving a pure absolute reference. But, only try absolute paths at the very end after you haven't found anything in the source-paths. That maintains backward compatibility. But, I seriously question why you want to support true absolute paths in the first place. They aren't portable. You can't reliably reproduce builds on any machine without changing the code. I really think the use case for support backward compatibility is pretty weak. http://livedocs.adobe.com/flex/3/html/help.html?content=embed_2.html Here is the exact section describing the expected behavior if this bug were fixed. Please fix this in Flex 3. "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. If the image is not found, Flex searches for the image in the SWC files associated with the application. If the MXML file is in the a2 directory, as in a2/testEmbed.mxml, Flex first searches the a2 directory and then the directories specified by the source-path option. " @Charlie, I keep repeating myself: The documentation is incorrect. It was made using FB, not the commandline. The compiler architects specifically designed it to NOT work this way. We do understand the importance of the feature and are looking into it. For now, please be patient and find workarounds that suit your build process.
We, I implement Simon Groenewolt suggestion at flex-mojos.
Now, the problem is asdoc. I don't know why asdoc check embed resources. BTW, why asdoc need all libraries to generate documentation? Anyone know that? VELO As a frustrated development director, I've now been wrestling with this issue on my Flex team's continuous integration build, and must say I find the response to this issue most disappointing. I'm still in disbelief that a language being put forth for professional software development can have a command-line compiler unable to handle the basic nature of absolute/relative file pathing for the inclusion of code or assets.
Breaking automated builds matters. It matters to people responsible for development practices that actually have the discipline to have automated, repeatable builds whose execution are a foundational component of their development process. Automated builds are key to the Agile Software Development methodologies that have been leading the field for years now. I am still rereading this bug report to make sure I am not hallucinating; you have broken automated builds and are saying that if you do anything about it that it will be in Flex 4? Please consider what it means for Adobe to say that it doesn't care about enabling automated builds for Flex projects. Telling development practices to go cobble together some kludge to work around a deficiency in your product is rather poor form. Thanks everyone for the input. It's clear that this is a significant user problem and we are investigating how we can address this in the most appropriate way for our customers who are struggling with this problem as well as those who already have working solutions. Obviously backward compatibility must remain an important priority for us; hiding the behavior change behind a compiler flag will be considered. Please stay tuned for further developments on this issue.
Thanks Steve,
Please also consider the following too that would be both backwardly compatible AND fix the problem without the need of a complier switch to hide the behavior: Just do both. Here is an algorithm that is backwardly compatible and fixes the problem: 1. Given a path to a resource 2. First try to resolve that resource by pre-pending each source-path included on the command line 3. If that file exists then it must have been found return it. 4. If you can't find a resource rooted at one of the source paths then try an absolute path In code: public function getAbsolutePathForResource( resource : String, sourcePaths : Array ) : File { for each( var sourcePath in sourcePaths ) { var file : File = new File( sourcePath, resource ); if( file.exists ) { return file; } } return new File( resource ); // if you don't find it anything then just try the absolute route. } That maintains backward compatibility by allow you to specify your resources absolutely, but also allows you to specify your resources relatively. Of course you'll have to introduce -source-path switch to define where the source-paths should be, but nothing other than that. verified.. now it looks at absolute path and then falls to source path.
Does this fix include compc as well as mxmlc? I build a swc, so I use compc..... I cannot seem to be able to use absolute paths at all, in compc, or ant. Help, I need this! I did try yesterday's nightly build with no luck.... Did try a mxml with this project, and absolute paths did seem to work, but sources paths did not...
(in a .as file) [Embed(source="targets_gc11/listner_ena.png")] Did not work with a command like: flex_sdk/bin/mxmlc src/flex/topo.mxml -source-path+=src/flex/images So, is this in the nightly builds yet? and does it apply to compc as well as mxlmc? It should look into the source path for embeds starting with /
It will first look into the absolute path and then will fall back to the source path(s). if there is no / in the beginning it will be assumed to be relative or absoulte only. is this fix available in a 3.x branch? if so, which revision? I'm still seeing the problem in compc 3.3.0.4589.
my source path contains two directories: src resources/assets my code contains: [Embed(source="/foo.swf")] and (using procmon.exe) I see compc look for: .\src\foo.swf c:\foo.swf but it's not looking in resources\assets. I've tried back/forward slashes, specifying full paths in the source path, "./" prefixes, everything. i'm rapidly losing hair here. please help. ok, I've just verified that this is still broken in 3.3.0.4852
are we going to have to wait until 4.0 to get a fix for this? I think this is a minimal repro case for this bug.
The fix for this is currently not integrated into the 3.x branch.
The fix is not 100% correct.
Look at commit #4208. Following line was placed in Fcsh.mxmlc() and Fcsh.compc(): ThreadLocalToolkit.getPathResolver().addSinglePathResolver(s.sourcePath); But for consistency it must also be placed to Fcsh.compile_compc() and Fcsh.compile_mxmlc() Or more easy and less error-prone solution: put this line only once to CompilerAPI.compile(...) and remove from Fcsh.java New issue was created for this: SDK-20569 I am appalled about the Adobe Support. This Issue is more than 1 YEAR old and nothing happens. I cant belive it. A workaround for the issue means that independant working copys are impossible. Working in a Team with an Repository is impossible. We uses Flex Builder and Flash, and have payed a lot of money for the Flash and Flexbuilder IDE and should be pleased with the Adobe comment of use a workaround, for more than a YEAR? oh no way, im sorry but im so enraged and frustrated. please fixe this issue asap, please.
Well, AFIK this ticket is fixed... but on gumbo....
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
B
Embed asset source starting with "/" works in FlexBuilder, but not in mxmlc
http://tech.groups.yahoo.com/group/flexcoders/message/103050