If a `src` config is not provided, by default, all of the library sources are included. There is some special handling in the build task to make sure all library sources are included regardless of the path to the build config. When someone includes a `src` config, path patterns are assumed to be relative to the current working directory (unless overriden with the `cwd` config). So, when you use the `src` config, your config is no longer portable.
This allows other packages to depend on the ol3 package and get the build tools (devDependencies are not installed when they are transitive dependencies). The justification here is that the ol3 package becomes useful to other packages when you are able to run the build.js task. For this task to run all of its dependencies must be available.
Because we don't know if a new or modified file includes changes to the class hierarchy, we regenerate info for all sources any time any one has changed. An alternative would be to generate info first for the new or modified file and then (potentially) regenerate info for more source files in the class hierarchy, but this makes the generate-info.js task far more complicated.
The test.js task starts the development server and runs the tests in PhantomJS. As mentioned in the readme, when running the tests continuously during development, it is more convenient to start the dev server and visit the root of the test directory in your browser.
Later we can bring in Karma to drive PhantomJS and other browsers, but this simple "run once" task is useful for the CI job.
By default, all paths in the build config (e.g. externs) are assumed to be relative to the ol3 repo root. To make it so relative paths are resolved from a different directory, use the cwd option.
In addition, this change makes it so the `build.js` task can be run from another directory.
The closure-util package works on Node 0.8, 0.10, and 0.11 (as of this writing), but it requires an updated version of npm to install on Node 0.8. For the build to pass on Travis, we update npm before installing other dependencies. For others who are installing the openlayers package, nothing special is required for Node 0.10 and above. For users on Node 0.8, the openlayers package will only install with an updated version of npm. This can be installed with npm itself.
npm install -g npm # only needed on Node 0.8
The change in #2098 made it so a feature's geometry could be undefined. This is consistent with the return type for the getGeometry method. Where calling code needs to ensure that it has a geometry instance, it can use instanceof, goog.isDefAndNotNull(), or test for a truthy value.
A feature can have a geometry whose value is an ol.geom.Geometry instance or null. A feature can also have no geometry property. By default, a feature has no geometry property. To set a geometry, one can be passed to the constructor (including null) or passed to setGeometry().
Any of minResolution, maxResolution, minZoom, or maxZoom can be used to constrain the view resolutions. Resolution options are given precedence over zoom options.
Whitespace builds are still painful to debug. Skipping the compiler altogether and simply concatenating sources is a better option for development and debugging. By ommitting the `compile` option in a build config, the output is "uncompiled" - a straight concatenation of all sources in dependency order.
This task generates build related metadata for the library based on doc annotations. Since it is about more than writing out exportable symbols, it makes sense to have a more general name.
Previously, ol.geom.Polygon was a transitive dependency of ol.proj (since ol.proj requires ol.sphere.NORMAL, and all spheres were capable of generating circular polygons). Instead, ol.proj should be lower-level. Since it deals only with coordinate arrays, it shouldn't depend on all of the geometry code.
By adding a static `circular` function to `ol.geom.Polygon`, the dependency tree makes more sense. If you want to create a polygon that approximates a circle on a sphere, you require `ol.geom.Polygon` and `ol.Sphere` (or one of the constants).
This makes room for geometries to have a `transform` method that takes projection-like arguments (meaning that `ol.geom.Geometry` will require `ol.proj`).
This gives more consistency with ol.proj.applyTransform, allowing us to add a more convenient ol.extent.transform method that takes projection-like arguments.
Since async and htmlparser2 are used by the postinstall task, they need to be listed as dependencies. These will get installed when ol3 is a dependency of another project.
With this change, the only two remaining generated scripts are build/exports.js and build/test/requireall.js. Both are only required by Plovr. With the Node based build task, a temporary exports.js file is created. The Node based server can be used to run the tests without build/test/requireall.js.
Because ol.proj.EPSG4326 et al. extend ol.proj.Projection which has exportable methods, these constructors need to be exportable as well (e.g. so ol.proj.EPSG4326.prototype is defined in exports.js when calling goog.exportProperty on getCode etc.). If we really don't want these to be exportable, they should be removed or made private (and named like ol.proj.EPSG4326_) for internal use only.
Tim Schaub