Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#14166 closed defect (fixed)

[regression] layers.profile.js shipped with Dojo 1.7 fails to build

Reported by: Kenneth G. Franqueiro Owned by: Rawld Gill
Priority: high Milestone: 1.7.1
Component: BuildSystem Version: 1.7.0
Keywords: Cc: Colin Snover
Blocked By: Blocking:

Description

It seems that the discard property in legacy build profiles might be tripping up the new builder. I observed the following result simply by attempting to build the example layers.profile.js which ships with DTK:

> build.bat profile=layers releaseName=layers action=release

> java -Xms256m -Xmx256m  -cp ../shrinksafe/js.jar;../closureCompiler/compiler.jar;../shrinksafe/shrinksafe.jar org.mozilla.javascript.tools.shell.Main  ../../dojo/dojo.js baseUrl=../../dojo load=build profile=layers releaseName=layers action=release
error(350) Cannot deduce module identifier from layer name layer name: string.discard
error(349) Missing prefix for top-level module. top-level module: string
processing profile resource .../util/buildscripts/profiles/layers.profile.js
errors on command line; terminating application.

(Problem hinted at by vvoovv on IRC, who has been trying to build his own profile with a discarded layer.)

Change History (14)

comment:1 Changed 8 years ago by Kenneth G. Franqueiro

csnover has pointed out that this problem is actually due to the name/resourceName being given to the discarded layer, and not the discard flag itself.

comment:2 Changed 8 years ago by Kenneth G. Franqueiro

Priority: normalhigh

comment:3 Changed 8 years ago by bill

Cc: Colin Snover added

In today's meeting, we said that the discard flag isn't supported anymore. Colin will update release notes and reference doc. Rawld will update that sample layers.profile.js file to not use the discard flag, and close this ticket.

Last edited 8 years ago by bill (previous) (diff)

comment:4 Changed 8 years ago by Colin Snover

Release notes and writeAmd docs have been updated.

comment:5 Changed 8 years ago by Rawld Gill

Since the v1.6- build docs have been neglected and are sometimes inaccurate and/or incomplete; here is a quick summary of the key points:

A v1.6- profile must define an object named "dependencies" that contains the following properties:

  • <name>, where <name> is other than "layers" or "prefixes"; these property values set various build switches
  • the property "prefixes", an array of prefix pairs that gives the path to each top-level module
  • the property "layers", an array of layer objects that say how to build any layers

The prefixes array gives the source location of each top-level module. If a relative path is given, then it assumed to be relative to the src dojo directory. If a top-level module is referenced in the layers array and is not present in the prefixes array, then it is assumed to be a sibling of the dojo directory.

If the dojo prefix is not given, then it is assumed to be ../../dojo. The v1.6 build program must be executed with util/buildscripts/ as the current working directly. These two facts combine to cause dojo to point to the correct location.

In v1.6-, all module trees are unconditionally written to the release directory as siblings (that is, every top-level module is a sibling of dojo).

A "layer" object has the properties:

  • "name", destination filename, *always* relative to the dojo directory
  • "resourceName", the dotted name that is used for the dojo.provide for this layer
  • "dependencies", an array of dotted-names as would be provided to dojo.require, there are the modules that comprise this layer
  • "layerDependencies", an array of resource filenames that reference modules that are explicitly excluded from this layer.
  • "copyrightFile", a filename that holds a copyright message to insert into the layer

A layer is composed by including the dependency tree implied by the modules given in dependencies, then excluding any modules in the dependency tree implied by the modules given by layerDependencies.

Notice that the name property can be derived from the resourceName property. It is redundant unless you are trying to make a utterly defective layer (e.g., creating the module my.module and writing it to your/module). If resourceName is provided, then name is ignored. Otherwise, if resourceName is not given, then the destination module name of the layer is derived from name.

Notice that layerDependencies gives filenames and not module names. This is particularly vexing: a layer and its dependencies are defined as a modules and consumed as modules by the loader, yet layerDependencies is given in terms of a resource filepath.

Lastly notice that the word "dependencies" is highly overloaded:

  • the profile must defines a dependencies object
  • each layer must define a dependencies array
  • each layer must define a layerDependencies array

The v1.7 build system make an strong effort to decode v1.6- profile contents. However, in some cases, backcompat may not work. If you stuble across one of these cases, the best way forward is to construct a v1.7-compatible build profile. It is easier, more rational, and much more powerful than the v1.6 variant.

comment:6 Changed 8 years ago by Rawld Gill

Resolution: fixed
Status: newclosed

In [27257]:

improve backcompat for v1.6 profiles; fixes #14166; !strict

comment:7 Changed 8 years ago by Rawld Gill

The layers profile is an example of very-old build practices. It describes a top-level module (string...not dojo/string) that is used to create the discarded module string.discard.

As of v1.7, the build system does not automatically add prefixes for top-level modules: you must explicitly provide them in the prefix array. If there is significant pushback on this decision, we can revisit it. However, note that all dojo stock profiles provide prefixes for all top level modules except dojo.

[27257] includes the necessary fix (including a prefix) to the layers profile to make is work. However, the layers profile is subsequently deleted in a commit noted below since it is not a useful example.

By far the best answer for those experiencing problems with v1.6 layers is to update your profiles to use the v1.7 layers format.

comment:8 Changed 8 years ago by Rawld Gill

In [27259]:

removed profile since it is a bad example; refs #14166; !strict

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

Replying to bill:

In today's meeting, we said that the discard flag isn't supported anymore. Colin will update release notes and reference doc. Rawld will update that sample layers.profile.js file to not use the discard flag, and close this ticket.

I was wrong in the meeting. The discard flag is supported. This was not the problem. as described on other notations on this ticket.

That said, I still believe the discard feature isn't very interesting/useful.

comment:10 Changed 8 years ago by Kenneth G. Franqueiro

One question about [27257]: what's the effect of removing the default 'dojo-scopeMap':1 ? (Is it something that causes effects we'll need to document?)

Also, is there a good place in the docs to include http://bugs.dojotoolkit.org/ticket/14166#comment:5 ? (Though I'd make one correction: IIRC layerDependencies is not required.)

comment:11 in reply to:  10 Changed 8 years ago by Rawld Gill

Replying to kgf:

One question about [27257]: what's the effect of removing the default 'dojo-scopeMap':1 ? (Is it something that causes effects we'll need to document?)

zero effect. It's not referenced anywhere in the dtk code near as I can tell.

comment:12 Changed 8 years ago by Kenneth G. Franqueiro

Resolution: fixed
Status: closedreopened

This needs to be backported to 1.7 branch, reopening so we don't forget...

comment:13 Changed 8 years ago by Rawld Gill

Resolution: fixed
Status: reopenedclosed

In [27294]:

backport [27257] and [27259]; fixes #14166; !strict

comment:14 Changed 8 years ago by Rawld Gill

fixed and backported to 1.7.1

Note: See TracTickets for help on using tickets.