UI changes branch progress report Day 2+3

[Kohsuke Kawaguchi]

I should have sent this out Friday, but here it goes.

At the end of day 1, I saw that "mvn test" in the test module was having a lot of failures left & right --- JavaScript inside HtmlUnit is reporting errors that we don't see in the actual browsers. I talked to Tom about this, and my understanding is that he's trying to upgrade HtmlUnit to a later version (we run a very old 2.6 while 2.17 is the latest) before spending any time looking into why tests are failing.

Tom did the initial attempt of upgrading to plain unmodified HtmlUnit 2.17, which didn't work. So I spent much of Day 2 starting from there and then backporting some patchsets we maintain for HtmlUnit 2.6. But I still failed to make this work, and eventually I abandoned this so that I can make some progress in other areas. The result of the backporting is here. 

So the bottom line, Day 2, the Universe won and I lost.

In Day 3, I gave up on the tests and got back to fixing form submissions by manually trying it out. I went through the remaining 14 Jelly form tags and fixed form submissions for all of them. I've also spent some time looking at jenkins-js-builder that the core now depends on, how JavaScript CommonJS modules are put together now, and how inter-plugin dependencies between JS modules are supposed to be written and work. Tom has an AI to write up about this as this is going to rebump how we do frontend development.

I'll let Gus report his progress on his own, but AIU he was fixing UI glitches and misbehaviours one by one. There were still some issues (such as controls overlapping each other, things were not hidden when they should have, etc.) While this work isn't complete, Gus told me that he felt good that the plumbing is all in place to let him make a progress; he doesn't feel like he's blocked by others.

What's next?

• I'm going to look at the effect of this change to plugins. I came up with an idea to reduce the impact of the plugins compatibility problem (JENKINS-29659), so I'm going to see if this idea works.
  
  
• Daniel Beck is going to schedule out-of-cycle Jenkins Office Hours so that we can go through this proposed change. It has at least two angles: the UX changes that impact users, and the internal changes that impact plugin developers.
  
  
• IIUC, Tom is working on getting the tests working and he has reported some progress.
  
  

Exciting progress!

--

Kohsuke Kawaguchi

[Tom Fennelly]

I think the test failures are now down to the config-ui changes (i.e. not relating to the JS modularization).

[Tom Fennelly]

I updated the config-ui-changes branch to now have the frontend-maven-plugin use an io.js executable instead of node.js for running gulp (for bundling JavaScript modules etc). This is really just in interim thing until node.js and io.js reunite/merge (whatever that will mean in reality).

The reason we are moving to io.js is to allow us use a newer version of a package called jsdom, which is really useful for testing JS code. The reason we want to use a newer version of that is because the newer versions do not require a package called contextify, which is a total pain for windows users.

Moving the frontend-maven-plugin to use io.js was not as straightforward as one might expect. It required hacking the root pom so that it would handle the download and install of io.js and npm for the frontend-maven-plugin (Vs it doing it itself, which it couldn't do for io.js). Not pretty, but it allows us move forward and it's only an interim thing.

I added pom sections to handle windows and linux but haven't tested them. I think they should work, but would be great if someone could try windows and linux. I know Gus is on vacation this week, so that rules him out.

Regards,

T.