The intent, back in the mists of time, was always to use jGit rather than spawning the git commandline.
However, back then, jgit didn't actually support all the necessary functionality. So the idea was to have an interface, and plug-in whatever back-end git implementation was appropriate. Much time passes... the initial separation API is probably out of date, &c, &c, &c. It would be nice to not have to have the git binary for the plugin to work - but I suspect it's just never been a big enough itch for anyone to need to scratch... I don't see how there would be lib version clashes - I thought separate plugins had separate classloaders. Unless you mean serializing ObjectIDs between plugins - but jgit does the right thing there... On Thu, Feb 14, 2013 at 11:48 AM, nicolas de loof <[email protected]>wrote: > > > 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. > > > -- 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.
