Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#4085 closed defect (fixed)

dojo.dojo.nls (double dojo in internationalization)

Reported by: guest Owned by: James Burke
Priority: high Milestone: 0.9
Component: BuildSystem Version: 0.9
Keywords: Cc: jamesh@…
Blocked By: Blocking:

Description

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@…

Attachments (1)

build.patch (9.5 KB) - added by guest 12 years ago.
[CLA-patch] Problem with i18nUtil.flattenLayerFileBundles

Download all attachments as: .zip

Change History (23)

comment:1 Changed 12 years ago by James Burke

Component: InternationalizationBuildSystem
Owner: changed from Adam Peller to James Burke
Status: newassigned

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.

comment:2 Changed 12 years ago by James Burke

Resolution: fixed
Status: assignedclosed

(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.

comment:3 Changed 12 years ago by James Burke

Resolution: fixed

(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.

comment:4 Changed 12 years ago by James Burke

This should be fixed now as of r10077.

comment:5 Changed 12 years ago by guest

Resolution: fixed
Status: closedreopened

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@…

comment:6 Changed 12 years ago by guest

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

comment:7 Changed 12 years ago by 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.

comment:8 Changed 12 years ago by James Burke

Cc: jamesh@… added

comment:9 Changed 12 years ago by 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

comment:10 Changed 12 years ago by 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

comment:11 Changed 12 years ago by 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)?

comment:12 Changed 12 years ago by 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

comment:13 Changed 12 years ago by 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?

comment:14 Changed 12 years ago by James Burke

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

comment:15 Changed 12 years ago by 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.

comment:16 Changed 12 years ago by 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?

comment:17 Changed 12 years ago by James Burke

Resolution: worksforme
Status: reopenedclosed

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

Changed 12 years ago by guest

Attachment: build.patch added

[CLA-patch] Problem with i18nUtil.flattenLayerFileBundles

comment:18 Changed 12 years ago by guest

Resolution: worksforme
Status: closedreopened

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.

comment:19 Changed 12 years ago by guest

Just take the bits you need,

jbondc

comment:20 Changed 12 years ago by 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?).

comment:21 Changed 12 years ago by James Burke

Resolution: fixed
Status: reopenedclosed

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

comment:22 Changed 12 years ago by 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?

Note: See TracTickets for help on using tickets.