Why is Jenkins using a HtmlUnit fork?

[Tom Fennelly]

Anyone have an idea? I'm hoping there was a really good reason, otherwise I think I might cry.

[Baptiste Mathus]

Well according to commits log this is is for KK https://github.com/jenkinsci/htmlunit/commits/master

My 2 cents

Anyone have an idea? I'm hoping there was a really good reason, otherwise I think I might cry.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/25ac23b5-5fc9-42c2-a9b4-2dbd3406ac48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kanstantsin Shautsou]

KK likes forking libraries to add some hacks, ask him.

[nicolas de loof]

As long as such a hack is a way to quickly get a fix / feature while a pull request is waiting for approval I'm fine with that, but when this ends with svnkit-like maintenance hell I'm -1

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/885ae71a-39e7-4c48-a78b-44acb5c970a7%40googlegroups.com.

[Tom Fennelly]

I spent a while trying to replace the forked HtmlUnit with HtmlUnit 2.17 (PR #1774). I've parked it for now. I was just running into one issue after another.

[Mark Waite]

I'm confident Kohsuke and others don't fork unless they see it as the best way to solve the problem and deliver good value to Jenkins users.  I believe a fork is usually a response to a gap.

The SVNKit example is one that made Hudson (Jenkins) so compelling for me from the very beginning of Hudson(Jenkins).  Hudson support for Subversion worked well, whether or not the team maintaining SVNKit at that time had a full or complete solution to the problem.  I think the fork was done to benefit me as a user so that I could have a working, integrated, pure Java subversion implementation.  I wasn't required to install or configure Subversion on my Windows slave machines.  Yes, that focus on users made it harder for developers later, but I think that focus on users was part of what brought Jenkins to being installed on over 100 000 instances.

Since the attempt to port to the latest HTMLUnit was challenging, I suspect that means there were significant gaps between what was needed for Jenkins development and what HTMLUnit was providing at the time of the fork.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BbPaoJYZZDayFo6Ynh84Gsed_Jr0q5FAjHJ%2BpGO7D8GuErLRw%40mail.gmail.com.

[Kanstantsin Shautsou]

On Jul 26, 2015, at 22:50, Mark Waite <mark.ea...@gmail.com> wrote:

I'm confident Kohsuke and others don't fork unless they see it as the best way to solve the problem and deliver good value to Jenkins users.  I believe a fork is usually a response to a gap.

The SVNKit example is one that made Hudson (Jenkins) so compelling for me from the very beginning of Hudson(Jenkins).  Hudson support for Subversion worked well, whether or not the team maintaining SVNKit at that time had a full or complete solution to the problem.  I think the fork was done to benefit me as a user so that I could have a working, integrated, pure Java subversion implementation.  I wasn't required to install or configure Subversion on my Windows slave machines.  Yes, that focus on users made it harder for developers later, but I think that focus on users was part of what brought Jenkins to being installed on over 100 000 instances.

Since the attempt to port to the latest HTMLUnit was challenging, I suspect that means there were significant gaps between what was needed for Jenkins development and what HTMLUnit was providing at the time of the fork.

Mark Waite

The question is whether this changes were proposed to upstream or it was an attempt to save the time that ends with _more_ time consumption for other people.

On Sun, Jul 26, 2015 at 9:32 AM Tom Fennelly <tom.fe...@gmail.com> wrote:

I spent a while trying to replace the forked HtmlUnit with HtmlUnit 2.17 (PR #1774). I've parked it for now. I was just running into one issue after another.

On 26 July 2015 at 11:25, nicolas de loof <nicolas...@gmail.com> wrote:

As long as such a hack is a way to quickly get a fix / feature while a pull request is waiting for approval I'm fine with that, but when this ends with svnkit-like maintenance hell I'm -1

Le dim. 26 juil. 2015 12:10, Kanstantsin Shautsou <kanstan...@gmail.com> a écrit :

KK likes forking libraries to add some hacks, ask him.

On Wednesday, July 22, 2015 at 11:16:14 PM UTC+3, Tom Fennelly wrote:

Anyone have an idea? I'm hoping there was a really good reason, otherwise I think I might cry.

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/885ae71a-39e7-4c48-a78b-44acb5c970a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BbPaoJYZZDayFo6Ynh84Gsed_Jr0q5FAjHJ%2BpGO7D8GuErLRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/woLn-ubRGkY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEV2K7TJK8NvGGU9PuCLy7%3DgAGqspSS%3DEUrgs6Wz%3D_HsQ%40mail.gmail.com.

[nicolas de loof]

I fully agree on the initial intent and benefit for project dynamic to fork and release custom binaries, the issue is those changes were not proposed upstream and in some cases (winstone for sample) the fork quickly diverged.

As a result we hardly can get upstream improvements, I remember doing such an upgrade for svnkit and this was hard work to get confidence with the resulting codebase. Steven christou was able to switch back to mainstream svnkit which let us upgrade on a regular basis

[Tom Fennelly]

We are where we are guys, so there's no point in us getting worked up about it. Imo, the question now is can we fix it and get back with the HtmlUnit herd?

The only things I've seen that could be considered to be "added value" are a few helper methods on the HtmlForm and DomNode classes (utilities for submitting a form etc). I was easily able to replicate these helpers in "util" classes within the test harness i.e. no need to maintain a fork for these imo. After that, there were some bug fixes, for which we'd need to analyse on a case-by-case basis to see if they need to be proposed+pushed back upstream.

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/woLn-ubRGkY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzmrY5jLiePK0hM%2BMQTqqKv6wNT%3DSTHDjM%3DYDd_Gc37%2B%3Dw%40mail.gmail.com.

[Bruno P. Kinoshita]

Just in case someone would like to check if we can get a new release of Apache Commons Jelly to replace our forked Jelly too; I'd started a discussion a couple of months ago in the apache dev-list and am (very) slowly working on it.

http://markmail.org/thread/r2vdpgtlbka62iki

Right now in my todo list:

- Mavenize the project, continuing Nial's work (just need to sort out the taglib site generation)

- Understand what changed in Jenkins and why

- Review some old issues, including those submitted by KK https://issues.apache.org/jira/browse/JELLY-284?jql=PROJECT%3DJELLY%20AND%20CREATOR%3Dkohsuke

- Start fixing issues

- Find someone to be a release manager in commons

Cheers

Bruno

---

From: nicolas de loof <nicolas...@gmail.com>
To: Mark Waite <mark.ea...@gmail.com>
Cc: jenkin...@googlegroups.com
Sent: Monday, July 27, 2015 7:14 PM
Subject: Re: Why is Jenkins using a HtmlUnit fork?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzmrY5jLiePK0hM%2BMQTqqKv6wNT%3DSTHDjM%3DYDd_Gc37%2B%3Dw%40mail.gmail.com.

[Tom Fennelly]

HtmlUnit is getting in the way yet again. The fact that we are using a forked version is not helping at all, but I think in general HtmlUnit (even recent versions if a web search is to be believed) does not play nicely with lots of JS libraries. In my case atm, our forked version is bitching about jQuery 2.

This is a bit of a conundrum for sure. How can we start making use of more modern JS libs in Jenkins core when we have a large test suite that blocks us from using them because it has a deeeeeeeply ingrained dependency on a forked and outdated lib which has serious fundamental limitations (even if we were using a non-forked version).

So I don't want a bitch-fest on this. I'm really hoping people might have ideas on how we might resolve this and move forward?

[Tom Fennelly]

I eventually got rid of the forked version of HtmlUnit from Jenkins core in this PR. Also see governance meeting notes on same. This should result in us being able to use more modern JS libs in Jenkins + write tests against them that don't blow up in our face.

Our forked version of HtmlUnit had inlined API extensions that no longer exist. I replaced all of these with static utility methods (in DomNodeUtil, HtmlFormUtil etc). I need to document these somewhere (also need to add more Javadoc as part of the PR). Where would be best? I could put a README.md in beside this code?

[Antonio Muñiz]

I think a README.md behind the code would be ok, since this project is used mainly by developers.

On Tue, Aug 25, 2015 at 11:25 AM, Tom Fennelly <tom.fe...@gmail.com> wrote:

I eventually got rid of the forked version of HtmlUnit from Jenkins core in this PR. Also see governance meeting notes on same. This should result in us being able to use more modern JS libs in Jenkins + write tests against them that don't blow up in our face.

Our forked version of HtmlUnit had inlined API extensions that no longer exist. I replaced all of these with static utility methods (in DomNodeUtil, HtmlFormUtil etc). I need to document these somewhere (also need to add more Javadoc as part of the PR). Where would be best? I could put a README.md in beside this code?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4a0b5562-107e-4c68-a253-98ff2d830e7f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Antonio Muñiz

Software Engineer
CloudBees, Inc.

[Robert Sandell]

It would be great if someone could write up a small migration guide on the wiki for plugin devs that are upgrading their core dependency.

Something like "Where you used to do f.getButtonByCaption("Advanced...").click(); change to HtmlFormUtil.getButtonByCaption(f, "Advanced...").click();" etc.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAJc7kzQqhBv2oDwdr6qWSv59oZJHwvpt0AVHUzksg-cGhFui0A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Tom Fennelly]

Absolutely, this is the sort of documentation I'm planning to add.