|
|
|
|
Hi,
for your information, I've started working on a JGit branch in git-plugin, to replace use of system git client in favor of a pure java implementation. Using git cli require to run a system process for all git operations. This is fragile : process can hang, plugin has to parse console output, and can then be broken by any outdated git installation and/or new git cli release that could change output format, option names, etc
JGit is not as simple to use as launching a command, but will ensure the git-plugin isn't system-dependent and more stable.
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|
|
|
Great job Nicolas! I will try to find some time to implement a few methods as well!
It helped me in some occasions :)
Cya!
Emanuele
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|
|
|
I've asked for this before. Please consider defining a "git API" that allows for swapping in different client implementations. We've seen from the Subversion plugin that some people would prefer the ability to use the native client, while others are OK
with SvnKit.
-- Dean
Great job Nicolas! I will try to find some time to implement a few methods as well!
It helped me in some occasions :)
Cya!
Emanuele
--
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
[hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|
|
|
It looks like Nicolas thought about that already, judging by the first commit in the branch :)
--
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|
|
|
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|
|
|
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 <[hidden email]>
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|
|
|
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? 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? WDYT? [1] https://github.com/jenkinsci/gerrit-trigger-plugin/pull/29 Robert Sandell Software Tools Engineer - SW Environment and Product Configuration Sony Mobile Communications 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 <[hidden email]> 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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|
|
|
2013/2/14 Sandell, Robert <[hidden email]>
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
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 <[hidden email]> 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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|
|
|
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 <[hidden email]> wrote:
2013/2/14 Sandell, Robert <[hidden email]>
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
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 <[hidden email]> 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 [hidden email].
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 [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
|
|
Locked
