dojo.dojo.nls (double dojo in internationalization)

[guest]

Introduced in the last 24 hours, when you build a custom dojo.js, there is a dependency dojo.dojo.nls.* rather than dojo.nls. Manually removing the extra dojo. fixes dojo.js

dojo@…

[James Burke]

I think I am causing this. I'm working on #2713, but I goofed something. I should have something to commit in a couple of hours. Sorry for the breakage.

[James Burke]

(In [10076]) Fixes #2713 #4085 #3801. Flattened bundles for i18n layers should work in xd and non-xd load cases now. Also brought over some xd fixes that were made after the 0.9 code was copied from the old trunk.

[James Burke]

(In [10077]) Fixes #2713 #4085 #3801. Flattened bundles for i18n layers should work in xd and non-xd load cases now. Also brought over some xd fixes that were made after the 0.9 code was copied from the old trunk.

[James Burke]

This should be fixed now as of r10077.

[guest]

As of this morning (10/14/2007 revision 10182), this issue is still occurring when using the code from trunk.

If needed, you may reach me on IRC as jamesholder, or email jamesh@…

[guest]

heh. whoops, make that 08/14/2007 :D i hadnt had my coffee yet

[James Burke]

Can you provide a sample build profile that demonstrates the problem? I can appreciate that it might be hard to do this if you reference custom modules. If you can post it and make up dummy names for your modules and indicate which ones reference i18n bundles, then maybe I can make up an example test case using dojo modules.

[guest]

james, hope the formatting stays. I didn't think i was doing anything special with my profile. Here it is.

dependencies = {

layers: [

{

name: "commonWidgets.js", layerDependencies: [ "dojo.js" ], dependencies: [

"dijit.Dialog", "dijit.layout.TabContainer?", "dijit.layout.ContentPane?", "dijit.form.ComboBox?", "dijit.form.FilteringSelect?", "dijit.form.DateTextBox?", "dijit.Tooltip", "dijit.dijit", "dojo.behavior", "dojo.data.ItemFileReadStore?"

]

}

], prefixes: [

[ "dijit", "../dijit" ], [ "dojox", "../dojox" ]

]

}

--james

[guest]

Drat, not sure what's up with the question marks in there. Must be a wiki thing, they're not in the original

--james

[James Burke]

Thanks for the build profile. I used it against r10198. I did not find an issue. I did the following steps (I called the profile above "jh.profile.js":

• cd util/buildscripts
• ./build.sh profile=jh releaseName=jh action=release
• cd ../../release/jh/dojo
• Checked commonWidgets.js and dojo.s for a "dojo.dojo" reference. I could not find one.
• I modified the release/js/dijit/tests/layout/test_TabContainer.html to include a script tag to load commonWidgets.js. I included this script tag right after the dojo.js script tag:

<script type="text/javascript" src="../../../dojo/commonWidgets.js"></script>

Everything loaded correctly. I was loading the pages in Firefox 2.0.0.6 on OSX.

What are the steps you use to see the bug? Is your repo snapshot up to date, with no local changes (check via svn status)?

[guest]

Alright,

I checked out again a second ago. (to r10198) and was able to reproduce the bug described.

We're pretty much the same except:

I was using this command to start the build.

java -jar lib/custom_rhino.jar build.js profile=dart action=release

When I switched to using the build.sh (what you are using), it generated the file correctly(no double dojo).

I wondered why I was using that command, so I went back and found the doc's i had looked at: http://dojotoolkit.org/book/dojo-porting-guide-0-4-x-0-9/build-system-changes

Sooo.... I'd say either the docs need to reflect using ./build.sh, or there is another problem using java that needs to be fixed.

I just glanced at the build.sh file... it looks like its pretty much just passingthe arguments to build.sh onto java.... which makes me even more curious as to whats busted.

Could it be an env thing? some command line variable I don't have set up?

I dunno.

--james

[James Burke]

Yeah, it must be something specific to your environment. I just tried with the straight java -jar call, and I was still OK doing the steps I mentioned previously. I was using OS X using Java 1.5.0_07-164 for this test. What are you using?

[James Burke]

BTW, I updated the porting guide page to reference build.sh/build.bat for the build. Thanks for pointing it out.

[guest]

java version "1.5.0_11" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot?(TM) Client VM (build 1.5.0_11-b03, mixed mode)

I'm running gentoo. What variables are used for generating the internationalization?

I tried using the java build command as root and as my normal user, (in case I lost an env when i su'ed ), but the problem shows up as either user (if bypassing the build.sh)

Anyway, thanks for taking a look at it.

[James Burke]

Adam Peller had a suggestion: maybe it is a classpath issue. Can you compare classpaths when you do ./build.sh (modify it to print out classpath) vs. doing the direct java command?

[James Burke]

Closing the ticket for now, since I cannot reproduce. But feel free to add more info to it, particularly if there are classpath issues.

[guest]

[CLA-patch] Problem with i18nUtil.flattenLayerFileBundles

[guest]

Hey james,

I came across the same problem dojo.dojo.nls and tracked it down to: buildUtil.mapPathToResourceName

It seems to be an issue with relative paths, it looks it might something with the JVM, I'm also using: java version "1.5.0_10" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Java HotSpot?(TM) Client VM (build 1.5.0_10-b03, mixed mode)

I changed the code the use the layername instead of the whole file path, let me know if the patch makes sense to you. It's working for me and the build above but I don't feel 100% about it.

[guest]

Just take the bits you need,

jbondc

[guest]

It is not environmental. It is not specific to java version and it has no bearing on what equipment you execute java on.

I have test this case (​http://r0.paddlesource.com/awutil.tbz2 untar in trunk/, then execute /trunk/util/buildscripts/ba.sh ). It has build equally on Java5 on my OSX 10.3 G3 Mac, WinXP under cygwin witn Sun Java5, FC7 with Sun Java5. The output is identical.

It has something to do with adding non-dojo layers to the 'dojo' layer (that is modifying the layered build to extend dojo.js's dependencies) If you modify layers.profile.js, and add custom components to dojo.js you will see the problem. (Could it be in the special-case logic that you use to set the default properties of the dojo.js layer?).

[James Burke]

(In [10285]) Fixes #4085. buildUtil.mapPathToResourceName was finding the wrong dojo path when the releaseName for a build was dojo.

[James Burke]

Thank you all for the input. That helped a lot. I think the following caused the problem:

When no releaseName is specified for the build command, then the directory "release/dojo" is used for the build output. If you add dependencies to dojo.js in your build file that need i18n resources, then a function to figure out paths to resource names was failing (it found the release/dojo as the start point for the resource name instead of release/dojo/dojo).

I was using releaseName=foo for my builds, so I did not see the problem.

Hopefully it is now fixed in r10285. If not please feel free to reopen with more information.

jbondc: thank you for taking the time to do a patch. I don't think in this case using layerName over fileName would help, and you probably avoided the issue in your patch since your function buildUtil.mapLayerToResourceId did not use the same path building logic as buildUtil.mapPathToResourceName(). I am concerned that the 'dojo/' reference in buildUtil.mapLayerToResourceId might refer to the releaseName (the 'dojo' part in 'release/dojo'), so maybe that would not work if releaseName was changed to something other than dojo?