Opened 10 years ago

Closed 7 years ago

#9395 closed defect (fixed)

layer file in nonexistent directory breaks build

Reported by: floatingworld Owned by: Rawld Gill
Priority: low Milestone: 1.7
Component: BuildSystem Version: 1.3.1
Keywords: layer profile needsreview Cc:
Blocked By: Blocking:


I'm building dojo 1.3.1 from source on Windows XP. My profile.js includes this:

layers: [
		name: "../../site/dojocustom.js",
		dependencies: [

And because the folder "site" doesn't already exist within releaseDir the build breaks. Creating that empty folder ahead of time resolves the problem. Here's the end of the build script's output:


release:  Optimizing (shrinksafe) file: C:/parentfolder/folder/../dijit/dijit-all.js
release:  Interning strings for file: C:/parentfolder/folder/../dojox/off/offline.js
release:  Optimizing (shrinksafe) file: C:/parentfolder/folder/../dojox/off/offline.js
org.mozilla.javascript.WrappedException: Wrapped C:\parentfolder\folder\..\..\site\dojocustom.js.uncompressed.js (The system cannot find the path specified)
 at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(
 at org.mozilla.javascript.MemberBox.newInstance(
 at org.mozilla.javascript.NativeJavaClass.constructSpecific(
 at org.mozilla.javascript.NativeJavaClass.construct(
 at org.mozilla.javascript.ScriptRuntime.newObject(
 at org.mozilla.javascript.gen.c3._c7(Unknown Source)
 at Source)
 at org.mozilla.javascript.optimizer.OptRuntime.callN(
 at org.mozilla.javascript.gen.c3._c6(Unknown Source)
 at Source)
 at org.mozilla.javascript.optimizer.OptRuntime.call2(
 at org.mozilla.javascript.gen.c1._c3(Unknown Source)
 at Source)
 at org.mozilla.javascript.optimizer.OptRuntime.call0(
 at org.mozilla.javascript.gen.c1._c0(Unknown Source)
 at Source)
 at org.mozilla.javascript.ContextFactory.doTopCall(
 at org.mozilla.javascript.ScriptRuntime.doTopCall(
 at Source)
 at org.mozilla.javascript.gen.c1.exec(Unknown Source)
Caused by: C:\parentfolder\folder\..\..\site\dojocustom.js.uncompressed.js (The system cannot find the path specified)
 at Method)
 at<init>(Unknown Source)
 at<init>(Unknown Source)
 at sun.reflect.GeneratedConstructorAccessor9.newInstance(Unknown Source)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
 at java.lang.reflect.Constructor.newInstance(Unknown Source)
 at org.mozilla.javascript.MemberBox.newInstance(
 ... 28 more

Change History (6)

comment:1 Changed 10 years ago by James Burke

This is problematic to support. What should happen is that you have a site directory before the build and you put in a prefixes entry in your build profile for site. Then things should work as expected.

The directories really match to module prefixes, and it is important for things like i18n bundles that also get flattened/optimized for a build layer. But in order to load the layer correctly, the layer code will try to do a dojo.require("site...") call to load the i18n bundle. However, if you have not set up the site directory/module prefix mapping things will fail.

i18n may not be a specific concern for the modules you have in your build, but for the generic build case, we need to support them.

So I believe this is working as designed, but I can appreciate that it can cause some confusion. I can see about putting in a message in the build about this expected behavior when this error is hit. Would that help?

comment:2 Changed 10 years ago by floatingworld

Yeah, that would be a good idea - to catch the exception and output an explanatory message. And actually I've thought about it more and even beyond i18n stuff it makes sense for this to be expected behavior, because otherwise if you've entered the wrong path for your application in profile.js, for example including too many "../", if the build didn't crash it wouldn't be until runtime of your application that you'd discover the problem.

comment:3 Changed 10 years ago by James Burke

Milestone: tbdfuture

comment:4 Changed 7 years ago by bill

Owner: changed from James Burke to Rawld Gill

Bulk update to assign BuildSystem? tickets to Rawld. Many of these are probably already fixed in 1.7.

comment:5 Changed 7 years ago by ben hockey

Keywords: needsreview added
Priority: highlow

comment:6 Changed 7 years ago by Rawld Gill

Milestone: future1.7
Resolution: fixed
Status: newclosed

Fixed as side-effect of new builder in 1.7.

Note: See TracTickets for help on using tickets.