#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: | [email protected]… | |
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
Attachments (1)
Change History (23)
comment:1 Changed 15 years ago by
Component: | Internationalization → BuildSystem |
---|---|
Owner: | changed from Adam Peller to James Burke |
Status: | new → assigned |
comment:2 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:3 Changed 15 years ago by
Resolution: | → fixed |
---|
comment:5 Changed 15 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 [email protected]…
comment:7 Changed 15 years ago by
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 15 years ago by
Cc: | [email protected]… added |
---|
comment:9 Changed 15 years ago by
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 15 years ago by
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 15 years ago by
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 15 years ago by
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 15 years ago by
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 15 years ago by
BTW, I updated the porting guide page to reference build.sh/build.bat for the build. Thanks for pointing it out.
comment:15 Changed 15 years ago by
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 15 years ago by
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 15 years ago by
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
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 15 years ago by
Attachment: | build.patch added |
---|
[CLA-patch] Problem with i18nUtil.flattenLayerFileBundles
comment:18 Changed 15 years ago by
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
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:20 Changed 15 years ago by
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 15 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:22 Changed 15 years ago by
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?
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.