Thanks for reporting the problem. Can you provide more details on your system configuration? A support bundle would be ideal, since it provides lots of information in a single package that is easy to collect and easy to upload?

My reading of that exception in the JDK 7 javadoc shows

Thrown when an application tries to call an abstract method. Normally, this error is caught by the compiler; this error can only occur at run time if the definition of some class has incompatibly changed since the currently executing method was last compiled

I'm especially perplexed why I didn't see the problem in my testing before release, since I tested with JDK 8 + Jenkins 1.651.3 + Debian and I tested with JDK 7 + Jenkins 1.609.3 + Debian.

After installing the new version of the git plugin, did you restart your Jenkins instance?

There is a change/addition from wadahiro in AbstractGitSCMSource to add many more git options to the multi-branch plugin and the literate plugin (and anything else that uses the SCMSource interface). That change, and its successors 1, 2, 3, and the merge 4 (add tests, refine the code, etc.) worked well in my tests.

Are any of your pipeline plugins out of date?

Any other areas which you think might have relevant differences?

I always restart after instaling/uninstalling plugins.
I have all plugins updated to the latest available.

support_2016-07-04_17.46.31.zip
This is with 2.5.0, do you get better information if I install 2.5.1, let it fail and then gather the bundle?

Thanks for the support bundle. The information you've provided is great. No need to show the failure (at least not yet). I need to see if I can duplicate the failure.

Is the failing job type a "Freestyle multi-branch project", a "Maven multi-branch project", a "Multi-configuration multi-branch project", a "Multibranch Pipeline", or something completely different?

If you're willing, can you upload the config.xml file (job definition file) from the job which is failing? You may need to obscure substitute sensitive information (like hostnames) before you upload.

It's a multibranch pipeline. A regular pipeline works, but there I get to configure the git repository URL myself. The config.xml is below, it's at default values except for the repository, as I deleted the old job.

<?xml version='1.0' encoding='UTF-8'?>
<org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject plugin="workflow-multibranch@2.8">
  <actions/>
  <description></description>
  <properties/>
  <views>
    <hudson.model.AllView>
      <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../../.."/>
      <name>All</name>
      <filterExecutors>false</filterExecutors>
      <filterQueue>false</filterQueue>
      <properties class="hudson.model.View$PropertyList"/>
    </hudson.model.AllView>
  </views>
  <viewsTabBar class="hudson.views.DefaultViewsTabBar"/>
  <healthMetrics>
    <com.cloudbees.hudson.plugins.folder.health.WorstChildHealthMetric plugin="cloudbees-folder@5.12"/>
  </healthMetrics>
  <icon class="org.jenkinsci.plugins.orgfolder.github.GitHubRepoIcon" plugin="github-organization-folder@1.3"/>
  <orphanedItemStrategy class="com.cloudbees.hudson.plugins.folder.computed.DefaultOrphanedItemStrategy" plugin="cloudbees-folder@5.12">
    <pruneDeadBranches>true</pruneDeadBranches>
    <daysToKeep>45</daysToKeep>
    <numToKeep>100</numToKeep>
  </orphanedItemStrategy>
  <triggers>
    <com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger plugin="cloudbees-folder@5.12">
      <spec>H * * * *</spec>
      <interval>3600000</interval>
    </com.cloudbees.hudson.plugins.folder.computed.PeriodicFolderTrigger>
  </triggers>
  <sources class="jenkins.branch.MultiBranchProject$BranchSourceList" plugin="branch-api@1.10">
    <data>
      <jenkins.branch.BranchSource>
        <source class="org.jenkinsci.plugins.github_branch_source.GitHubSCMSource" plugin="github-branch-source@1.7">
          <id>cfc000cc-b0fd-4329-844e-cf215d846fbe</id>
          <checkoutCredentialsId>SAME</checkoutCredentialsId>
          <scanCredentialsId>...</scanCredentialsId>
          <repoOwner>vladdu</repoOwner>
          <repository>erlide_eclipse</repository>
          <includes>*</includes>
          <excludes></excludes>
        </source>
        <strategy class="jenkins.branch.DefaultBranchPropertyStrategy">
          <properties class="empty-list"/>
        </strategy>
      </jenkins.branch.BranchSource>
    </data>
    <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../.."/>
  </sources>
  <factory class="org.jenkinsci.plugins.workflow.multibranch.WorkflowBranchProjectFactory">
    <owner class="org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject" reference="../.."/>
  </factory>
</org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject>

I see from comparing your job definition and my initial test job definition that you're using the github plugin to provide source control, rather than the git plugin. Is that intentional?

Is there a particular benefit you gain from using the github plugin for source control rather than the git plugin?

When I switch to use github to provide source control rather than git, I can see the same error. Thanks very much for your patience reporting it. Unfortunately, I don't know how to resolve it. I'll need to spend more time researching the interaction between the git plugin, the github plugin, and the multi-branch pipeline job type.

Jul 04, 2016 12:45:12 PM hudson.model.Executor finish1
SEVERE: Executor threw an exception
java.lang.AbstractMethodError: jenkins.plugins.git.AbstractGitSCMSource.getExtensions()Ljava/util/List;
        at jenkins.plugins.git.AbstractGitSCMSource.build(AbstractGitSCMSource.java:305)
        at jenkins.scm.api.SCMSource.build(SCMSource.java:283)
        at jenkins.branch.MultiBranchProject.newBranch(MultiBranchProject.java:267)
        at jenkins.branch.MultiBranchProject.access$000(MultiBranchProject.java:82)
        at jenkins.branch.MultiBranchProject$1.observe(MultiBranchProject.java:297)
        at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.doRetrieve(GitHubSCMSource.java:285)
        at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.retrieve(GitHubSCMSource.java:256)
        at jenkins.scm.api.SCMSource.fetch(SCMSource.java:146)
        at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:294)
        at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:157)
        at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:122)
        at hudson.model.ResourceController.execute(ResourceController.java:98)
        at hudson.model.Executor.run(Executor.java:410)

I see the issue.

GitHubSCMSource implements AbstractGitSCMSource, but does not implement getExtensions(), List<GitSCMExtension> getExtensions(). This method has been implemented in https://github.com/jenkinsci/git-plugin/pull/350 in a backward-incompatible way. It was released as git-2.5.1

Working on the fix

markewaite Are you fine if I take it?

Yes, absolutely. My apologies that I didn't realize PR350 was backwards incompatible. I missed testing the case with github as source control, and would likely have missed it writing that to the log file.

I assume that means that AbstractGitSCMSource is the definition of the API as used by any other plugin which provides an implementation of AbstractGitSCMSource. My apologies that I didn't consider that case!

oleg_nenashev I'm willing to revert the entire change from PR350 and release a new git plugin 2.5.2 rather than break compatibility for downstream consumers of the AbstractGitSCMSource interface.

markewaite I'm working on a more graceful PR, but it's up to you

In my PR there won't be compatibility breakage. To be submitted in 20 minutes

markewaite Thanks for updating the details about github/git source. I believe it's now rolling.

https://github.com/jenkinsci/git-plugin/pull/420

markewaite So the PR is under review

oleg_nenashev yes, I've been running tests on the change for the last few hours using my Docker instance and multiple slaves. I specifically checked this problem is fixed and have been doing additional exploratory testing. I intend to release git plugin 2.5.2 before end of the day today so that it will be visible in the update center before U.S. users return from their independence day holiday tomorrow.

Fix in git plugin 2.5.2 released 4 Jul 2016.

Excellent, thank you very much!

\o/ great job. Congratulations.