Commit cdad10dc authored by David Prévot's avatar David Prévot

Imported Upstream version 1.11.0+dfsg

parents ff3735cb afd327d2
......@@ -29,7 +29,7 @@ If your desired contribution is more than a non-trivial fix, you should discuss
We require all contributions, to be covered under the Dojo Foundation's [Contributor License Agreement][cla]. This can
be done electronically and essentially ensures that you are making it clear that your contributions are your
contributions, you have the legal right to contribute and you are transferring the copyright of your works to the Dojo
contributions, you have the legal right to contribute and you are transferring the copyright of your works to the Dojo
Foundation.
If you are an unfamiliar contributor to the committer assessing your pull request, it is best to make it clear how
......@@ -194,7 +194,7 @@ documentation appropriately or added the appropriate inline documentation.
If the pull request changes the functional behaviour or is fixing a defect, the unit test cases should be modified to
reflect this. The committer reviewing your pull request is likely to request the appropriate changes in the test
cases. Dojo utilises its own test harness called [D.O.H.][] and is available as part of the [dojo/util][] repository.
cases. Dojo utilises [Intern][] for all new tests, and has legacy support for its previous generation test harness called [D.O.H.][] and is available as part of the [dojo/util][] repository. All new tests should be authored using Intern.
It is expected that you will have tested your changes against the existing test cases and appropriate platforms prior to
submitting your pull request.
......@@ -219,6 +219,7 @@ unfamiliar to those who are just starting to contribute.
[claCheck]: http://dojofoundation.org/about/claCheck
[Creating a Pull Request]: https://help.github.com/articles/creating-a-pull-request
[Fork a Repo]: https://help.github.com/articles/fork-a-repo
[Intern]: http://theintern.io/
[styleguide]: http://dojotoolkit.org/reference-guide/developer/styleguide.html
[DojoDoc]: http://dojotoolkit.org/reference-guide/developer/markup.html
[D.O.H.]: http://dojotoolkit.org/reference-guide/util/doh.html
......
......@@ -400,7 +400,7 @@ define([
this._supportingWidgets = [];
// this is here for back-compat, remove in 2.0 (but check NodeList-instantiate.html test)
if(this.srcNodeRef && (typeof this.srcNodeRef.id == "string")){
if(this.srcNodeRef && this.srcNodeRef.id && (typeof this.srcNodeRef.id == "string")){
this.id = this.srcNodeRef.id;
}
......
......@@ -15,8 +15,8 @@
"url": "https://github.com/dojo/dijit.git"
},
"dependencies": {
"dojo": "1.11.0-rc3"
"dojo": "1.11.0"
},
"devDependencies": {
},
}
}
{
"name": "dijit",
"version": "1.11.0-rc3",
"version": "1.11.0",
"directories": {
"lib": "."
},
"main": "main",
"dependencies": {
"dojo": "1.11.0-rc3"
"dojo": "1.11.0"
},
"description": "Dijit provides a complete collection of user interface controls based on Dojo, giving you the power to create web applications that are highly optimized for usability, performance, internationalization, accessibility, but above all deliver an incredible user experience.",
"license" : "BSD-3-Clause OR AFL-2.1",
......
......@@ -94,7 +94,30 @@
doh.isNot(undefined, w.id)
}
}
},
{
name: "create where id specified in prototype",
runTest: function(t){
declare("TestWidgetWithId", _WidgetBase, {
id: "id-in-prototype"
});
// Creating without an id should use the id in the prototype
w = new TestWidgetWithId();
w.placeAt(document.body);
doh.t(registry.byId("id-in-prototype"), "widget in registry");
doh.is(w.domNode, dom.byId("id-in-prototype"), "id on domnode");
w.destroy();
// Then try overriding id
w = new TestWidgetWithId({id: "override"});
w.placeAt(document.body);
doh.t(registry.byId("override"), "widget in registry");
doh.is(w.domNode, dom.byId("override"), "id on domnode");
w.destroy();
}
},
]);
doh.register("setter calls on creation", function(){
......
......@@ -513,6 +513,7 @@
var tc = registry.byId("ttabs");
winUtils.scrollIntoView(tc.domNode);
doh.is(4, tc.getChildren().length, "num tabs before trying to close one");
dom.byId("ttabs_tablist_ttab1").focus();
......@@ -531,7 +532,7 @@
robot.keyPress(keys.ENTER, 500, {});
robot.sequence(d.getTestCallback(function(){
doh.is(2, tc.getChildren().length, "remaining tabs");
doh.is(3, tc.getChildren().length, "remaining tabs");
doh.is("ttab2", tc.selectedChildWidget.id,
"selection moved to next tab (since first tab was deleted)");
}), 500);
......
......@@ -50,11 +50,15 @@ table.dijitInline {
position: absolute; /* remove from normal document flow to simulate display: none */
visibility: hidden; /* hide element from view, but don't break scrolling, see #18612 */
}
.dijitHidden * {
visibility: hidden !important; /* hide visibility:visible descendants of class=dijitHidden nodes, see #18799 */
}
.dijitVisible {
/* To show selected pane in StackContainer etc. */
display: block !important; /* override user's display:none setting via style setting or indirectly via class */
position: relative; /* to support setting width/height, see #2033 */
visibility: visible;
}
.dj_ie6 .dijitComboBox .dijitInputContainer,
......
......@@ -29,7 +29,7 @@ If your desired contribution is more than a non-trivial fix, you should discuss
We require all contributions, to be covered under the Dojo Foundation's [Contributor License Agreement][cla]. This can
be done electronically and essentially ensures that you are making it clear that your contributions are your
contributions, you have the legal right to contribute and you are transferring the copyright of your works to the Dojo
contributions, you have the legal right to contribute and you are transferring the copyright of your works to the Dojo
Foundation.
If you are an unfamiliar contributor to the committer assessing your pull request, it is best to make it clear how
......@@ -194,7 +194,7 @@ documentation appropriately or added the appropriate inline documentation.
If the pull request changes the functional behaviour or is fixing a defect, the unit test cases should be modified to
reflect this. The committer reviewing your pull request is likely to request the appropriate changes in the test
cases. Dojo utilises its own test harness called [D.O.H.][] and is available as part of the [dojo/util][] repository.
cases. Dojo utilises [Intern][] for all new tests, and has legacy support for its previous generation test harness called [D.O.H.][] and is available as part of the [dojo/util][] repository. All new tests should be authored using Intern.
It is expected that you will have tested your changes against the existing test cases and appropriate platforms prior to
submitting your pull request.
......@@ -219,6 +219,7 @@ unfamiliar to those who are just starting to contribute.
[claCheck]: http://dojofoundation.org/about/claCheck
[Creating a Pull Request]: https://help.github.com/articles/creating-a-pull-request
[Fork a Repo]: https://help.github.com/articles/fork-a-repo
[Intern]: http://theintern.io/
[styleguide]: http://dojotoolkit.org/reference-guide/developer/styleguide.html
[DojoDoc]: http://dojotoolkit.org/reference-guide/developer/markup.html
[D.O.H.]: http://dojotoolkit.org/reference-guide/util/doh.html
......
......@@ -80,7 +80,7 @@ define(["../has", "./config", "require", "module"], function(has, config, requir
dojo.isAsync = !has("dojo-loader") || require.async;
dojo.locale = config.locale;
var rev = "$Rev: 9a1699e $".match(/[0-9a-f]{7,}/);
var rev = "$Rev: 382e75b $".match(/[0-9a-f]{7,}/);
dojo.version = {
// summary:
// Version number of the Dojo Toolkit
......@@ -93,7 +93,7 @@ define(["../has", "./config", "require", "module"], function(has, config, requir
// - flag: String: Descriptor flag. If total version is "1.2.0beta1", will be "beta1"
// - revision: Number: The Git rev from which dojo was pulled
major: 1, minor: 11, patch: 0, flag: "-rc3",
major: 1, minor: 11, patch: 0, flag: "",
revision: rev ? rev[0] : NaN,
toString: function(){
var v = dojo.version;
......
......@@ -24,5 +24,5 @@
"jsgi-node": "0.3.1",
"formidable": "1.0.14",
"sinon": "1.12.2"
},
}
}
{
"name": "dojo",
"version": "1.11.0-rc3",
"version": "1.11.0",
"directories": {
"lib": "."
},
......@@ -11,7 +11,7 @@
"jsgi-node": "0.3.1",
"formidable": "1.0.14",
"sinon": "1.12.2",
"dojo": "1.11.0-rc3"
"dojo": "1.11.0"
},
"main": "main",
"scripts": {
......
......@@ -29,7 +29,7 @@ If your desired contribution is more than a non-trivial fix, you should discuss
We require all contributions, to be covered under the Dojo Foundation's [Contributor License Agreement][cla]. This can
be done electronically and essentially ensures that you are making it clear that your contributions are your
contributions, you have the legal right to contribute and you are transferring the copyright of your works to the Dojo
contributions, you have the legal right to contribute and you are transferring the copyright of your works to the Dojo
Foundation.
If you are an unfamiliar contributor to the committer assessing your pull request, it is best to make it clear how
......@@ -194,7 +194,7 @@ documentation appropriately or added the appropriate inline documentation.
If the pull request changes the functional behaviour or is fixing a defect, the unit test cases should be modified to
reflect this. The committer reviewing your pull request is likely to request the appropriate changes in the test
cases. Dojo utilises its own test harness called [D.O.H.][] and is available as part of the [dojo/util][] repository.
cases. Dojo utilises [Intern][] for all new tests, and has legacy support for its previous generation test harness called [D.O.H.][] and is available as part of the [dojo/util][] repository. All new tests should be authored using Intern.
It is expected that you will have tested your changes against the existing test cases and appropriate platforms prior to
submitting your pull request.
......@@ -219,6 +219,7 @@ unfamiliar to those who are just starting to contribute.
[claCheck]: http://dojofoundation.org/about/claCheck
[Creating a Pull Request]: https://help.github.com/articles/creating-a-pull-request
[Fork a Repo]: https://help.github.com/articles/fork-a-repo
[Intern]: http://theintern.io/
[styleguide]: http://dojotoolkit.org/reference-guide/developer/styleguide.html
[DojoDoc]: http://dojotoolkit.org/reference-guide/developer/markup.html
[D.O.H.]: http://dojotoolkit.org/reference-guide/util/doh.html
......
......@@ -15,9 +15,9 @@
"url": "https://github.com/dojo/dojox.git"
},
"dependencies": {
"dojo": "1.11.0-rc3",
"dijit": "1.11.0-rc3"
"dojo": "1.11.0",
"dijit": "1.11.0"
},
"devDependencies": {
},
}
}
{
"name": "dojox",
"version": "1.11.0-rc3",
"version": "1.11.0",
"directories": {
"lib": "."
},
"main": "main",
"dependencies": {
"dojo": "1.11.0-rc3",
"dijit": "1.11.0-rc3"
"dojo": "1.11.0",
"dijit": "1.11.0"
},
"description": "Dojo eXtensions, a rollup of many useful sub-projects and varying states of maturity – from very stable and robust, to alpha and experimental. See individual projects contain README files for details.",
"license" : "BSD-3-Clause OR AFL-2.1",
......
_Do you have a contribution? We welcome contributions, but please ensure that you read the following information
before issuing a pull request. Also refer back to this document as a checklist before issuing your pull request.
This will save time for everyone._
# Before You Start
## Understanding the Basics
If you don't understand what a *pull request* is, or how to submit one, please refer to the [help documentation][]
provided by GitHub.
## Is It Really a Support Issue
If you aren't sure if your contribution is needed or necessary, please visit the [support forum][] before attempting to
submit a pull request or a ticket.
## Search Dojo Toolkit's Bug Database
We require every commit to be tracked via our [bug database][]. It is useful, before you get too far, that you have
checked that your issue isn't already known, otherwise addressed? If you think it is a valid defect or enhancement,
please open a new ticket before submitting your pull request.
## Discuss Non-Trivial Contributions with the Committers
If your desired contribution is more than a non-trivial fix, you should discuss it on the
[contributor's mailing list][dojo-contrib]. If you currently are not a member, you can request to be added.
## Contributor License Agreement
We require all contributions, to be covered under the Dojo Foundation's [Contributor License Agreement][cla]. This can
be done electronically and essentially ensures that you are making it clear that your contributions are your
contributions, you have the legal right to contribute and you are transferring the copyright of your works to the Dojo
Foundation.
If you are an unfamiliar contributor to the committer assessing your pull request, it is best to make it clear how
you are covered by a CLA in the notes of the pull request. The committer will [verify][claCheck] your status.
If your GitHub user id you are submitting your pull request from differs from the Dojo Community ID or e-mail address
which you have signed your CLA under, you should specifically note what you have your CLA filed under (and for CCLA
that you are listed under your company's authorised contributors).
# Submitting a Pull Request
The following are the general steps you should follow in creating a pull request. Subsequent pull requests only need
to follow step 3 and beyond:
1. Fork the repository on GitHub
2. Clone the forked repository to your machine
3. Create a "feature" branch in your local repository
4. Make your changes and commit them to your local repository
5. Rebase and push your commits to your GitHub remote fork/repository
6. Issue a Pull Request to the official repository
7. Your Pull Request is reviewed by a committer and merged into the repository
*Note*: While there are other ways to accomplish the steps using other tools, the examples here will assume the most
actions will be performed via the `git` command line.
## 1. Fork the Repository
When logged in to your GitHub account, and you are viewing one of the main repositories, you will see the *Fork* button.
Clicking this button will show you which organizations your can fork to. Choose your own account. Once the process
finishes, you will have your own repository that is "forked" from the official one.
Forking is a GitHub term and not a git term. Git is a wholly distributed source control system and simply worries
about local and remote repositories and allows you to manage your code against them. GitHub then adds this additional
layer of structure of how repositories can relate to each other.
## 2. Clone the Forked Repository
Once you have successfully forked your repository, you will need to clone it locally to your machine:
```bash
$ git clone --recursive git@github.com:username/themes.git
```
This will clone your fork to your current path in a directory named `themes`.
To test your work in this repo against Dojo, Dijit, DojoX, and dgrid, you will need to either include the relevant
release locally, or clone those repositories as well.
You should also set up the `upstream` repository. This will allow you to take changes from the "master" repository
and merge them into your local clone and then push them to your GitHub fork:
```bash
$ cd themes
$ git remote add upstream git@github.com:dojo/themes.git
$ git fetch upstream
```
Then you can retrieve upstream changes and rebase on them into your code like this:
```bash
$ git pull --rebase upstream master
```
For more information on maintaining a fork, please see the GitHub Help article [Fork a Repo][] and information on
[rebasing][] from git.
## 3. Create a Branch
The easiest workflow is to keep your master branch in sync with the upstream branch and do not locate any of your own
commits in that branch. When you want to work on a new feature, you then ensure you are on the master branch and create
a new branch from there. While the name of the branch can be anything, it can often be easy to use the ticket number
you might be working on. For example:
```bash
$ git checkout -b t12345 master
Switched to a new branch 't12345'
```
You will then be on the feature branch. You can verify what branch you are on like this:
```bash
$ git status
# On branch t12345
nothing to commit, working directory clean
```
## 4. Make Changes and Commit
Now you just need to make your changes. Once you have finished your changes (and tested them) you need to commit them
to your local repository (assuming you have staged your changes for committing):
```bash
$ git status
# On branch t12345
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: somefile.js
#
$ git commit -m "Corrects some defect, fixes #12345, refs #12346"
[t12345 0000000] Corrects some defect, fixes #12345, refs #12346
1 file changed, 2 insertions(+), 2 deletions(-)
```
## 5. Rebase and Push Changes
If you have been working on your contribution for a while, the upstream repository may have changed. You may want to
ensure your work is on top of the latest changes so your pull request can be applied cleanly:
```bash
$ git pull --rebase upstream master
```
When you are ready to push your commit to your GitHub repository for the first time on this branch you would do the
following:
```bash
$ git push -u origin t12345
```
After the first time, you simply need to do:
```bash
$ git push
```
## 6. Issue a Pull Request
In order to have your commits merged into the main repository, you need to create a pull request. The instructions for
this can be found in the GitHub Help Article [Creating a Pull Request][]. Essentially you do the following:
1. Go to the site for your repository.
2. Click the Pull Request button.
3. Select the feature branch from your repository.
4. Enter a title and description of your pull request mentioning the corresponding [bug database][] ticket in the description.
5. Review the commit and files changed tabs.
6. Click `Send Pull Request`
You will get notified about the status of your pull request based on your GitHub settings.
## 7. Request is Reviewed and Merged
Your request will be reviewed. It may be merged directly, or you may receive feedback or questions on your pull
request.
# What Makes a Successful Pull Request?
Having your contribution accepted is more than just the mechanics of getting your contribution into a pull request,
there are several other things that are expected when contributing to the Dojo Toolkit which are covered below.
## Coding Style and Linting
Dojo has a very specific [coding style][styleguide]. All pull requests should adhere to this.
## Inline Documentation
Any non-obvious style rules should include a valid CSS comment.
## Licensing
All of your submissions are licensed under a dual "New" BSD/AFL license.
## Expect Discussion and Rework
Unless you have been working with contributing to Dojo for a while, expect a significant amount of feedback on your
pull requests. We are a very passionate community and even the committers often will provide robust feedback to each
other about their code. Don't be offended by such feedback or feel that your contributions aren't welcome, it is just
that we are quite passionate and Dojo has a long history with many things that are the "Dojo-way" which may be
unfamiliar to those who are just starting to contribute.
[help documentation]: http://help.github.com/send-pull-requests
[bug database]: http://bugs.dojotoolkit.org/
[support forum]: http://dojotoolkit.org/community/
[dojo-contrib]: http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
[cla]: http://dojofoundation.org/about/cla
[claCheck]: http://dojofoundation.org/about/claCheck
[Creating a Pull Request]: https://help.github.com/articles/creating-a-pull-request
[Fork a Repo]: https://help.github.com/articles/fork-a-repo
[styleguide]: http://dojotoolkit.org/reference-guide/developer/styleguide.html
[DojoDoc]: http://dojotoolkit.org/reference-guide/developer/markup.html
[dojo/util]: https://github.com/dojo/util
[interactive rebase]: http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages
[rebasing]: http://git-scm.com/book/en/Git-Branching-Rebasing
This diff is collapsed.
......@@ -14,7 +14,7 @@
"dependencies": {
},
"devDependencies": {
"stylus": "0.53.0",
"nib": "1.1.0"
"stylus": "0.53.0",
"nib": "1.1.0"
}
}
{
"name": "dojo-themes",
"version": "1.11.0-rc3",
"version": "1.11.0",
"description": "Dojo 1.x modern themes",
"license" : "BSD-3-Clause OR AFL-2.1",
"bugs": "http://bugs.dojotoolkit.org/",
......@@ -12,8 +12,8 @@
},
"dojoBuild": "themes.profile.js",
"peerDependencies": {
"dojo": "1.11.0-rc3",
"dijit": "1.11.0-rc3"
"dojo": "1.11.0",
"dijit": "1.11.0"
},
"devDependencies": {
"grunt": "^0.4",
......
......@@ -29,7 +29,7 @@ If your desired contribution is more than a non-trivial fix, you should discuss
We require all contributions, to be covered under the Dojo Foundation's [Contributor License Agreement][cla]. This can
be done electronically and essentially ensures that you are making it clear that your contributions are your
contributions, you have the legal right to contribute and you are transferring the copyright of your works to the Dojo
contributions, you have the legal right to contribute and you are transferring the copyright of your works to the Dojo
Foundation.
If you are an unfamiliar contributor to the committer assessing your pull request, it is best to make it clear how
......@@ -75,7 +75,7 @@ $ git clone --recursive git@github.com:username/util.git
This will clone your fork to your current path in a directory named `util`.
It is important that you clone recursively for ``dojox``, ``demos`` or ``util``because some of the code is contained in
It is important that you clone recursively for ``dojox``, ``demos`` or ``util`` because some of the code is contained in
submodules. You won't be able to submit your changes to the repositories that way though. If you are working on any of
these sub-projects, you should contact those project leads to see if their workflow differs.
......@@ -194,7 +194,7 @@ documentation appropriately or added the appropriate inline documentation.
If the pull request changes the functional behaviour or is fixing a defect, the unit test cases should be modified to
reflect this. The committer reviewing your pull request is likely to request the appropriate changes in the test
cases. Dojo utilises its own test harness called [D.O.H.][] and is available as part of the [dojo/util][] repository.
cases. Dojo utilises [Intern][] for all new tests, and has legacy support for its previous generation test harness called [D.O.H.][] and is available as part of the [dojo/util][] repository. All new tests should be authored using Intern.
It is expected that you will have tested your changes against the existing test cases and appropriate platforms prior to
submitting your pull request.
......@@ -219,9 +219,10 @@ unfamiliar to those who are just starting to contribute.
[claCheck]: http://dojofoundation.org/about/claCheck
[Creating a Pull Request]: https://help.github.com/articles/creating-a-pull-request
[Fork a Repo]: https://help.github.com/articles/fork-a-repo
[Intern]: http://theintern.io/
[styleguide]: http://dojotoolkit.org/reference-guide/developer/styleguide.html
[DojoDoc]: http://dojotoolkit.org/reference-guide/developer/markup.html
[D.O.H.]: http://dojotoolkit.org/reference-guide/util/doh.html
[dojo/util]: https://github.com/dojo/util
[interactive rebase]: http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages
[rebasing]: http://git-scm.com/book/en/Git-Branching-Rebasing
\ No newline at end of file
[rebasing]: http://git-scm.com/book/en/Git-Branching-Rebasing
......@@ -7,7 +7,7 @@ the directories in which they reside and in the code itself. No external
contributions are allowed under licenses which are fundamentally incompatible
with the AFL or BSD licenses that Dojo is distributed under.
The text of the AFL and BSD licenses is reproduced below.
The text of the AFL and BSD licenses is reproduced below.
-------------------------------------------------------------------------------
The "New" BSD License:
......
......@@ -14,11 +14,11 @@
"url": "https://github.com/dojo/util.git"
},
"dependencies": {
"dojo": "1.11.0-rc3",
"dijit": "1.11.0-rc3",
"dojox": "1.11.0-rc3",
"dojo-themes":"1.11.0-pre",
"dojo": "1.11.0",
"dijit": "1.11.0",
"dojox": "1.11.0",
"dojo-themes":"1.11.0-pre"
},
"devDependencies": {
},
}
}
define([], function(){
var
rev = "$Rev: 3fda435 $".match(/[0-9a-f]{7,}/),
rev = "$Rev: 32aadc8 $".match(/[0-9a-f]{7,}/),
version= {
major: 1, minor: 11, patch: 0, flag: "-rc3",
major: 1, minor: 11, patch: 0, flag: "",
revision: rev ? rev[0] : NaN,
toString: function(){
var v= version;
......
......@@ -7,13 +7,13 @@ the directories in which they reside and in the code itself. No external
contributions are allowed under licenses which are fundamentally incompatible
with the AFL or BSD licenses that Dojo is distributed under.
The text of the AFL and BSD licenses is reproduced below.
The text of the AFL and BSD licenses is reproduced below.
-------------------------------------------------------------------------------
The "New" BSD License:
**********************
Copyright (c) 2005-2015, The Dojo Foundation
Copyright (c) 2005-2016, The Dojo Foundation
All rights reserved.
Redistribution and use in source and binary forms, with or without
......
......@@ -7,13 +7,13 @@ the directories in which they reside and in the code itself. No external
contributions are allowed under licenses which are fundamentally incompatible
with the AFL or BSD licenses that Dojo is distributed under.
The text of the AFL and BSD licenses is reproduced below.
The text of the AFL and BSD licenses is reproduced below.
-------------------------------------------------------------------------------
The "New" BSD License:
**********************
Copyright (c) 2005-2015, The Dojo Foundation
Copyright (c) 2005-2016, The Dojo Foundation
All rights reserved.
Redistribution and use in source and binary forms, with or without
......
......@@ -7,13 +7,13 @@ the directories in which they reside and in the code itself. No external
contributions are allowed under licenses which are fundamentally incompatible
with the AFL or BSD licenses that Dojo is distributed under.
The text of the AFL and BSD licenses is reproduced below.
The text of the AFL and BSD licenses is reproduced below.
-------------------------------------------------------------------------------
The "New" BSD License:
**********************
Copyright (c) 2005-2015, The Dojo Foundation
Copyright (c) 2005-2016, The Dojo Foundation
All rights reserved.
Redistribution and use in source and binary forms, with or without
......
......@@ -21,7 +21,7 @@ define(["doh/runner", "require", "dojo/_base/config"], function(doh, require, co
};
console.log("\n"+doh._line);
console.log("The Dojo Unit Test Harness, $Rev: 3fda435 $");
console.log("The Dojo Unit Test Harness, $Rev: 32aadc8 $");
console.log("Copyright (c) 2011, The Dojo Foundation, All Rights Reserved");
console.log("Running with node.js");
for (var tests= [], args= config["commandLineArgs"], i= 0, arg; i<args.length; i++) {
......
......@@ -21,7 +21,7 @@ define(["doh/runner", "require", "dojo/_base/config"], function(doh, require, co
};
print("\n"+doh._line);
print("The Dojo Unit Test Harness, $Rev: 3fda435 $");
print("The Dojo Unit Test Harness, $Rev: 32aadc8 $");
print("Copyright (c) 2011, The Dojo Foundation, All Rights Reserved");
for (var tests= [], args= config["commandLineArgs"], i= 0, arg; i<args.length; i++) {
arg= (args[i]+"").split("=");
......
<!DOCTYPE html>
<html style="height:100%;">
<head>
<title>The Dojo Unit Test Harness, $Rev: 3fda435 $</title>
<title>The Dojo Unit Test Harness, $Rev: 32aadc8 $</title>
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1, maximum-scale=1"/>
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
......
{
"name": "doh",
"version": "1.11.0-rc3",
"version": "1.11.0",
"directories": {
"lib": "."
},
......
<!DOCTYPE html>
<html style="height:100%;">
<head>
<title>The Dojo Unit Test Harness, $Rev: 3fda435 $</title>
<title>The Dojo Unit Test Harness, $Rev: 32aadc8 $</title>
<script type="text/javascript" src="_parseURLargs.js"></script>
......
......@@ -7,13 +7,13 @@ the directories in which they reside and in the code itself. No external
contributions are allowed under licenses which are fundamentally incompatible
with the AFL or BSD licenses that Dojo is distributed under.
The text of the AFL and BSD licenses is reproduced below.
The text of the AFL and BSD licenses is reproduced below.
-------------------------------------------------------------------------------
The "New" BSD License:
**********************
Copyright (c) 2005-2015, The Dojo Foundation
Copyright (c) 2005-2016, The Dojo Foundation
All rights reserved.
Redistribution and use in source and binary forms, with or without
......
{
"name": "dojo-util",
"version": "1.11.0-rc3",
"version": "1.11.0",
"licenses": [
{
"type": "AFLv2.1",
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment