It's odd it's looking for

"http://ourservername/javascript/release/dojo/nls/_en-us.js"

instead of:

"http://ourservername/javascript/release/dojo/nls/YourPofileBuildName_en-us.js"

Are you specifying a "name" for your layer file? Looks like something with the layer file to me, but I'm not sure. I also include a releaseName param when I run build.sh, but I don't know if that makes a difference.

-Adam

specify a resourceName for your layer in the profile file. that is where the build system gets the "YourProfileBuildName" string from.

Hi,

Thanks so much for your advice so far - I really appreciate it. Unfortunately, I've not been able to cure the problem by adding in a resourceName into the profile file or by putting in a releaseName param. I tried several builds, adding resourceName in different places in the file and by adding the releaseName param when I run the script. In all cases I always get the same 404 error looking for that file...

If it helps further, the error in the compiled file has to do with dijit - I'm using it to render a tab container on the page. When the compiled page loads, it is the tab container that fails to initialize (everything else on the page works), again, it's throwing an exception because it can't find the en_us files:

[Exception... "'Error: Bundle not found: loading in dijit , locale=en-us' when calling method: [nsIDOMEventListener::handleEvent]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "" data: no]

I've posted my.profile.js - I even added the resourceName at the top and inside both of the layers - can anyone see anything obvious that I'm missing out here?

Thanks so much.
A

dependencies ={
resourceName: "APP",
layers: [
{
resourceName: "APPGlobal",
name: "../../APP_Global.js",
dependencies: [
"APP",
"APP.Global"
]
},
{
resourceName: "APPInfo",
name: "../../APP_InfoPage.js",
dependencies: [
"APP.InfoPage"
]
}
],
prefixes: [
[ "dijit", "../dijit" ],
[ "dojox", "../dojox" ],
[ "APP", "../../APP" ]
]
};

Looks like a css includes problem to me. I'm actually losing my mind with build issues myself right now. There are two nightmarish aspects of it:

1) Test cycles are long
2) So many things can go wrong!!

The error you're getting looks like a css error, though. Make sure your path to your css files is correct in your html -- the following should work for the most generic build:

You can also load those from Google/AOL if you're using xdomain. Manually make sure the paths work in your browser. Also, if you're doing xdomain, I believe the css needs to be xdomain also and in the same domain.

-Adam

Hi everyone -

I've finally solved this issue after reading through these postings - thanks very much for all your help; I really appreciate it.

The issue was solved by following jburke's instructions carefully. I made some changes to the profile in light of his comments and things are working properly now.

Thanks so much once again.

I hope this thread helps anyone else finding they have similar problems

Hi Adam,

I really appreciate your response with that one. And sorry to hear that you're experiencing build issues too!

I have a concern with your last response though... Would the fact that the build process is not creating the right _en_us.js files really be down to css errors? The reason why I ask is that I'm not using *any* of the dojo css inside my application; it's all included from another file (which is completely outside the build itself)... And the css all loads fine when I check my app out, so I'm at a loss there too..

After reading your response, the first thing I did was re-run the build only this time removing the cssOptimize param from there... But it still would not build with the proper _en-us.js files.

It seemed to me like it has something to do with the dijit library not being built in the right way, which I'd guessed was to do with a fault with my profile file?

What I tried doing was to take one of the _en-us.js files that it did create (APP_InfoPage_en-us) and rename it to _en-us and copy it to dojo/nls but that only seemed to move the exception to another location (this time it was within dijit/nls.... Something about that solution just felt like it was wrong.

Any ideas?

Thanks very much!

Looking more closely at the details of your post, it's odd the browser's requesting

"dojo/nls/_en-us.js"

as opposed to

"yourLayer/nls/yourLayerName_en-us.js"

In my understanding, in your case it should be requesting:

"APP/nls/APP_Global_en-us.js"

So it looks like there's something fundamentally wrong, but I can't spot it. I would try just using a single layer with everything. Once that works, you can break everything up.

I actually don't use a resourceName in the profile itself, but I pass it as a param to the sh script. Here's my sh script and truncated profile in case you can glean anything:

./build.sh copyTests=false profileFile=../../../util/shoot.profile.js action=clean,release releaseDir=$tmpDir/ releaseName=js

Here's ../../../util/shoot.profile.js

dependencies =
{
layers:
[
{
name: "../littleshoot/littleshootlib.js",
dependencies:
[
"littleshoot.AppMonitor",
"dojo.io.script",
]
}
],
prefixes:
[
[ "littleshoot", "../../littleshoot" ],
]
};

Finally, I load it in html like so:

When I did get errors along the lines of what you're seeing, they were for "littleshoot/nls/littleshootlib_en-us.js" -- although I can't recall precisely what was causing that. I think some xdomain issue though.

Are you using xdomain? Can you include your html?

I think these usability issues are one of the biggest issues with the build system, James. It's extremely powerful with amazing features, but I feel like a lot of developers like me have trouble taking full advantage of it all.

Even just somehow making directories more consistent (../../ versus .. above), more configuration by convention. The problem is it's hard to keep track of where all these directories are if you're not writing the build itself. Creating more consistency wherever possible would do wonders!!!

-Adam

I've also just tested my build process with 1.2.0b2 and wanted to report that it also works fine in that version too - no errors - again, many thanks to everyone for their suggestions with this one!

Best,
A