View Full Version : JS Builder crashes building latest yui-ext code from svn
28 Dec 2006, 10:57 AM
Trying to build either yui-ext or the resources after latest SVN update (ver 95). Crashing with message "Name cannot begin with the '<' character, hexadecimal value 0x3c. Line 2, position 2"
Looks like it's occurring in the Project.Load() method.
28 Dec 2006, 11:55 AM
Are you using Jack's .jsb project files or your own? I can build the current dev files using the .jsb project files in SVN by just double-clicking on the .jsb and building it.
If you are using a custom .jsb file, please post it here and I'll take a look.
28 Dec 2006, 12:10 PM
I thought I was using Jack's but it looks like SVN is doing something wierd when it sees a modified version and tries to update. I told it to resolve the conflict, but it looks like it still leaves junk in the file. I killed the jsbs and pulled fresh copies and it's OK.
<?xml version="1.0" encoding="utf-8"?>
<project path="" name="yui-ext" author="Jack Slocum" version="0.33" copyright="$projectName $version
Copyright(c) 2006, $author." output="E:\Projects\yui-ext.0.33.1" source="True" source-dir="$output\source" minify="True" min-dir="$output\build" doc="False" doc-dir="$output\docs" min-dair="$output\build">
<project path="" name="yui-ext" author="Jack Slocum" version="0.40" copyright="$projectName $version
Copyright(c) 2006, $author." output="C:\apache2\htdocs\deploy\yui-ext.0.40\" source="True" source-dir="$output\source" minify="True" min-dir="$output\build" doc="False" doc-dir="$output\docs" min-dair="$output\build">
<directory name="" />
<target name="Core" file="$output\yui-ext-core.js" debug="True" shorthand="False" shorthand-list="YAHOO.util.Dom.setStyle
<include name="yutil.js" />
<include name="DomHelper.js" />
<include name="Element.js" />
<include name="CompositeElement.js" />
<include name="EventManager.js" />
<include name="UpdateManager.js" />
<include name="Layer.js" />
28 Dec 2006, 12:49 PM
Are you using Tortoise or something else to merge? Just curious as I haven't tried merging jsb files myself, but if there are any conflicts in general, Tortoise should prompt you to resolve them manually if they can't be auto-resolved:
If you get any conflicts during an update (this can happen if others changed the same lines in the same file as you did and those changes don't match) then the dialog shows those conflicts in red. You can double click on these lines to start the external merge tool to resolve the conflicts.
By the looks of your file, the same line changed and so it could not be auto-merged. I guess it either didn't prompt you or you chose not to merge manually, so adding the diff info into the file is probably the best it could do for you since it didn't know which version of the line was current.
28 Dec 2006, 1:14 PM
It's Tortoise. When it detects a conflict, it looks like it renames the file with '.mine' then pulls down the current version. My thought was that when you tell it a confict is resolved it considers current version correct - however it must be leaving diffs. I'll have take a look at the doc and see what the right process is do deal with this.
28 Dec 2006, 8:20 PM
SVN is great for that. You monkeyed with a file and then did SVN Update and that same file had changes committed while your working copy did not. Hence the .mine, the revision minus your changes, and the latest revision showing up. You can edit the file and remove any conflicts without much problem, choose the one you want, and then SVN Mark Resolved, and like magic... all files disappear except the one you want. Isn't that sweet. It's not Tortoise so much as all SVN clients. They do that.
29 Dec 2006, 7:42 PM
I faced the same problem. Is there a way to externalize the changes to output path etc that the user makes? Maybe write to a proj.properties file in the install working dir?
For example I changed the output path to the one I wanated but on SVN update, I have to manually redo all my path settings.
<project path="" name="yui-ext" author="Jack Slocum" version="0.40" .. output="C:\apache2\htdocs\deploy\yui-ext.0.40\" >
29 Dec 2006, 7:53 PM
Also "recent projects" in the file menu will be nice.
30 Dec 2006, 7:20 AM
Well, regarding overwriting the output paths, etc. everyone who uses Jack's project files will have that issue (including me). It's sort of difficult to keep that separate is it really is part of the "project" -- you can't really define build targets separately from the path that they are built to. Even if they were separate, if Jack added or removed a build target, then the external mapping to the paths would still break. I think as long as you're using Jack's jsb files instead of maintaining your own, that's just something you'll have to live with.
A "recent projects" menu item is a good idea and something I've been meaning to add. I'll add it to the list -- thanks.
2 Jan 2007, 3:00 AM
It's sort of difficult to keep that separate is it really is part of the "project"
Not sure I fully understand why its hard to make the output references in the project file as variable references, and store the variable values in a separate file like <project>-vars.properties. Kinda like ant allows you to pull in properties files that store the variable values.
Would it atleast be possbile to move all the variables in a separate xml tag in the project file. That way we don't have to make selective merges within lines in the proejct file.
2 Jan 2007, 3:37 AM
Not sure I fully understand why its hard to make the output references in the project file as variable references, and store the variable values in a separate file like <project>-vars.properties.
We can do that. But again, if any of the target names change, or if any are added or removed by Jack, then you are back to the same issue since they won't match correctly. I'm not saying that your suggestion cannot be done, just that it doesn't necessarily solve all the problems related to reusing Jack's project files. But yes, it would probably help most of the time -- I'll look into saving the paths independently.
3 Jan 2007, 3:33 PM
Powered by vBulletin® Version 4.1.5 Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.