Opened 10 years ago

Closed 10 years ago

#15897 closed defect (invalid)

Dojo buildsystem broken in 1.8.0

Reported by: tsvendsen Owned by: Rawld Gill
Priority: undecided Milestone: tbd
Component: BuildSystem Version: 1.8.0
Keywords: Cc:
Blocked By: Blocking:



It seems like the dojo build system does break our builds when going from 1.7.1 to 1.8.0.


  1. unpack contents of zip (scripts folder at the same level as dojo src)
  2. cd into dojo buildscripts folder
  3. run build command

java -Xms256m -Xmx256m -cp "../shrinksafe/js.jar";"../closureCompiler/compiler.jar";"../shrinksafe/shrinksafe.jar" "../../dojo/dojo.js" baseUrl="../../dojo" baseUrl=../../dojo load=build profile=../../../scripts/plugin.profile.js -r basePath=../../

Note that the build runs discovery as normal, but the output is not in the release catalog as for dojo and the other stuff. It outputs the contents directly to my/company... and the js file is 0B The only files ending up in the release catalog are those that have a single namespace name, like dojo, dijit, ..., if the name attribute in the packages contains a / then the build does not work

directory structure

   |  |--company/
   |  |  |--plugins/   
   |  |  |  |--buildbug/
   |  |  |  |  |--buildbug.profile.js
   |  |  |  |  |--GeneratedWidget.js
   |  |  |  |  |--package.json

By unpacking dojo 1.7.1 and building from that you will see that the build works as expected and everything is put together in the release folder.

The question is if this feature has been discontinued and we have to restructure all our components to have a unique top level directory or if this is a defect.

This problem looks quite similar to the defect reported in but I'm not 100% sure since it looked like the discovery is failing there.

NOTE! by adding a console.log to the amd function in package.js you can clearly see that the buildsystem is dropping a directory when building.

Attaching an example project to this ticket.

Attachments (1) (2.4 KB) - added by tsvendsen 10 years ago.
Example project

Download all attachments as: .zip

Change History (2)

Changed 10 years ago by tsvendsen

Attachment: added

Example project

comment:1 Changed 10 years ago by Rawld Gill

Resolution: invalid
Status: newclosed

Hi tsvendsen,

Thanks for the report. It turns out there is an error in your build script. Package names must be "The first segment of an absolute module ID prefix"; see the heading "packages" in

I'm not sure exactly what you were trying to do with baseUrl on the command line (and I didn't try very hard to understand). In any event there is an easier way to go about setting up paths.

To begin, recall "the property basePath was automatically added to the profile object and set to the path at which the profile resides. If the profile contains the property basePath and the value of that property is a relative path, then the build system will automatically resolve that path with respect to the directory in which the profile resources resides" and "basePath is used as the reference path when resolving relative source paths". See for the full text.

I designed this so that a profile could specify basePath as relative to directory in which the profile resides. This allows the build system to resolve the same paths without respect to the cwd (not the case prior to 1.7).

Lastly, recall that

  • all relative src paths and are relative to basePath
  • all relative dest paths are relative to releaseDir
  • relative releaseDir is relative to basePath

Given all of this, assuming the directory structure:

   |  |--company/
   |  |  |--plugins/   
   |  |  |  |--buildbug/
   |  |  |  |  |--buildbug.profile.js
   |  |  |  |  |--GeneratedWidget.js
   |  |  |  |  |--package.json

The following profile works:

var profile = {
    // relative to this file

    // relative to base path







I'm not sure why you're using the verbose command line (though there is nothing technically wrong with it). Here is the command line I tested with (executed from the util/buildscripts dir).

./ -bin java -p ../../../scripts/plugin.profile.js -r

Of course I'm a java hater so I would always omit "-bin java", causing the script to use node.js

Note: See TracTickets for help on using tickets.