Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#12673 closed enhancement (fixed)

enhance builder to decouple from v1.6- loader, consume AMD modules and has.js API, and keep backcompat with v1.6-

Reported by: Rawld Gill Owned by: Rawld Gill
Priority: high Milestone: 1.7
Component: BuildSystem Version: 1.6.0
Keywords: Cc: James Thomas
Blocked By: Blocking:

Description

The version 1.6- build system uses the 1.6- loader to trace dependencies. Since this loader has been replaced, this design must be replaced.

Further, the 1.6- loader is designed to consume the dojo.provide/require module format and does not understand the AMD module format. Since the dojo code stack now uses the AMD format, this design must be enhanced to directly consume AMD modules.

Finally, 1.7+ is moving to extensive use of the has.js API for code bracketing. The build system must be enhanced to trim dead code branches based on has feature values known at build time.

These enhancements must be additive: the build system must still consume dojo.provide/require modules as well as v1.6- profiles.

Change History (101)

comment:1 Changed 9 years ago by Rawld Gill

Status: newassigned

comment:2 Changed 9 years ago by Rawld Gill

(In [24330]) added new build program; refs #12673, \!strict

comment:3 Changed 9 years ago by Rawld Gill

(In [24378]) updated build script to point to new builder; small hack to make builder work with _base/sniff not-conditionally included; small hacks to make builder work on dtk server; refs #12673; \!strict

comment:4 Changed 9 years ago by ben hockey

i can't seem to get the build to work - it seems that its assuming a browser:

using build.sh

ben@dev04 /usr/local/share/dojo/trunk/util/buildscripts » ./build.sh profile=base
loader/failed-sync
dojo*
../../dojo/main.js
ReferenceError: "ActiveXObject" is not defined.
loader/failed-sync
build*
../../util/build/main.js
ReferenceError: "ActiveXObject" is not defined.

and using node

ben@dev04 /usr/local/share/dojo/trunk/util/buildscripts » node ../../dojo/dojo.js load=build profile=base
loader/failed-sync
dojo*
/homes/staff/ben/svn/dojo/dojo/main.js
{ stack: [Getter/Setter],
  arguments: [ 'ActiveXObject' ],
  type: 'not_defined',
  message: [Getter/Setter] }
loader/failed-sync
build*
/homes/staff/ben/svn/dojo/util/build/main.js
{ stack: [Getter/Setter],
  arguments: [ 'ActiveXObject' ],
  type: 'not_defined',
  message: [Getter/Setter] }

comment:5 Changed 9 years ago by bluk

I also can't get it to work using the latest trunk from Dojo but if I back out the last couple of fixes for #12672 that were made today (Tuesday April 19), then the build script seems to start doing work but the release itself doesn't seem to be shrinksafed.

What is the expected output? I see some errors like:

ERROR: failed to resolve dependency (dojo/_base/_loader/bootstrap) for module (/Users/user1/Sites/dojo_git/dojo/lib/backCompat.js)
ERROR: failed to resolve dependency (dojo/_base/_loader/hostenv_browser) for module (/Users/user1/Sites/dojo_git/dojo/lib/kernel.js)

Is there any documentation for the latest changes to maybe help us along? Would be much appreciated! Thanks!

comment:6 Changed 9 years ago by Rawld Gill

I broke the builder with some config "improvements" to the loader. Should be fixed soon.

comment:7 Changed 9 years ago by Rawld Gill

(In [24410]) improved config impl in loader; fixed regression in builder caused by [24396]; refs #12672; refs #12673; \!strict

comment:8 Changed 9 years ago by Rawld Gill

as of [24410], the new builder should be working on both rhino and node. There are a few features that have not yet been ported from bdLoad; these will be finished ASAP:

  • the optimizer is not turned on (code is in repo)
  • css optimization is not turned on (code is in repo)
  • dumping symbols has not been ported
  • custom scoping has not been ported
  • traversing HTML files is not turned on
  • selecting a version of query is not ported (this may be removed)
  • burning in a config has not been ported

comment:9 Changed 9 years ago by ben hockey

building my app uses the v1xProfiles builder and there is an error with logger not being defined - stack trace from using node (same problem exists in rhino but node shows a more descriptive error - although it won't help much)

ReferenceError: logger is not defined
    at eval at <anonymous> (build/v1xProfiles:311:5)
    at build/v1xProfiles:311:5
    at build/v1xProfiles:313:5
    at build/buildControl:111:12
    at Array.forEach (native)
    at build/buildControl:94:27
    at /homes/staff/ben/svn/dojo/dojo/dojo.js:741:42
    at /homes/staff/ben/svn/dojo/dojo/dojo.js:786:23
    at /homes/staff/ben/svn/dojo/dojo/dojo.js:818:5
    at /homes/staff/ben/svn/dojo/dojo/dojo.js:994:6

comment:10 Changed 9 years ago by ben hockey

the previous build tool would delete the contents of the release dir before doing a build. this builder will output some errors about not being able to copy files over if you try to run the build a 2nd time.

some sample output

writing resources...
cp: /homes/staff/ben/svn/dojo/release/util/doh/.svn/all-wcprops: Permission denied
ERROR: failed to copy file from "/homes/staff/ben/svn/dojo/util/doh/.svn/all-wcprops" to "/homes/staff/ben/svn/dojo/release/util/doh/.svn/all-wcprops"
cp: /homes/staff/ben/svn/dojo/release/util/doh/.svn/entries: Permission denied
ERROR: failed to copy file from "/homes/staff/ben/svn/dojo/util/doh/.svn/entries" to "/homes/staff/ben/svn/dojo/release/util/doh/.svn/entries"

comment:11 Changed 9 years ago by ben hockey

unable to resolve some dependencies. do we need to remove dojo/lib/backCompat.js and dojo/lib/kernel.js or should they be updated?

sample output from build

ben@dev04 ~/share/dojo/trunk/util/buildscripts » ./build.sh profile=base
running under rhino
discovering resources...
reading resources...
processing raw resource content...
tokenizing resource...
processing resource tokens...
parsing resource...
processing resource AST...
ERROR: failed to resolve dependency (dojo/_base/_loader/bootstrap) for module (/homes/staff/ben/svn/dojo/dojo/lib/backCompat.js)
ERROR: failed to resolve dependency (dojo/_base/_loader/hostenv_browser) for module (/homes/staff/ben/svn/dojo/dojo/lib/kernel.js)
executing global optimizations...

comment:12 in reply to:  10 ; Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

the previous build tool would delete the contents of the release dir before doing a build. this builder will output some errors about not being able to copy files over if you try to run the build a 2nd time.

some sample output

writing resources...
cp: /homes/staff/ben/svn/dojo/release/util/doh/.svn/all-wcprops: Permission denied
ERROR: failed to copy file from "/homes/staff/ben/svn/dojo/util/doh/.svn/all-wcprops" to "/homes/staff/ben/svn/dojo/release/util/doh/.svn/all-wcprops"
cp: /homes/staff/ben/svn/dojo/release/util/doh/.svn/entries: Permission denied
ERROR: failed to copy file from "/homes/staff/ben/svn/dojo/util/doh/.svn/entries" to "/homes/staff/ben/svn/dojo/release/util/doh/.svn/entries"

Yes, it's true, the new builder doesn't delete the previous output but rather overwrites anything that's there. So any output is fresh, but anything in the destination tree that's not part of the output is left alone.

I didn't like the idea of the builder deleting trees in the file system. It seemed to me this would be better done in a shell script.

If there is a strong desire to keep this feature, it's easy enough to put back.

comment:13 in reply to:  9 ; Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

building my app uses the v1xProfiles builder and there is an error with logger not being defined - stack trace from using node (same problem exists in rhino but node shows a more descriptive error - although it won't help much)

ReferenceError: logger is not defined
    at eval at <anonymous> (build/v1xProfiles:311:5)
    at build/v1xProfiles:311:5
    at build/v1xProfiles:313:5
    at build/buildControl:111:12
    at Array.forEach (native)
    at build/buildControl:94:27
    at /homes/staff/ben/svn/dojo/dojo/dojo.js:741:42
    at /homes/staff/ben/svn/dojo/dojo/dojo.js:786:23
    at /homes/staff/ben/svn/dojo/dojo/dojo.js:818:5
    at /homes/staff/ben/svn/dojo/dojo/dojo.js:994:6

There is no logger in the new build system. Can you tell me your use case? I added this item to the TODO list in comment #8.

comment:14 in reply to:  8 Changed 9 years ago by Rawld Gill

Investigate logger feature and decide to include or not.

comment:15 in reply to:  12 Changed 9 years ago by ben hockey

Replying to rcgill:

Yes, it's true, the new builder doesn't delete the previous output but rather overwrites anything that's there. So any output is fresh, but anything in the destination tree that's not part of the output is left alone.

I didn't like the idea of the builder deleting trees in the file system. It seemed to me this would be better done in a shell script.

If there is a strong desire to keep this feature, it's easy enough to put back.

my vote is to maintain the previous behavior simply because it has now become the expected behavior. yes, a shell script could do this but then it would have to know where the output dir is and everybody would have to update their shell scripts. it is much simpler for the build tool to calculate exactly where the output will be because this information is contained in the profile. i don't mind if an option is added to change this behavior but i think the default should be a drop-in replacement for the previous build tool.

comment:16 in reply to:  11 Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

unable to resolve some dependencies.

The error message is correct. There are unresolved dependencies. But those errors are in old files that aren't used in 1.7. I expect to kill them soon. I wanted to wait until things settled a bit with all the massive changes before deleting things.

I also noticed that I've got an exclude already in dojo/package.json for the dojo/_base/loader tree...so those files shouldn't be being discovered. I'll investigate this error.

For the moment, if you get such error reports; they're informational and shouldn't affect the output.

comment:17 in reply to:  13 ; Changed 9 years ago by ben hockey

Replying to rcgill:

There is no logger in the new build system. Can you tell me your use case? I added this item to the TODO list in comment #8.

here's part of my profile - i can see now that the issue is probably generated from my profile setting the log level to logger.TRACE - it was very convenient to be able to tweak this from within the profile.

dependencies = {
	// Generally, we pass this in on the command line
	//	 buildLayers: "../app/app.js",

	// this should probably always be release
	// other possible values are clean or help
	// release implies clean unless buildLayers option is used
	action: "release",

	// this is our version number which will be returned via dojo.version
	version: "1.7.0.1303306349000",

	// we can have the following log levels:
	//      TRACE: 0,
	//      INFO: 1,
	//      WARN: 2,
	//      ERROR: 3
	log: logger.TRACE,

	// this is the name of the directory that the build will be put in
	// default value: "dojo"
	releaseName: "release",

	// this is the path to where the build directory will be
	// default value: "../../"
	// releaseDir: "../../",

	// this should probably always be "comments"
	// an alternative is "comments.keepLines" which will still strip
	// comments and inline @import calls but will preserve line returns
	cssOptimize: "comments",

	// which JavaScript optimizer to run on the output files
	// "closure", "shrinksafe", "shrinksafe.keepLines", or "packer"
	optimize: "shrinksafe",
	layerOptimize: "shrinksafe",

	// "normal" will leave in console.warn and console.error
	// use "all" to remove them
	stripConsole: "normal",

	// this removes the demos and tests, etc from the dojo distribution
	mini: true,

	// == localeList
	// list of locales we support
	localeList: "en-us",

	// == loader and xdDojoPath
	// XD stuff - comment these 2 lines for a local build
	// loader: "xdomain",
	// xdDojoPath: "",

	// these are our layers
	layers: [
		{
			name: "dojo.js",
			dependencies: [
				// removed
			]
		},
		{
			name: "../dijit/dijit.js",
			dependencies: [
				// removed
			]
		},
		{
			name: "../app/app.js",
			layerDependencies: [
				"dojo.js",
				"../dijit/dijit.js"
			],
			dependencies: [
				// removed
			]
		}
	],

	// we could provide a third parameter to these prefixes,
	// which would be a path to a copyright file - for example
	prefixes: [
		["dijit", "../dijit"],
		["dojox", "../dojox"],
		["app", "../app"]
	]
};

comment:18 Changed 9 years ago by ben hockey

if you try to build the baseplus profile of dojo, the extra modules (dijit._Widget, dijit._Templated, dojo.fx and dojo.NodeList?-fx) are not included in dojo.js

comment:19 Changed 9 years ago by ben hockey

if i have the following structure, test.modules.foo is not included in the test/test.js output

test
  test.js
  bar.js
  modules
    foo.js

test.js

dojo.provide('test.test');

dojo.require('test.modules.foo');
dojo.require('test.bar');

is there something special with modules that is causing this?

comment:20 in reply to:  19 Changed 9 years ago by ben hockey

Replying to neonstalwart:

fyi - layers from the profile for the above build

layers: [
	{
		name: "../test/test.js"
	}
],

comment:21 Changed 9 years ago by ben hockey

the default value for releaseName used to be 'dojo'. now if releaseName is not specified, the output is placed directly in releaseDir/release rather than releaseDir/release/dojo

comment:22 Changed 9 years ago by ben hockey

dojo.version does not report the version from the profile. also, the build tool used to output the version number as part of it's logging when it was doing the build. something like:

Building with version x.x.x.xxx

it was useful for verifying what you were doing.

comment:23 Changed 9 years ago by James Thomas

Cc: James Thomas added

comment:24 Changed 9 years ago by bluk

the optimizer is not turned on (code is in repo)
css optimization is not turned on (code is in repo)

Is there any way to turn those on to try to get an optimized build? TIA!

comment:25 Changed 9 years ago by James Thomas

Using the trunk build system with the sample "dtkapi" profile doesn't seem to work correctly. Running the following command indicates a successful build has occurred.

$ sh build.sh profile=dtkapi 
....
Total build time: 85.06 seconds

But the file "../../release/dtkapi.js" isn't present in the output. Looking at the logs, does the following indicate I've configured something wrong? ERROR: unable to find the resource for layer (dojo/dtkapi)

comment:26 Changed 9 years ago by Chris Mitchell

Priority: normalhigh

setting pri high, blocking web builder progress

comment:27 Changed 9 years ago by Rawld Gill

(In [24752]) ported forward changes in [24750] that affected builder; refs #12673; !strict

comment:28 in reply to:  4 Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

i can't seem to get the build to work - it seems that its assuming a browser:

fixed

comment:29 in reply to:  9 Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

building my app uses the v1xProfiles builder and there is an error with logger not being defined

including the logger in a profile shouldn't cause an exception now, but logger setting are ignored.

comment:30 Changed 9 years ago by Rawld Gill

build is now using/requires node 0.4.x when using node.js

comment:31 Changed 9 years ago by Rawld Gill

(In [24806]) added feature to include absolute module id in built amd modules as required for cdn build (this needs to be improved to be switchable); refs #12673; !strict

comment:32 in reply to:  10 Changed 9 years ago by ben hockey

Replying to neonstalwart:

this builder will output some errors about not being able to copy files over if you try to run the build a 2nd time.

this issue seems to have been resolved

comment:33 Changed 9 years ago by Rawld Gill

(In [24847]) improved amdDeps transform to convert dojo.provide/dojo.require modules to amd modules; fixed dojo layer bootstrap; added copyTests; refs #12673; !strict

comment:34 Changed 9 years ago by Rawld Gill

(In [24875]) improved transform from dojo.provide-style module to AMD module in builder; refs #12673; !strict

comment:35 Changed 9 years ago by Rawld Gill

(In [24876]) fixed bug in wait semaphore in copy transform; refs #12673

comment:36 Changed 9 years ago by Rawld Gill

(In [24877]) added file handle throttling machinery; refactored process and fs modules; refs #12673; !strict

comment:37 Changed 9 years ago by Rawld Gill

(In [24879]) turned on internStrings, copyTests, and mini features; refs #12673; !strict

comment:38 Changed 9 years ago by Rawld Gill

(In [24881]) turned on and deprecated the profileFile switch (profile now handles filenames in addition to profile names with automatic detection between the two forms); refs #12673; !strict

comment:39 Changed 9 years ago by Richard Backhouse

I'm attempting to build off the trunk and its failings looking for "util/build/transforms/dojoBoot.js" which is defined as a dependency in util/build/transforms/writeDojo.js

comment:40 Changed 9 years ago by Rawld Gill

(In [24909]) added google closure compiler; refs #12673

comment:41 Changed 9 years ago by Rawld Gill

(In [24910]) enhanced build app with optimizer machinery; added files missing from repo; likely breaks on windows; refs #12673; !strict

comment:42 in reply to:  41 Changed 9 years ago by Rawld Gill

Replying to rcgill:

(In [24910]) enhanced build app with optimizer machinery; added files missing from repo; likely breaks on windows; refs #12673; !strict

This is a major enhancement that turns on many features. It has been tested on node.js and rhino on Unix (FreeBSD) and successfully builds base, demos-all, dtkapi. It has not been tested on windows with rhino, and that will likely fail. It should work on a window cygwin environment.

All deleting (cleaning) has been commented out (there has not been enough testing to publish code that deletes directory trees!). If you wish to play with locally, grep "process.exec"

The version includes closure support with has.js and full console trimming.

The program is highly asynchronous and, in node, supports multiple concurrent processes during the optimization phase. This improves performance with closure; however, closure kills performance compared to no optimization. This issue must be studied in hopes of finding more optimizations.

There are still a few v1.6- features that have yet to be moved or turned on:

  • css optimization: code is there, not turned on
  • version, copyright, and build stamping output: need to add trivial code
  • traversing htmlFiles/Dirs: need to move code from v1.6-

Many changes have been made and this revision will need much more testing to work out kinks.

comment:43 in reply to:  39 Changed 9 years ago by Rawld Gill

Replying to rbackhouse:

I'm attempting to build off the trunk and its failings looking for "util/build/transforms/dojoBoot.js" which is defined as a dependency in util/build/transforms/writeDojo.js

Sorry about that. I've added the missing file.

Thanks for the report!

comment:44 Changed 9 years ago by James Thomas

Building with a v1 profile with the dojo.js layer defined throws an exception. For example if you try to build with "baseplus.profile.js", I see the following issue:

ERROR: /Users/james/Code/DTK/dojotoolkit/dojo/dojo.js and /Users/james/Code/DTK/dojotoolkit/dojo/dojo.js are both attempting to write into /Users/james/Code/DTK/dojotoolkit/release/dojo/dojo/dojo.js

The build appears to complete successfully but looking in the dojo.js.uncompressed.js file, the extra layer dependencies haven't been added.

comment:45 Changed 9 years ago by Rawld Gill

(In [24935]) fixed machinery to build augmented dojo.js and custom base dojo.js; refs #12673; !strict

comment:46 in reply to:  44 Changed 9 years ago by Rawld Gill

Replying to jamesthomas:

Building with a v1 profile with the dojo.js layer defined throws an exception. For example if you try to build with "baseplus.profile.js", I see the following issue:

ERROR: /Users/james/Code/DTK/dojotoolkit/dojo/dojo.js and /Users/james/Code/DTK/dojotoolkit/dojo/dojo.js are both attempting to write into /Users/james/Code/DTK/dojotoolkit/release/dojo/dojo/dojo.js

The build appears to complete successfully but looking in the dojo.js.uncompressed.js file, the extra layer dependencies haven't been added.

Augmented or custom base dojo.js instructions were not processed correctly; fixed in [24935] and verified with baseplus profile; still need more tests, but appears OK

comment:47 Changed 9 years ago by bill

(In [24944]) dojo.require(this.widget) confuses AMD builder. Could load the resource through require([]), or just require that the user load it before hand. For now, doing the latter. Refs #12673 !strict.

comment:48 Changed 9 years ago by Rawld Gill

(In [24951]) added copyright and build messages; improved optimizer status reporting; fixed off-by-one error in gate passing algorithm; refs #12673; !strict

comment:49 Changed 9 years ago by Rawld Gill

(In [24952]) added reporting to a file; refs #12673; !strict

comment:50 Changed 9 years ago by Rawld Gill

(In [24958]) added version-stamping feature; refs #12673; !strict

comment:51 Changed 9 years ago by Rawld Gill

(In [24965]) added css optimization transform; refs #12673

comment:52 Changed 9 years ago by bill

(In [24967]) automatically detect if node is present (and use it if it is), refs #12673

comment:53 Changed 9 years ago by bill

(In [24971]) Fix build warnings by removing dojo.provide() calls from assistants/* files.

The dojo.provide() calls were incorrect since they didn't match the names of the files, and they were unneeded since the files were loaded through SceneController via dojo.xhrGet() and dojo.eval(), rather than through the loader.

Refs #12673 !strict

comment:54 Changed 9 years ago by Chris Mitchell

The following issues with the build tool have been reported using of trunk with your latest updates this morning (shows up in the mobileGeoCharting demo when built):

1) dijit/templates is not copied over so a few demos that reference the HTML templates there fail. 2) dojo/cldr/nls is built but a compressed version is not there (i.e. there's a number.js.uncompressed.js but not a number.js). So a few references to dojo/cldr/nls/number.js will fail causing demos to break. 3) Do dependencies have to be explicitly listed now? When I build the demos for instance, I only listed the "demos.mobile*.src" as a dependency. Yesterday, any referenced dependency would be written out to the src.js file (i.e. dojox.mobile, dojox.mobile.EdgeToEdgeCategory?, etc.). but now it doesn't write out dependencies to the src.js file. Does this have to do with the async?

comment:55 Changed 9 years ago by Chris Mitchell

Another issue found this morning:

4) In the mobileGeoCharting (with cssOptimize on), the CSS doesn't optimize URL images links correctly.

In dojox/geo/charting/resources/Map.css, there's a:


.mapZoomIn {
    width: 21px;
    height: 21px;
    background: url(img/zoomin.png) no-repeat;
    position: absolute;
}

In the mobileGeoCharting demo's optimized CSS, it becomes:

.mapZoomIn {width: 21px; height: 21px; background: url(../../dojox/geo/charting/resourcesimg/zoomin.png) no-repeat; position: absolute;}

Notice that it is resourcesimg instead of resources/img with the /.

comment:56 Changed 9 years ago by Chris Mitchell

Another issue found...Dojo build scripts not honoring "releaseDir" value (this breaks our build environment, and may break customer's if they depend on it in their build environments)

In 1.6 the following commands result in a dojo_optimized directory being created as a peer to the top-level dojo directory.

In 1.7 the dojo_optimized directory is created at dojo/dojo/util/dojo_optimized.

cd dojo/dojo/util/buildscripts
./build.sh profileFile=profiles/myprofile.profile.js version=1.6 action=clean,release stripConsole=all layerOptimize=shrinksafe optimize=shrinksafe releaseDir=../../../ cssOptimize=comments releaseName=dojo_optimized copyTests=false

comment:57 in reply to:  56 Changed 9 years ago by Chris Mitchell

Replying to chrism:

Another issue found...Dojo build scripts not honoring "releaseDir" value (this breaks our build environment, and may break customer's if they depend on it in their build environments)

In 1.6 the following commands result in a dojo_optimized directory being created as a peer to the top-level dojo directory.

In 1.7 the dojo_optimized directory is created at dojo/dojo/util/dojo_optimized.

cd dojo/dojo/util/buildscripts
./build.sh profileFile=profiles/myprofile.profile.js version=1.6 action=clean,release stripConsole=all layerOptimize=shrinksafe optimize=shrinksafe releaseDir=../../../ cssOptimize=comments releaseName=dojo_optimized copyTests=false

Just realized the releaseDir problem was reported late last night...it's now working as of this morning--thx!

comment:58 Changed 9 years ago by Chris Mitchell

we're working on updates for windows builds (rhino/node)...should have patch for both soon.

comment:59 Changed 9 years ago by Chris Mitchell

Is the new build tool handling requireIf'sproperly? At first glance, the requireIf does not seems to be supported yet, instead, the script seems to stop with

InternalError?: missing ; before statement

followed by a cryptic trace...

comment:60 Changed 9 years ago by Chris Mitchell

there is still a regression from 1.6 with the relative paths in the releaseDir option. Here's an example that fails still:

cd dojo/util/buildscripts/
./build.sh profile=uploader version=1.7 action=clean,release stripConsole=all layerOptimize=shrinksafe optimize=shrinksafe releaseDir=../../../ cssOptimize=comments releaseName=dojo_optimized copyTests=false

When this same build is executed with an absolute path on releaseDir and it does work. So apparently it's just relative dirs that it doesn't like. The buildscripts/build.sh does not 'cd' to anywhere else, so I guess the java code in the builder just doesn't handle relative dirs the same way as it did in 1.6.

comment:61 Changed 9 years ago by Douglas Hays

Resolution: fixed
Status: assignedclosed

(In [24981]) Fixes #12673. Use position:fixed+bottom:0 for devices that truly support it, and position:absolute+top for others.

comment:62 Changed 9 years ago by Douglas Hays

Resolution: fixed
Status: closedreopened

Closed wrong ticket #

comment:63 Changed 9 years ago by Douglas Hays

r24981 fixes #12970 instead

comment:64 Changed 9 years ago by Chris Mitchell

(In [24982]) refs #12673 add support for builds on windows !strict

comment:65 Changed 9 years ago by Chris Mitchell

(In [24983]) refs #12673 add support for builds on windows !strict

comment:66 Changed 9 years ago by Rawld Gill

(In [25005]) fixed isAbsolutePath bug due to node bug throwing on nonexisting file; fixed windows child process commands; fixed running for different location than util/buildscripts; added HTML file processing; refs #12673; !strict

comment:67 Changed 9 years ago by Rawld Gill

(In [25006]) improved warnings for package.json and dojo paths; refs #12673; !strict

comment:68 Changed 9 years ago by Rawld Gill

(In [25008]) improved loader to mark modules w/out factories as immediately executed; improved dojo/text plugin process with built code; refs #12672; refs #12673; !strict

comment:69 Changed 9 years ago by Rawld Gill

(In [25009]) fixed bug that wrote nls bundles to .uncompressed filename; fixed relative pathing bug in flattening css; refs #12673; !strict

comment:70 Changed 9 years ago by Ed Chatelain

The build does not seem to be pulling in the full dependency list for things which have been converted to the new amd format. An easy way to see this problem is to update demos/castle/src.js to include: dojo.require("dojox.color"); After the build the build-report.txt will show that demos/castle/src: includes dojox/color, but it does not include dojox/color/_base or dojo/color which are required by dojox/color. And when it is run those files are still pulled in individually. I am having the same problem with dojo.require("dojox.mvc"); dojo.require("dojox.mobile"); Thanks, Ed Chatelain

comment:71 Changed 9 years ago by Chris Mitchell

New problem as of trunk today from etissandier: The build tool embeds widget template strings in the code with a define(), but it does not seems to work in some cases, in particular for TextBox?.js

For example, optimized TextBox?.js code is :

define("*text/dijit/form/templates/TextBox.html", "<div class=\"dijit dijitReset dijitInline dijitLeft\" id=\"widget_${id}\" role=\"presentation\"\n\t><div class=\"dijitReset dijitInputField dijitInputContainer\"\n\t\t><input class=\"dijitReset dijitInputInner\" dojoAttachPoint='textbox,focusNode' autocomplete=\"off\"\n\t\t\t${!nameAttrSetting} type='${type}'\n\t/></div\n></div>\n");


define([
        "dojo",
        "..",
        "dojo/text!./templates/TextBox.html",
        "./_FormWidget",
        "./_TextBoxMixin"], function(dojo, dijit, template){


The template is embedded, but inside the define function, the template variable is an object with no parameter instead of the template string.

The unoptimized version in trunk works fine.

comment:72 Changed 9 years ago by Chris Mitchell

Another issue reported from etissandier: We notice that the build system is adding some AMD code on top of some of the Dojo files.

For example in the dojox/dtl/_base.js although the file is already in AMD format, the tool adds the following lines on top of the files.

define(["dojo","dijit","dojox","dojox/string/Builder"], function(dojo, dijit, dojox){
dojo.getObject("dojox.dtl._base", 1);

It looks like this is happening because of the dojo.require in the method:

getBuffer: function(){
        dojo.require("dojox.string.Builder");
        return new dojox.string.Builder();
}

This looks like a case of a Dojo 1.6 module that was not completely converted to AMD.

In the case of dojox.dtl, this seems to break the loading of the dtl module completly. The unoptimized version runs fine.
Build tool needs to detect the case where dojo 1.6- dojo.provides/dojo.requires are inside a AMD-define closure, and log warning/error appropriately.

comment:73 Changed 9 years ago by Chris Mitchell

build_release.sh does not work on trunk... dojo.js contains "undefined;" in its contents

comment:74 in reply to:  73 Changed 9 years ago by Chris Mitchell

Replying to chrism:

build_release.sh does not work on trunk... dojo.js contains "undefined;" in its contents


More info from Mike Rheinheimer, IBM... The inclusion of any value other than "1.7.0" as the value in the "version" parameter on the build command line breaks it. For example, version=1.7 will result in dojo.js with "undefined;"

comment:75 Changed 9 years ago by Rawld Gill

(In [25025]) fixed bug in version stamping build; refs #12673

comment:76 Changed 9 years ago by Rawld Gill

(In [25042]) fixed r24951 caused wrong output when a copyright message is not given; refs #12673; !strict

comment:77 in reply to:  19 Changed 9 years ago by ben hockey

Replying to neonstalwart:

if i have the following structure, test.modules.foo is not included in the test/test.js output

<snip> transferred to #12995

comment:78 Changed 9 years ago by Rawld Gill

(In [25062]) fixed version stamping; removed support for cjs package lib machinery; refs #12673; fixes #12996; !strict

comment:79 Changed 9 years ago by Ed Chatelain

After svn update, I am getting the error below: Did you forget to commit version.js?

dyn9-37-238-130:buildscripts edchatelain$ ./build.sh action=release profile=demos-all version=1.7.0 running under rhino loader/sync-inject build*version ../../util/build/version.js JavaException?: java.net.MalformedURLException: no protocol: ../../util/build/version.js loader/exec [object Object] JavaException?: java.net.MalformedURLException: no protocol: ../../util/build/version.js build*main

function (a1, a2, a3) {

return contextRequire(a1, a2, a3, module, result);

}

function (name) {

return hasCache[name] = isFunction(hasCache[name]) ? hasCache[name](global, doc, element) : hasCache[name];

}

js: "../../dojo/dojo.js", line 805: exception from uncaught JavaScript? throw: JavaException?: java.net.MalformedURLException: no protocol: ../../util/build/version.js

comment:80 Changed 9 years ago by Rawld Gill

(In [25083]) added missing file; refs #12673

comment:81 in reply to:  17 Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

Replying to rcgill:

There is no logger in the new build system. Can you tell me your use case? I added this item to the TODO list in comment #8.

As mentioned, there is no more logger in the build system and the configuration switch "log" has been deprecated and is ignored. The build system has been fixed to consume log setting and/or logger calls...actions are always to print a deprecated message. This allows old profiles to be consumed without modification.

comment:82 in reply to:  18 Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

if you try to build the baseplus profile of dojo, the extra modules (dijit._Widget, dijit._Templated, dojo.fx and dojo.NodeList?-fx) are not included in dojo.js

fixed.

comment:83 in reply to:  19 ; Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

if i have the following structure, test.modules.foo is not included in the test/test.js output

test
  test.js
  bar.js
  modules
    foo.js

test.js

dojo.provide('test.test');

dojo.require('test.modules.foo');
dojo.require('test.bar');

is there something special with modules that is causing this?

Should be fixed; I have a local test case that's nearly identical. Please retry an open a new ticket if it's still a problem.

comment:84 in reply to:  21 Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

the default value for releaseName used to be 'dojo'. now if releaseName is not specified, the output is placed directly in releaseDir/release rather than releaseDir/release/dojo

fixed.

comment:85 in reply to:  22 Changed 9 years ago by Rawld Gill

Replying to neonstalwart:

dojo.version does not report the version from the profile. also, the build tool used to output the version number as part of it's logging when it was doing the build. something like:

Building with version x.x.x.xxx

it was useful for verifying what you were doing.

The version from the profile is fixed.

The build tool doesn't report the version of any particular package that's included in a build, including dojo since we're trying to move away from dojo having a special status within the build system.

Note that it is quite possible to run the build program with one version of dojo and build another version.

This issue moved to #13025

comment:86 in reply to:  24 Changed 9 years ago by Rawld Gill

Replying to bluk:

the optimizer is not turned on (code is in repo)
css optimization is not turned on (code is in repo)

Is there any way to turn those on to try to get an optimized build? TIA!

fixed

comment:87 in reply to:  47 Changed 9 years ago by Rawld Gill

Replying to bill:

(In [24944]) dojo.require(this.widget) confuses AMD builder. Could load the resource through require([]), or just require that the user load it before hand. For now, doing the latter. Refs #12673 !strict.

This is an intended enhancement. The version 1.6- builder would silently ignore such applications. The 1.7 build system warns (that's changed from error when this report was originally made). It's up to the user to determine if the warning is an error or not...the build will ignore the application other than issuing the warning.

comment:88 in reply to:  54 Changed 9 years ago by Rawld Gill

Replying to chrism:

The following issues with the build tool have been reported using of trunk with your latest updates this morning (shows up in the mobileGeoCharting demo when built):

3) Do dependencies have to be explicitly listed now? When I build the demos for instance, I only listed the "demos.mobile*.src" as a dependency. Yesterday, any referenced dependency would be written out to the src.js file (i.e. dojox.mobile, dojox.mobile.EdgeToEdgeCategory?, etc.). but now it doesn't write out dependencies to the src.js file. Does this have to do with the async?

I don't quite understand what you're saying here. Could you recheck and if you still see an error start a new ticket.

Thanks!

comment:89 in reply to:  59 Changed 9 years ago by Rawld Gill

Replying to chrism:

Is the new build tool handling requireIf'sproperly? At first glance, the requireIf does not seems to be supported yet, instead, the script seems to stop with

InternalError?: missing ; before statement

followed by a cryptic trace...

moved to #13026

comment:90 in reply to:  72 Changed 9 years ago by Rawld Gill

Replying to chrism:

Another issue reported from etissandier: We notice that the build system is adding some AMD code on top of some of the Dojo files.

For example in the dojox/dtl/_base.js although the file is already in AMD format, the tool adds the following lines on top of the files.

define(["dojo","dijit","dojox","dojox/string/Builder"], function(dojo, dijit, dojox){
dojo.getObject("dojox.dtl._base", 1);

It looks like this is happening because of the dojo.require in the method:

getBuffer: function(){
        dojo.require("dojox.string.Builder");
        return new dojox.string.Builder();
}

This looks like a case of a Dojo 1.6 module that was not completely converted to AMD.

In the case of dojox.dtl, this seems to break the loading of the dtl module completly. The unoptimized version runs fine.
Build tool needs to detect the case where dojo 1.6- dojo.provides/dojo.requires are inside a AMD-define closure, and log warning/error appropriately.

moved to #13028

comment:91 Changed 9 years ago by Rawld Gill

Resolution: fixed
Status: reopenedclosed

Closing this ticket. All reported issues are either fixed or moved to other tickets.

If you find an issue that wasn't moved and wasn't fixed, then please open a new ticket.

comment:92 Changed 9 years ago by bill

Component: GeneralBuildSystem

comment:93 in reply to:  83 Changed 9 years ago by ben hockey

Replying to rcgill:

Should be fixed; I have a local test case that's nearly identical. Please retry an open a new ticket if it's still a problem.

fyi - i had already transferred this problem to #12995 and this morning confirmed that it is still an issue. modules in part of the path seems to be a problem. we can continue discussing over at #12995 but let me know if you need me to zip up a failing test case if your local test already includes a modules folder with content and doesn't fail.

comment:94 Changed 9 years ago by Rawld Gill

(In [25302]) fixed loading cached modules in ie; refs #12672, #12673; !strict

comment:95 Changed 9 years ago by Rawld Gill

(In [25343]) improved builder to rescope cached (interned) text resources; fixed had fixup when regex fails, re-added log level switch; refs #12673; refs #13157; !strict

comment:96 Changed 9 years ago by Rawld Gill

(In [25431]) inserted version info into package.json files; refs #12673; !strict

comment:97 Changed 9 years ago by Rawld Gill

(In [25433]) updated build scripts to insert version number in proper files and write absolute module ids in released code; refs #12673

comment:98 Changed 8 years ago by Rawld Gill

(In [25635]) removed part of old builder to keep folks from trying to use it; more to remove but some of jslib may be used for other tasks so care is needed; refs #12673

comment:99 Changed 8 years ago by Rawld Gill

In [26633]:

removed cruft; improved msg machinery; ensure directories created for reports; added debug dump; fixes #13679; refs #12673; !strict

comment:100 Changed 8 years ago by Rawld Gill

In [26644]:

fixed assumptions about packages introduced in [26634]; refs #12673; !strict

comment:101 Changed 8 years ago by Rawld Gill

In [26783]:

removed compactCss transform which is unused and has similar features to optimizeCss transform; refs #12673; !strict

Note: See TracTickets for help on using tickets.