I've solved the build issue. Actually, I managed to work around it. Ultimately, I deleted my local maven repo (~/.m2/repository/*) and reran the build. The subsequent build ran, suggesting that one or more of the existing artifacts in my local maven repo was causing the problem, or perhaps when maven built the class path, it managed to get an older copy of maven-core ahead of the required version 3.1.0 (just guessing here).
I set up a jenkins job to build git-plugin and set the option to use a private repository to prevent my other projects from introducing this problem in the future. On Wednesday, January 6, 2016 at 1:29:13 PM UTC-7, Michael Giroux wrote: > > Really appreciate the suggestions. > > To eliminate eclipse, I cloned https://github.com/jenkinsci/git-plugin.git > to a new directory and built with maven. Same issue. Wonder if this is > caused by my version of OS X (10.11.2) El Capitan. I'm going to check > the maven groups. > > On Wednesday, January 6, 2016 at 12:25:48 PM UTC-7, Vincent Latombe wrote: >> >> If you use Eclipse, make sure you do a clean build in maven. Not doing so >> will result in odd failures with all things related to annotation >> processing, such as the error message you are getting. >> >> Vincent >> >> 2016-01-06 17:22 GMT+01:00 Mark Waite <mark.ea...@gmail.com>: >> >>> I had a friend at the office compile the master branch of the git plugin >>> on his MacOS machine with maven 3.3.1 and Java 1.8.0_60. No test failures >>> for him either. I truly don't know what's different about your environment >>> that causes the tests to fail. >>> >>> Mark Waite >>> >>> On Tue, Jan 5, 2016 at 9:01 PM Mark Waite <mark.ea...@gmail.com> wrote: >>> >>>> It may be that you're seeing a slightly different variation on MacOS of >>>> what I'm seeing on FreeBSD. On FreeBSD, it appears the tests fail due to >>>> the Jenkins version on which the git plugin is based. >>>> >>>> I maintain a working branch (for compatibility testing) on >>>> https://github.com/MarkEWaite/git-plugin/tree/ongoing/latest-jenkins-lts . >>>> >>>> That branch compiles and passes all tests on FreeBSD 10.1 with OpenJDK 8. >>>> It is the same content as the git plugin master branch, plus an update to >>>> the pom.xml to depend on the latest Jenkins long term support release. I >>>> believe it also includes one other relatively minor change required in the >>>> newer Jenkins version. >>>> >>>> You might try that same branch for yourself. >>>> >>>> Mark Waite >>>> >>>> On Tue, Jan 5, 2016 at 8:22 PM Mark Waite <mark.ea...@gmail.com> wrote: >>>> >>>>> I use various versions of maven, including Maven 3.2.5, and the latest >>>>> versions of Oracle Java 7 and Oracle Java 8 on the platforms where I >>>>> compile and run. I also use OpenJDK 7 and OpenJDK 8 on at least a few of >>>>> the platforms. >>>>> >>>>> I also built and tested on FreeBSD 10.1 using OpenJDK 7. That's the >>>>> closest I can approximate to a MacOS machine. It fails with a hundred or >>>>> more test failures, but not with the message you're seeing. >>>>> >>>>> I built and tested on FreeBSD 10.1 using OpenJDK 8. It also fails >>>>> with a hundred or more test failures, but not the message you're seeing. >>>>> >>>>> I am able to run slave agents on FreeBSD, and the git plugin and git >>>>> client plugin are able to clone repositories, but I can't compile and >>>>> test >>>>> successfully on FreeBSD with either OpenJDK 7 or OpenJDK 8. >>>>> >>>>> I think the problem you're seeing is either platform specific (like my >>>>> FreeBSD problem), or environment and configuration specific. >>>>> Unfortunately, I don't have any way to do further diagnosis. >>>>> >>>>> You might check with Craig Rodrigues on this mailing list. I believe >>>>> he's a FreeBSD developer. I don't think I've ever seen a Darwin >>>>> developer >>>>> on the list. >>>>> >>>>> Mark Waite >>>>> >>>>> On Tue, Jan 5, 2016 at 7:02 PM Michael Giroux <mlgi...@gmail.com> >>>>> wrote: >>>>> >>>>>> Mac OS should not matter. Maven is Java, and Java is platform >>>>>> neutral (in theory), but maven version may be of interest. >>>>>> >>>>>> What is your specific build environment? >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, January 5, 2016 at 6:02:56 PM UTC-7, Mark Waite wrote: >>>>>> >>>>>>> That's a very strange message. The only reference I could find to >>>>>>> that message was a wiki article from 2011. See >>>>>>> https://wiki.jenkins-ci.org/display/JENKINS/My+class+is+missing+descriptor >>>>>>> in >>>>>>> case that gives you any help. >>>>>>> >>>>>>> I see that you're running on MacOS, and I don't have a MacOS machine >>>>>>> in my mix of development and test environments, so there may be >>>>>>> something >>>>>>> specific to the Mac. >>>>>>> >>>>>>> Mark Waite >>>>>>> >>>>>>> On Tue, Jan 5, 2016 at 4:29 PM Michael Giroux <mlgi...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>> Attaching build.log for complete build result. shows maven version >>>>>>>> and java versions at head of file. >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, January 5, 2016 at 4:25:25 PM UTC-7, Michael Giroux >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I'm running a build now, will attach console output when tests >>>>>>>>> complete. Here is an example of a failure: >>>>>>>>> >>>>>>>>> java.lang.AssertionError: class >>>>>>>>> hudson.plugins.git.util.DefaultBuildChooser is missing its descriptor >>>>>>>>> >>>>>>>>> at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1165) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.util.BuildChooser.getDescriptor(BuildChooser.java:142) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.util.BuildChooser.getDisplayName(BuildChooser.java:45) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:555) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:529) >>>>>>>>> >>>>>>>>> at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:384) >>>>>>>>> >>>>>>>>> at hudson.scm.SCM.poll(SCM.java:401) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1450) >>>>>>>>> >>>>>>>>> at hudson.model.AbstractProject._poll(AbstractProject.java:1421) >>>>>>>>> >>>>>>>>> at hudson.model.AbstractProject.poll(AbstractProject.java:1332) >>>>>>>>> >>>>>>>>> at hudson.plugins.git.SCMTriggerTest.check(SCMTriggerTest.java:271) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.SCMTriggerTest.testCommitAsBranchSpec_feature4_sha1(SCMTriggerTest.java:206) >>>>>>>>> >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>>> >>>>>>>>> at >>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>>>> >>>>>>>>> at >>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>>> >>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:497) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jvnet.hudson.test.JenkinsRule$2.evaluate(JenkinsRule.java:486) >>>>>>>>> >>>>>>>>> at org.junit.rules.RunRules.evaluate(RunRules.java:20) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) >>>>>>>>> >>>>>>>>> >>>>>>>>> testCommitAsBranchSpec_feature4_branchName(hudson.plugins.git.JGitSCMTriggerLocalPollTest) >>>>>>>>> >>>>>>>>> Time elapsed: 10.183 sec <<< FAILURE! >>>>>>>>> >>>>>>>>> java.lang.AssertionError: class >>>>>>>>> hudson.plugins.git.util.DefaultBuildChooser is missing its descriptor >>>>>>>>> >>>>>>>>> at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1165) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.util.BuildChooser.getDescriptor(BuildChooser.java:142) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.util.BuildChooser.getDisplayName(BuildChooser.java:45) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:555) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:529) >>>>>>>>> >>>>>>>>> at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:384) >>>>>>>>> >>>>>>>>> at hudson.scm.SCM.poll(SCM.java:401) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.model.AbstractProject.pollWithWorkspace(AbstractProject.java:1450) >>>>>>>>> >>>>>>>>> at hudson.model.AbstractProject._poll(AbstractProject.java:1421) >>>>>>>>> >>>>>>>>> at hudson.model.AbstractProject.poll(AbstractProject.java:1332) >>>>>>>>> >>>>>>>>> at hudson.plugins.git.SCMTriggerTest.check(SCMTriggerTest.java:271) >>>>>>>>> >>>>>>>>> at >>>>>>>>> hudson.plugins.git.SCMTriggerTest.testCommitAsBranchSpec_feature4_branchName(SCMTriggerTest.java:214) >>>>>>>>> >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>>> >>>>>>>>> at >>>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>>>> >>>>>>>>> at >>>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>>> >>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:497) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.jvnet.hudson.test.JenkinsRule$2.evaluate(JenkinsRule.java:486) >>>>>>>>> >>>>>>>>> at org.junit.rules.RunRules.evaluate(RunRules.java:20) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >>>>>>>>> >>>>>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) >>>>>>>>> >>>>>>>>> at >>>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) >>>>>>>>> >>>>>>>>> >>>>>>>>> Running hudson.plugins.git.JGitSCMTriggerRemotePollTest >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tuesday, January 5, 2016 at 3:55:01 PM UTC-7, Mark Waite wrote: >>>>>>>>>> >>>>>>>>>> I'm interested in the test failures you're seeing, since there >>>>>>>>>> are currently no test failures on the Cloudbees execution of the >>>>>>>>>> automated tests >>>>>>>>>> <https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/1031/> >>>>>>>>>> on >>>>>>>>>> the master branch, and there were only three random failures on my >>>>>>>>>> execution of the automated tests on CentOS 6, CentOS 7, Debian 6, >>>>>>>>>> Debian 7, >>>>>>>>>> Debian 8, Windows 7, and Windows 10, with Java 7 and Java 8. >>>>>>>>>> >>>>>>>>>> Mark Waite >>>>>>>>>> >>>>>>>>>> On Tue, Jan 5, 2016 at 3:39 PM Michael Giroux <mlgi...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Before I start making changes, I'm building from master and >>>>>>>>>>> getting test failures. Is there a document that explains >>>>>>>>>>> additional >>>>>>>>>>> environment setup needed to work on plugins? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tuesday, January 5, 2016 at 12:59:55 PM UTC-7, Mark Waite >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> That is am interesting idea. Giving a semantic meaning to am >>>>>>>>>>>> empty field should not alert behavior for non-empty fields. Will >>>>>>>>>>>> you be >>>>>>>>>>>> coding it? >>>>>>>>>>>> >>>>>>>>>>>> Mark Waite >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jan 5, 2016, 11:47 AM Michael Giroux <mlgi...@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>> Mark, >>>>>>>>>>>>> >>>>>>>>>>>>> I think there may be a simple solution that can be implemented >>>>>>>>>>>>> in the Git plugin. If the job is configured with additional >>>>>>>>>>>>> behavior >>>>>>>>>>>>> "checkout to local branch" AND the local branch name is left >>>>>>>>>>>>> blank, then >>>>>>>>>>>>> the Git plugin could do a checkout of the configured remote >>>>>>>>>>>>> branch sans >>>>>>>>>>>>> "origin/". I think this allows for current behavior while also >>>>>>>>>>>>> allowing >>>>>>>>>>>>> maven release builds to run. >>>>>>>>>>>>> >>>>>>>>>>>>> Michael >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, December 31, 2015 at 8:41:53 AM UTC-7, Mark Waite >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I think your logic is very reasonable. The git plugin seems >>>>>>>>>>>>>> like the right place to do that. Since the need is to reference >>>>>>>>>>>>>> a >>>>>>>>>>>>>> substring of the current GIT_BRANCH value within the context of >>>>>>>>>>>>>> a Jenkins >>>>>>>>>>>>>> job, it seems like an addition to the token macro keywords >>>>>>>>>>>>>> allowed on >>>>>>>>>>>>>> GIT_BRANCH might meet your need. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You might refer to >>>>>>>>>>>>>> https://issues.jenkins-ci.org/browse/JENKINS-25465 for a >>>>>>>>>>>>>> discussion of the fullName=false parameter to GIT_BRANCH, in >>>>>>>>>>>>>> case that will >>>>>>>>>>>>>> already handle your case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mark Waite >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Dec 31, 2015 at 6:07 AM Michael Giroux < >>>>>>>>>>>>>> mlgi...@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>> Accepting that the Git Parameter plugin is technically >>>>>>>>>>>>>>> correct, lets get back to the maven release build issue. >>>>>>>>>>>>>>> 1. to do a maven release, we MUST configure the "checkout to >>>>>>>>>>>>>>> local branch" option, or define a pre build step to do a git >>>>>>>>>>>>>>> checkout into >>>>>>>>>>>>>>> a local branch. >>>>>>>>>>>>>>> 2. the local branch name MUST be the effective name on the >>>>>>>>>>>>>>> remote (sans origin/) to allow the maven release:prepare to >>>>>>>>>>>>>>> push the pom >>>>>>>>>>>>>>> changes to the correct branch. >>>>>>>>>>>>>>> 3. we currently can not use the value from the Git Parameter >>>>>>>>>>>>>>> plugin because that includes the "origin/" prefix resulting in >>>>>>>>>>>>>>> a new branch >>>>>>>>>>>>>>> created on the remote git repo. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm not really sure where the option belongs, but to support >>>>>>>>>>>>>>> doing a maven release on a branch specified by the Git >>>>>>>>>>>>>>> Parameter plugin we >>>>>>>>>>>>>>> need a clean way to get the code checked out into the correct >>>>>>>>>>>>>>> local branch. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The Git plugin could provide an option to derive local >>>>>>>>>>>>>>> branch name, or the Git Parameter plugin could define an >>>>>>>>>>>>>>> additional >>>>>>>>>>>>>>> parameter containing the effective branch name. I'm not sure >>>>>>>>>>>>>>> which is best >>>>>>>>>>>>>>> approach. I suspect that the Git plugin should be able to >>>>>>>>>>>>>>> operate whether >>>>>>>>>>>>>>> the Git Parameter plugin has been configured or not, so I lean >>>>>>>>>>>>>>> toward an >>>>>>>>>>>>>>> option in Git plugin to "checkout to local branch" that ends up >>>>>>>>>>>>>>> with the >>>>>>>>>>>>>>> required local branch name, but there may be a more appropriate >>>>>>>>>>>>>>> approach. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What is the next step? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wednesday, December 30, 2015 at 3:12:49 PM UTC-7, Mark >>>>>>>>>>>>>>> Waite wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could do that as well, though the git parameter plugin is >>>>>>>>>>>>>>>> technically correct. It is showing the branch to be built, >>>>>>>>>>>>>>>> and the branch >>>>>>>>>>>>>>>> to be built truly is "origin/master", since there is no local >>>>>>>>>>>>>>>> master branch >>>>>>>>>>>>>>>> tracking the remote branch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Mark Waite >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Dec 30, 2015 at 11:41 AM Michael Giroux < >>>>>>>>>>>>>>>> mlgi...@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Mark, I wonder if one of the issues I have is actually a >>>>>>>>>>>>>>>>> defect in the Git Parameter plugin. Specifically, the values >>>>>>>>>>>>>>>>> set by the >>>>>>>>>>>>>>>>> Git Parameter plugin include the "origin/" prefix. When this >>>>>>>>>>>>>>>>> is used as >>>>>>>>>>>>>>>>> the value for checkout to local branch, AND the build is a >>>>>>>>>>>>>>>>> maven release, >>>>>>>>>>>>>>>>> we end up with a new branch in Stash "origin/master" (should >>>>>>>>>>>>>>>>> be simply >>>>>>>>>>>>>>>>> master) or "origin/some_other_branch". It seems that normal >>>>>>>>>>>>>>>>> builds run >>>>>>>>>>>>>>>>> just fine, but release builds result in pushes back to Git >>>>>>>>>>>>>>>>> and here is >>>>>>>>>>>>>>>>> where the branch names get messed up. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Should I be asking the Git Parameter plugin developers to >>>>>>>>>>>>>>>>> strip the leading "origin/" from the branch names that are >>>>>>>>>>>>>>>>> assigned to the >>>>>>>>>>>>>>>>> parameter? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Wednesday, December 30, 2015 at 11:22:33 AM UTC-7, >>>>>>>>>>>>>>>>> Michael Giroux wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks Mark. Command line build runs fine w/o compile >>>>>>>>>>>>>>>>>> errors. For your reference, this is a known Eclipse issue >>>>>>>>>>>>>>>>>> bug >>>>>>>>>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=369592. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wednesday, December 30, 2015 at 10:34:59 AM UTC-7, >>>>>>>>>>>>>>>>>> Mark Waite wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://jenkins.ci.cloudbees.com/job/plugins/job/git-plugin/ >>>>>>>>>>>>>>>>>>> (and >>>>>>>>>>>>>>>>>>> my internal Jenkins server inside my firewall) confirm that >>>>>>>>>>>>>>>>>>> the code on the >>>>>>>>>>>>>>>>>>> master branch compiles correctly from the maven command >>>>>>>>>>>>>>>>>>> line. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I run my debugger from Netbeans (rather than Eclipse) >>>>>>>>>>>>>>>>>>> and can confirm that it compiles and runs from Netbeans as >>>>>>>>>>>>>>>>>>> well. I don't >>>>>>>>>>>>>>>>>>> use Eclipse, so I'm not much help wiht Eclipse specific >>>>>>>>>>>>>>>>>>> failures. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Mark Waite >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Dec 30, 2015 at 8:31 AM Michael Giroux < >>>>>>>>>>>>>>>>>>> mlgi...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> BTW, the following patch resolves my compile errors, >>>>>>>>>>>>>>>>>>>> but not sure if the cast to (Item) is the best choice. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> diff --git >>>>>>>>>>>>>>>>>>>> a/src/test/java/hudson/plugins/git/GitSCMTest.java >>>>>>>>>>>>>>>>>>>> b/src/test/java/hudson/plugins/git/GitSCMTest.java >>>>>>>>>>>>>>>>>>>> index 3a14b10..a39e60c 100644 >>>>>>>>>>>>>>>>>>>> --- a/src/test/java/hudson/plugins/git/GitSCMTest.java >>>>>>>>>>>>>>>>>>>> +++ b/src/test/java/hudson/plugins/git/GitSCMTest.java >>>>>>>>>>>>>>>>>>>> @@ -1203,7 +1203,7 @@ >>>>>>>>>>>>>>>>>>>> false, >>>>>>>>>>>>>>>>>>>> Collections.<SubmoduleConfig>emptyList(), >>>>>>>>>>>>>>>>>>>> browser, null, null); >>>>>>>>>>>>>>>>>>>> p.setScm(scm); >>>>>>>>>>>>>>>>>>>> - configRoundtrip(p); >>>>>>>>>>>>>>>>>>>> + configRoundtrip((Item)p); >>>>>>>>>>>>>>>>>>>> assertEqualDataBoundBeans(scm,p.getScm()); >>>>>>>>>>>>>>>>>>>> assertEquals("Wrong key", "git " + url, >>>>>>>>>>>>>>>>>>>> scm.getKey()); >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> @@ -1215,7 +1215,7 @@ >>>>>>>>>>>>>>>>>>>> FreeStyleProject p = createFreeStyleProject(); >>>>>>>>>>>>>>>>>>>> GitSCM scm = new GitSCM(" >>>>>>>>>>>>>>>>>>>> https://github.com/jenkinsci/jenkins";); >>>>>>>>>>>>>>>>>>>> p.setScm(scm); >>>>>>>>>>>>>>>>>>>> - configRoundtrip(p); >>>>>>>>>>>>>>>>>>>> + configRoundtrip((Item)p); >>>>>>>>>>>>>>>>>>>> assertEqualDataBoundBeans(scm,p.getScm()); >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Wednesday, December 30, 2015 at 10:29:37 AM UTC-7, >>>>>>>>>>>>>>>>>>>> Michael Giroux wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Not making any changes to code, just trying to examine >>>>>>>>>>>>>>>>>>>>> primary project source to understand what is being >>>>>>>>>>>>>>>>>>>>> changed in the PRs. >>>>>>>>>>>>>>>>>>>>> I cloned the primary git repo from >>>>>>>>>>>>>>>>>>>>> https://github.com/jenkinsci/git-plugin.git so I >>>>>>>>>>>>>>>>>>>>> could get some context for the PRs which show only the >>>>>>>>>>>>>>>>>>>>> code being changed. >>>>>>>>>>>>>>>>>>>>> Getting compile errors on unmodified project. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Eclipse version 4.5 (Mars), JDK 1.8.0 (also tried JDK >>>>>>>>>>>>>>>>>>>>> 1.7.0) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Wednesday, December 30, 2015 at 9:53:36 AM UTC-7, >>>>>>>>>>>>>>>>>>>>> Mark Waite wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Don't attempt to evaluate the two pull requests in >>>>>>>>>>>>>>>>>>>>>> the same repository. They are two different ideas that >>>>>>>>>>>>>>>>>>>>>> might meet your >>>>>>>>>>>>>>>>>>>>>> need. I suspect that one or the other will eventually >>>>>>>>>>>>>>>>>>>>>> be merged, but not >>>>>>>>>>>>>>>>>>>>>> both. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Mark Waite >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 30, 2015 at 7:21 AM Michael Giroux < >>>>>>>>>>>>>>>>>>>>>> mlgi...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> <blockquote class="gmail_quote" style="margin:0 0 0 >>>>>>>>>>>>>>>>>>>>>> .8ex;border-left:1p >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/f4323d13-2dd0-4900-9a90-23878e1cc1dc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
