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 <[email protected]>: > 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>>>> 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 <[email protected]> >>>>>>>>>> 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 < >>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Mark, I'm taking a look at the two pull requests. I >>>>>>>>>>>>>>>>>>>>> cloned the repo so I can view code in Eclipse, but I'm >>>>>>>>>>>>>>>>>>>>> getting compile >>>>>>>>>>>>>>>>>>>>> errors in GitSCMTest.java: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Description Resource Path Location Type >>>>>>>>>>>>>>>>>>>>> The method configRoundtrip(FreeStyleProject) is >>>>>>>>>>>>>>>>>>>>> ambiguous for the type GitSCMTest GitSCMTest.java >>>>>>>>>>>>>>>>>>>>> /git/src/test/java/hudson/plugins/git line 1206 Java >>>>>>>>>>>>>>>>>>>>> Problem >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Suggestions? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Michael >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Tuesday, December 29, 2015 at 10:47:14 PM UTC-7, >>>>>>>>>>>>>>>>>>>>> Mark Waite wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> There is a pending pull request to the git plugin >>>>>>>>>>>>>>>>>>>>>> which provides a new environment variable, >>>>>>>>>>>>>>>>>>>>>> GIT_SHORT_BRANCH_NAME. The >>>>>>>>>>>>>>>>>>>>>> semantics of that proposed environment variable are not >>>>>>>>>>>>>>>>>>>>>> quite what you're >>>>>>>>>>>>>>>>>>>>>> describing, but you might review the pull request to see >>>>>>>>>>>>>>>>>>>>>> if it is close >>>>>>>>>>>>>>>>>>>>>> enough for your use case. See >>>>>>>>>>>>>>>>>>>>>> https://github.com/jenkinsci/git-plugin/pull/347 and >>>>>>>>>>>>>>>>>>>>>> https://github.com/jenkinsci/git-plugin/pull/304 for >>>>>>>>>>>>>>>>>>>>>> two different possibilities. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Mark Waite >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Tue, Dec 29, 2015 at 8:36 PM Michael Giroux < >>>>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The issue I'm describing is a result of using the >>>>>>>>>>>>>>>>>>>>>>> Git Parameter plugin which allows the user to select a >>>>>>>>>>>>>>>>>>>>>>> branch, + the Git >>>>>>>>>>>>>>>>>>>>>>> plugin which allows configuration of the branch to >>>>>>>>>>>>>>>>>>>>>>> build and the local >>>>>>>>>>>>>>>>>>>>>>> branch name, + maven release plugin which relies on >>>>>>>>>>>>>>>>>>>>>>> local branch name for >>>>>>>>>>>>>>>>>>>>>>> push to remote + Stash Webhook to Jenkins with triggers >>>>>>>>>>>>>>>>>>>>>>> a build of any >>>>>>>>>>>>>>>>>>>>>>> arbitrary branch. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I will admit that one solution is to create two jobs >>>>>>>>>>>>>>>>>>>>>>> in Jenkins to allow building of any arbitrary branch as >>>>>>>>>>>>>>>>>>>>>>> triggered by the >>>>>>>>>>>>>>>>>>>>>>> Stash web hook for jenkins, and a second job that is >>>>>>>>>>>>>>>>>>>>>>> configured to build a >>>>>>>>>>>>>>>>>>>>>>> branch specified by user supplied parameter values. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> The problem occurs when when attempting to configure >>>>>>>>>>>>>>>>>>>>>>> a single jenkins build that allows for manual >>>>>>>>>>>>>>>>>>>>>>> specification of branch via >>>>>>>>>>>>>>>>>>>>>>> the Git parameter, and builds kicked off by the Stash >>>>>>>>>>>>>>>>>>>>>>> web hook to jenkins. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 1. to allow the jenkins web hook to initiate a >>>>>>>>>>>>>>>>>>>>>>> build, it is necessary to configure the build to build >>>>>>>>>>>>>>>>>>>>>>> any branch (leaving >>>>>>>>>>>>>>>>>>>>>>> branch to build as blank). >>>>>>>>>>>>>>>>>>>>>>> 2. to allow a maven release to build, you MUST >>>>>>>>>>>>>>>>>>>>>>> specify a local branch name. Otherwise, the push to >>>>>>>>>>>>>>>>>>>>>>> stash fails the build >>>>>>>>>>>>>>>>>>>>>>> does not have a local branch name. >>>>>>>>>>>>>>>>>>>>>>> 3. To meet condittion #1, the default value for the >>>>>>>>>>>>>>>>>>>>>>> Git parameter must be "**" so that the branch to build >>>>>>>>>>>>>>>>>>>>>>> is ANY (** or empty) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> So basically, the issue is that if a build is >>>>>>>>>>>>>>>>>>>>>>> configured to build any branch, and also has maven >>>>>>>>>>>>>>>>>>>>>>> release configured, you >>>>>>>>>>>>>>>>>>>>>>> need some way to get the code checked out to a local >>>>>>>>>>>>>>>>>>>>>>> branch (additional >>>>>>>>>>>>>>>>>>>>>>> behaviors) with the same name as the branch being >>>>>>>>>>>>>>>>>>>>>>> built, and there is >>>>>>>>>>>>>>>>>>>>>>> currently no way to do that. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I tried to put "${GIT_BRANCH/*\//}" into the >>>>>>>>>>>>>>>>>>>>>>> "checkout to local branch" but this did not work. It >>>>>>>>>>>>>>>>>>>>>>> seems this field does >>>>>>>>>>>>>>>>>>>>>>> not resolve environment variable references using full >>>>>>>>>>>>>>>>>>>>>>> bash variable >>>>>>>>>>>>>>>>>>>>>>> reference notation. Perhaps this is the solution. >>>>>>>>>>>>>>>>>>>>>>> Extend the "checkout to >>>>>>>>>>>>>>>>>>>>>>> local branch" to provide full bash resolution of the >>>>>>>>>>>>>>>>>>>>>>> variable name. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Tuesday, December 29, 2015 at 10:03:25 AM UTC-7, >>>>>>>>>>>>>>>>>>>>>>> Michael Giroux wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Using Jenkins 1.609.3, Git plugin 2.4.0. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> We have configured most of our jobs to allow jobs >>>>>>>>>>>>>>>>>>>>>>>> to be initiated by the Stash Webhook to Jenkins. To >>>>>>>>>>>>>>>>>>>>>>>> allow developers to >>>>>>>>>>>>>>>>>>>>>>>> manually initiate a build of any branch, the jobs use >>>>>>>>>>>>>>>>>>>>>>>> the Git Parameter to >>>>>>>>>>>>>>>>>>>>>>>> set a BRANCH variable. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Using this configuration, the Git Parameter is >>>>>>>>>>>>>>>>>>>>>>>> configured to set "**" as the default branch to build. >>>>>>>>>>>>>>>>>>>>>>>> This allows the >>>>>>>>>>>>>>>>>>>>>>>> Stash Webhook to initiate a build of any branch. In >>>>>>>>>>>>>>>>>>>>>>>> order to allow the job >>>>>>>>>>>>>>>>>>>>>>>> to perform a maven release, we have configured the Git >>>>>>>>>>>>>>>>>>>>>>>> SCM to checkout to >>>>>>>>>>>>>>>>>>>>>>>> local branch "master". This all works well as long as >>>>>>>>>>>>>>>>>>>>>>>> we are not doing a >>>>>>>>>>>>>>>>>>>>>>>> maven release, or when we do a maven release on the >>>>>>>>>>>>>>>>>>>>>>>> master branch. The >>>>>>>>>>>>>>>>>>>>>>>> strategy breaks down if the developer attempts a maven >>>>>>>>>>>>>>>>>>>>>>>> release on another >>>>>>>>>>>>>>>>>>>>>>>> branch when the maven release:prepare goal tries to >>>>>>>>>>>>>>>>>>>>>>>> push pom updates. Note >>>>>>>>>>>>>>>>>>>>>>>> that the maven release plugin uses the current local >>>>>>>>>>>>>>>>>>>>>>>> branch in the push as >>>>>>>>>>>>>>>>>>>>>>>> "git push url localBranch:localBranch" As a result, >>>>>>>>>>>>>>>>>>>>>>>> when the build is for >>>>>>>>>>>>>>>>>>>>>>>> "some_branch" which has been checked out to local >>>>>>>>>>>>>>>>>>>>>>>> branch "master" we get an >>>>>>>>>>>>>>>>>>>>>>>> error on "git push ... master:master" because the >>>>>>>>>>>>>>>>>>>>>>>> remote "master" is not in >>>>>>>>>>>>>>>>>>>>>>>> sync with the local. No surprises here since the >>>>>>>>>>>>>>>>>>>>>>>> local "master" is >>>>>>>>>>>>>>>>>>>>>>>> actually "some_branch". >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To resolve this, we have deleted the "checkout to >>>>>>>>>>>>>>>>>>>>>>>> local branch" additional action, and added a pre-build >>>>>>>>>>>>>>>>>>>>>>>> step that does the >>>>>>>>>>>>>>>>>>>>>>>> following:' >>>>>>>>>>>>>>>>>>>>>>>> # checkout to a local branch using the remote >>>>>>>>>>>>>>>>>>>>>>>> branch name >>>>>>>>>>>>>>>>>>>>>>>> LOCAL_GIT_BRANCH=${GI >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>> 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 [email protected]. >>>>> >>>>> >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/jenkinsci-users/b1636c11-3a56-41ed-ba5d-547dae02292a%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/b1636c11-3a56-41ed-ba5d-547dae02292a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-users/78815edf-b1a7-478a-bda1-6b722400fb55%40googlegroups.com >>>> <https://groups.google.com/d/msgid/jenkinsci-users/78815edf-b1a7-478a-bda1-6b722400fb55%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHckAhsUXVuM9-kYb4xV%2BTJu9-vgEDvZ%2BydwkGSVfCjDg%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtHckAhsUXVuM9-kYb4xV%2BTJu9-vgEDvZ%2BydwkGSVfCjDg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAH-zGCh7XnVdh2iZBTxyTUna4So%2BSq4e_OpNw9hr41wUx0QW7g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
