Missing requires about ol-cesium HOT 14 CLOSED

Right now we don't compile in the code anything what would provide these requires - as all ol. methods are available only via ol3 externs.
If the requires are directly added to the js files the existing compilation with externs will stop to run, unless the build process is adjusted appropriatelly.

So this bug report is mostly about adjusting of the build process to support more build approaches:

1. ol3cesium.js independent of ol3 (WE HAVE IT NOW)
2. ol3cesium.js compiled together with ol3
3. ol3cesium.js compiled together with ol3 and the application

Related discussion is under #45. For the initial contract was from beginning agreed 1) with possibility to add 2) and 3) later on.

One namespace can't be both in ol.provide() and in externs.

from ol-cesium.

Related discussion is under #45. For the initial contract was from beginning agreed 1) with possibility to add 2) and 3) later on.

We also said that we'd want approach 3 to be supported from the start of the project. This was to cover the way Camptocamp is going to use ol3cesium.

For 2 and 3 we need the ol3cesium files to include goog.require's to ol3. And to still be able to support 1 we can use closure-util's ignoreRequires option. See https://github.com/openlayers/closure-util/.

from ol-cesium.

I fully agree and I preffer to have all three build options available for ol3cesium projects.
To resolve this issue the build process must be adjusted first.

from ol-cesium.

Agree. Although I don't find option 1 very relevant. Also, supporting the three approaches requires a more sophisticated build infrastructure. We indeed need to know/be confident that the code works with the three approaches. We do not have that infrastructure today.

from ol-cesium.

I think options 1 and 3 are the most relevant ones. I could live without 2 😄.

from ol-cesium.

@elemoine agreed to fix this by closure-util into build process and by adding the goog.require which will be ignored by regex for "ol." for the build with externs - to be done now via #84.

In future a proper build infrastructure should be done #83 - but not now.

from ol-cesium.

Using closure-util's ignoreRequires option is the first step, but, unfortunately, it is not sufficient. We also need to prevent the compiler from crying when it encounters a goog.require for which it cannot find a corresponding goog.provide. The compiler does provide an option to disable that check, but that option is not available on the commandline. The only way to set that option is to build the compiler ourselves. See https://groups.google.com/d/msg/closure-compiler-discuss/_YDYYRyvbnI/TGhv6Lo43tkJ. So what do we do? Do option 2 rather than option 1? :-)

from ol-cesium.

So question is: do you think we should build our own version of the compiler?

from ol-cesium.

Is there an added value for method 1 other method 2?
What are the use cases covered by method 1 which would be impossible using method 2?

from ol-cesium.

Advantage of (1) is the testing of the quality of publicly exported API of OL3 while developing OL3Cesium and especially better separation of the code base of OL3 and OL3Cesium. If OL3Cesium starts to use unexported methods in OL3 it would tend to be broken more often in future. Always when OL3 internals are updated so must be OL3Cesium.

Method (1) is stricter for OL3Cesium developers. It is technically easy to switch from (1) to (2) - but there is no way back, once we avoid method (1) for the main development.

Only possible workaround now would be probably to have the goog.require(ol.xxxx) in separate files - and pass them to the compiler only for (2) and (3) but not for (1).

from ol-cesium.

Advantage of (1) is the testing of the quality of publicly exported API of OL3 while developing OL3Cesium and especially better separation of the code base of OL3 and OL3Cesium. If OL3Cesium starts to use unexported methods in OL3 it would tend to be broken more often in future. Always when OL3 internals are updated so must be OL3Cesium.

But the compiler would help us a lot. It would immediately warn us when we incorrectly use ol3.

Method (1) is stricter for OL3Cesium developers.

Method (1) does not make sense to me. ol3 uses the Closure compiler. We want to use the Closure compiler for ol3-cesium. Yet we don't compile ol3 and ol3-cesium together. To support that we have to generate externs for ol, which has already caused us some trouble. And now we're facing this goog.require related problem. It's like fighting against the compiler and not using it for what it was created in the first place.

In my opinion ol.js is for people not compiling their code. People who are brave enough to compile their code should just compile it together with ol3. There is no room in the middle :-)

from ol-cesium.

Advantage of (1) is the testing of the quality of publicly exported API of OL3 while developing OL3Cesium

This really should be an excercice left to projects that don't use the compiler. You get the point :-)

from ol-cesium.

Only possible workaround now would be probably to have the goog.require(ol.xxxx) in separate files - and pass them to the compiler only for (2) and (3) but not for (1).

I think I tried something like this in the past, but I failed, because the goog.require's had to be in the same file as the namespace it defines for the compiler (or closurebuilder.py tool) to do its job. Do you have an actual example I could look at? (I have to say that I'm not convinced that's a good solution for the long term, but I'd agree to give it a try.)

from ol-cesium.

I only answered @gberaudo question - and I am not trying to convince anybody for (1) ;-)
In fact (2) and (3) are more natural for the compiler, easier to code and required for larger applications. The best would be to have them all. If you have time, just go for a proper implementation for (2) and (3) and the build system adjustments #83.

Example of the goog.require hack is visible in:
https://github.com/klokantech/iiifviewer

from ol-cesium.