Re: [orion-dev] [orion-releng] orion.eclipse.org update blocked

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Now that we understand the root cause of
the editor problem, I can answer this. I'm also moving the discussion to
orion-dev because I think it's important we all understand the root cause
in this case. The problem was that the requirejs builder does static analysis
to find and connect all the modules in our scripts. It does this by finding
a very specific code pattern: invocation of a function called "define"
whose first argument is an array string literal of dependencies. However
in the editor code we want to support the case where requirejs is not available.
We used to do this as follows (I am simplifying).

orion.textview = /*
define module here */
if (window.define) {
   define(['orion/textview/textModel',
'orion/textview/keyBinding'], function() { return orion.textview; });
}

This worked, but it caused us to declare
a global variable (orion and orion.textview). This is bad practice and
our editor consumers don't want us littering their DOM with our names.
So it was changed to:

(define || function(deps, callback) { defineGlobal("orion/textview",
deps, callback); })
(['orion/textview/textModel',
'orion/textview/keyBinding'], /* define module here
*/ );

Where "defineGlobal" was a helper function that
was used for the case where requirejs was missing to hook up the dependencies.
This avoided globals and supported the cases we cared about. However, requirejs
builder did not recognize that we were invoking a function called "define"
here. The requirejs build doesn't fail when this happens - it just doesn't
notice the module and doesn't hook up the module dependencies. The resulting
code is syntactically correct but utterly fails at runtime.

Next we tried this pattern:

(function() {
        var
deps = ['orion/textview/textModel',
'orion/textview/keyBinding'];
        var
moduleParent = "orion/textview";
        var
module = /* define module here */
        if
(window.define) {
         
      define(deps, module);
        } else
{
         
      defineGlobal(moduleParent, deps, module);
        }
}());

This also avoids globals, and it's statically
clear that we are invoking a define function. However requirejs *also*
requires that the first argument be a literal array of strings, so it failed
in the same way.  Finally after several attempts we came up with a
pattern that works in all cases, avoids cluttering out code, and requirejs
recognizes as a module definition:

if (!window.define) {
        window.define
= /* helper function for non-requirejs case */
}
define(['orion/textview/textModel',
'orion/textview/keyBinding'], /* module
definition here */, "orion/textview");

If anyone else has best practices to
share on how to define modules in a way that supports requirejs and non-requirejs
usage, please chime in.

Now onto McQ's question of why we didn't
notice the bug until we deployed. The main reason of course is that our
self-hosting on orion.eclipse.org or localhost doesn't do the requirejs
compilation which introduces the error. Also, or JS unit tests are only
testing small bits of function and not ensure that our entire pages are
successfull built and working. I have entered a bug for higher level JS
tests that verify our pages are all working after the compile step: https://bugs.eclipse.org/bugs/show_bug.cgi?id=362805.
I have linked this to our plan item about build and test infrastructure
improvements. If anyone has ideas here please chime in on the bug.

John

Mike Wilson/Ottawa/IBM@IBMCA
Sent by: orion-releng-bounces@xxxxxxxxxxx

11/01/2011 12:19 PM

Please respond to
Orion build notices and discussions <orion-releng@xxxxxxxxxxx>

To	Orion build notices and discussions <orion-releng@xxxxxxxxxxx>
cc
Subject	Re: [orion-releng] orion.eclipse.org update blocked

> When our self-hosting server is broken, our first
priority has to be fixing any bugs blocking it. 
... and our second priority should be understanding how someone released
changes this obviously bad. 

What testing (that clearly was not done) should people be doing, before
deploying to the server, to prevent this from happening again?

McQ.

John
Arthorne---2011/11/01 11:08:27---It's been a rough morning for orion.eclipse.org.
I ran a build this morning that succeeded, and deployed it to orion.eclipse.or

From:	John Arthorne/Ottawa/IBM@IBMCA
To:	orion-releng@xxxxxxxxxxx
Date:	2011/11/01 11:08
Subject:	[orion-releng] orion.eclipse.org update blocked

---

It's been a rough morning for orion.eclipse.org. I ran a build this morning
that succeeded, and deployed it to orion.eclipse.org. However the server
was exiting immediately due to an equinox bug: 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=362412

I added a workaround for that problem, and the server started. However,
you can't open any editors because of this orion bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=362505

I have now reverted orion.eclipse.org to last week's build (20111028).
When our self-hosting server is broken, our first priority has to be fixing
any bugs blocking it. Mark/Silenio/Felipe, please let me know when you
are ready for a rebuild. 

John_______________________________________________
orion-releng mailing list
orion-releng@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/orion-releng

_______________________________________________
orion-releng mailing list
orion-releng@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/orion-releng