Twitter github

Posts Tagged with “jgit”

September 22, 2011
4 Comments

EGit and JGit 1.1 Released

By

The JGit and EGit project teams are proud to announce our 1.1 release in time for Indigo SR1!

To see what’s new, check out the respective JGit new and noteworthy and EGit new and noteworthy documents. In terms of new features, some of my favorites are the new reflog view which I had a hand in putting together.

If you ever wanted to know where a commit went, git-reflog can save you. In terms of other features, I’m really happy with the improvements to the synchronize view which just screams now in terms of performance (thank you Dariusz Luksza). I’m confident now that we should handle the majority of repositories with reasonable performance when trying to compare refs.

The other highlight of the release is the improvements to the GitHub Mylyn Connector.

GitHub Pull Requests can now be added as a Mylyn Task Repository type and you can now open pull requests with an editor (supports opening commits in the commit viewer). This is fantastic productivity boost (thanks Kevin Sawiciki) if you had to work with github pull requests via the command line before. On top of that, there’s a full implementation of the GitHub v3 API available via the EGit project.

Enjoy the release and thanks for your patience while we improve the Git support within Eclipse!

May 12, 2011
2 Comments

Git Ant Tasks via JGit

By

As part of our upcoming 1.0 release, JGit will feature some Git Ant tasks. This is great news if you want Ant tasks that are portable and don’t rely shelling out to call the Git command line interface. If you want to take a peak at the, check out the org.eclipse.jgit.ant module.

A special thank you to Ketan Padegaonkar from ThoughtWorks for the initial contribution. If you want more Ant tasks available, please feel free to contribute by looking at our contributor guide.

October 8, 2009
18 Comments

Modularity is Fun?

By

A few days ago I had one of those moments that made me smile, let me describe it in pictures…

I recently was hacking on the JGit project as I’m working on getting a build ready for the project.

What did I notice? Well, there was some evil UI code in the JGit bundle.

jgit1

You know what to do with evil UI code? Time to move it into another bundle!

jgit2

Sweet! Now we have a nice separation between core and ui layers, right?

jgit3

Oh no… compile errors… what the heck?

jgit4

It looks like some of the code in the core bundle was referencing UI pieces. This is an obvious bad practice since there is the common use case that people may want to run your code in a headless fashion. However, as a developer, it’s common to start out and just group your code into one bundle. It’s sad but it’s just the reality of development. This reason should also highlight to you why modularity doesn’t come for free… you have to think about your dependencies and architecture. If you produce complex code first and try to modularize it later… you’ll end up in painful situation. Thankfully, when you have good tools that manage your classpath for you, errors like this become evident.

Ok, enough of my diatribes, back to getting a build for JGit in place at Eclipse.

On a side note, I’ll soon blog about using EGit and Gerrit to develop JGit, stay tuned.