2013/2/14 Sandell, Robert <[email protected]> > Some questions/concerns around this since we are thinking of using JGit > for some features in the Gerrit Trigger plugin:**** > > ** ** > > I guess the risk for lib version clashes is already there since the git > plugin already has a dependency to JGit for some internal stuff, but do you > have any thought on how we could minimize this? >
It indeed uses some JGit classes for it's Repository objet model, but not to actualy access the repository > **** > > ** ** > > Could maybe the git plugin provide an api for other plugins to do git > operations? > ** > > The two features in the Gerrit Trigger I am thinking about for the moment > is pull #29 [1] where Emanuele is planning to use JGit to get the list of > changed files in the workspace, since it is not always the case that the > user has used the git plugin to get the patch set, we might need to do some > git operations in the workspace to find the culprits.**** > > We also have a long term plan to provide a Gerrit SCM implementation that > should be as close to zero conf as possible (all the information about what > to clone and fetch is provided by the trigger already). That would > introduce a lot of JGit code, or maybe we could just solve it by using the > git plugin behind the scenes from the user?**** > > ** > Some cleanup needed in git-plugin to make "IGitAPI" a real API, but fore sure then other plugin could use it as well to manage interaction with a git repository. Could maybe even be moved to a "jgit-plugin" utility plugin so that it would benefits contributions from various plugin uses cases. > **** > > ** > > WDYT?**** > > ** ** > > [1] https://github.com/jenkinsci/gerrit-trigger-plugin/pull/29**** > > ** ** > > ** ** > > * * > > *Robert Sandell***** > > Software Tools Engineer - SW Environment and Product Configuration**** > > Sony Mobile Communications**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *nicolas de loof > *Sent:* den 14 februari 2013 08:01 > *To:* [email protected] > > *Subject:* Re: use JGit in git-plugin**** > > ** ** > > There is already a IGitAPI that allows this isolate git cli specific > stuff, but never has been designed to let user select an implementation.** > ** > > ** ** > > My plan is to provide git-cli one as a plugin so you use JGit by default, > but can switch to git-cli that offer more options**** > > 2013/2/13 Jesse Glick <[email protected]>**** > > On 02/13/2013 01:58 PM, Emanuele Zattin wrote:**** > > It looks like Nicolas thought about [swappable implementations] already, > judging by the first commit in the branch**** > > > That has long existed; 64af8cf merely changed the _default_ from CLI to > JGit. There is still no UI to pick your preferred implementation.**** > > > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > **** > > ** ** > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > **** > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
