I am making a Java application that uses Git. I found that there is something called
JavaGit, EGit and JGit.
I know that JavaGit and EGit/JGit are different. What I don't understand is the difference between EGit and JGit. Both are hosted on Eclipse projects but one seems to be Eclipse related and the other not.
I don't use Eclipse and I don't plan to, so I really don't care much about "Eclipse integration".
Is JGit somehow connected to Eclipse? (It is hosted on www.eclipse.org, and the documentation of JGit also has a lot of "eclipse" keywords inside)
Out of the three, what will I need to connect my Java program (not written in Eclipse) to work with Git repositories?
I would prefer a standalone Git library (i.e., without depending on a local Git installation)
EDIT: One more question:
Does JGit support Git bundle command?
EDIT: I found the answer -- it does (haven't tried it yet). It is in transport package in a class called BundleWriter
You can use JGit as standalone library, but, as mentioned in the JGit Homepage:
JGit can be found within:
* EGit, Eclipse team provider for Git
In that sense, JGit is connected to Eclipse in that EGit uses JGit features to develop the Eclipse Git plugin.
Considering all Eclipse projects are now versioned in Git repos (instead of previously CVS repos), I would consider JGit for your Java project, as it seems that:
JavaGit isn't updated for quite some time (2008)
Eclipse is committed to offer a good support for Git through EGit, which should ensure by extension the development of JGit (used by EGit).
Thorbjørn Ravn Andersen comments:
Even though you say that Egit uses JGit, it is not quite clear in the above that EGit is an Eclipse plugin for git giving git support in the same way that CVS is already supported in Eclipse
The migration of Eclipse projects from CVS to Git is in progress, and has been reported here (by Chris Aniszczyk).
I’ve monitored conversations concerning the migration of project code from CVS to Git in the dev-lists of several projects.
Most developers, it seems, understand the value proposition of migrating, despite their concerns that with migration comes a whole lot of new learnin’ as they figure out how to say productive in the new environment.
Inevitably, discussion about the team provider for Git being developed by the EGit project becomes an prominent part of the conversation. “Is EGit ready for primetime?” is often the question that bounced around
The official bug illustrated Eclipse commitment to provide "adequate tooling support" for all Eclipse projects now on Git repo is the bug 293192.
In order to deprecate old VCS in favour of git (bug 270854), adequate tooling
should be available. This bug is created to track that.
[...] I opened/linked relevant EGit bugs in order to have a better visibility/tracking
of what's missing.
So Egit is the only project referenced in that bug to provide said adequate tooling support for the new (D)VCS chosen for all Eclipse projects.
(bug 270854 is about Deprecate old VCS tools, which includes essentially CVS.)
Just in (March 17th, 2001): The State of Git at Eclipse – Early 2011 (Chris Aniszczyk):
I’m happy that things have come quite a long way since last year based on Eclipse Marketplace stats and the community contributions the projects have received.
So what’s next? In terms of tooling, we’re getting closer to our 1.0 release (which is planned for the Indigo release).
The git tooling at Eclipse is much better these days, if you need help or have questions, please start with the most excellent EGit User Guide.
If you’re an eclipse.org project, please consider starting the process to move your project repository to Git. There are a lot of eclipse.org projects already on Git.
It would be nice to see the all of the eclipse.org projects have plans to move to Git by the Indigo release.
As one of the authors of JGit and EGit, sorry for the confusion.
JGit is an EDL (new-style BSD) licensed, lightweight, pure Java library implementing the Git version control system. It can be used in a standalone fashion and is embedded in applications such as Gerrit, Eclipse, Netbeans and IntelliJ. EGit embeds JGit to use it to work with Git repositories and expose Git constructs from within Eclipse. At the moment, JGit doesn't support the git-bundle command but you're welcome to contribute support, it shouldn't be that hard, please see our contributor guide.
Just to chime in, as I just stumbled on this this question just now.
There is a difference between the Eclipse Foundation and the Eclipse IDE. The Foundation is the umbrella organization, while the IDE is one of the projects developed through the foundation. So, the important thing to know is that just as Apache started with the web server and branched out to become a Foundation hosting a number of projects, so has the Eclipse Foundation now expanded beyond its "roots" in the IDE.
So in this context the JGit code provides a Java API for git commands, while EGit uses JGit to provide git support for the Eclipse IDE.
Personally, I also find this a little confusing at times, and sometimes it almost seems that having so much going on has in some ways degraded the focus of these organizations; however I can also see the utility in having one umbrella organization instead of 20 similar but different organizations.
JGit is git implemented from scratch as a Java library whereas JavaGit is (was ?) a Java API wrapping the native git implementation (i.e. it's calling the native git command line).
EGit is the Git Eclipse Team Provider integrating JGit into the Eclipse IDE and is providing the UI to work with Git from inside Eclipse.
In the meantime a large part of the Eclipse community and also a large number of corporate developers is using EGit/JGit (that's the reason why the companies backing these projects put money into that). See the project pages ([1], [2]) and ohloh if you want to get some insight who is contributing.
JGit is a library to manipulate git repository. You do not use JGit alone, unless you write a program to manipulate git repository in the way you like.
If you use Eclipse as the IDE, you install EGit as a version control plugin (defaulted in Indigo). EGit calls JGit so you also have JGit installed if you install EGit.
Note, for Netbeans, you install NBGit as a version control plugin. NBGit also calls JGit.
JavaGit: not actively maintained?
JGit is the Java implementation of Git. It is a library, that also can be used in your own applications. It also provides some sort of CLI operations.
EGit on the other side is the Eclipse team provider plugin for Git, which uses JGit as Git implementation. Simplified you could say EGit is the UI part, and JGit the background part.
JGit doesn't depend on EGit, but EGit does depend on JGit.
From: https://www.eclipse.org/forums/index.php/t/273443/
Related
I develop with eclipse, Java for Android. I just installed SVN subclipse for the company. I made the repository in a cloud (maybe it is a mistake, I can change it) and we all work every one in his computer and then commit the code to the repository.
The repository is always the latest code of all the developers.
I don't find a way how to compile the repository and build an APK file. How can I do it?
Typically you would use some continous integration system like Jenkins. It can fetch the code from your svn repository (or git for that matter), and perform most anything you want. This seems like a good starting point: Building android apps with Jenkins/Hudson (even if the link is a bit old).
I have several projects linked to bitbucket repositories using EGit. If I use IntelliJ IDEA for development instead, is there anything I need to keep in mind when migrating the projects over, and keeping them on that repository and updated with IntelliJ's git integration?
Considering the IntelliJ-git integration requires a git, make sure you have the latest (1.8.3+) installed.
Otherwise, you should be able to use the same working tree/repo as the one used by Eclipse Egit. No special migration should be required.
I am building a plugin for Eclipse - but as we use Maven as a standard build platform I would like to be able to build the plugin using Maven.
I have found a previous question about using Maven with Eclipse Plugins - but as it is a year old I thought it was worthwhile collecting some new answers:
Is it currently possible to build Eclipse Plugins by Maven AND have nice IDE Integration?
It seems that Tycho has not been driven forward much in the last year - but has anything else been created that fulfils this need or is there an easier way?
Does anyone recommend still the Maven PDE plugin? Is this a cumbersome solution as it is just a wrapper for ANT scripts?
I'm on the Tycho mailing list and I see plenty of feedback that suggests that people are successfully building plug-ins using Maven. My current project isn't doing OSGi development, so I can't vouch from personal experience with the latest version of Tycho. It's also worth pointing out that Tycho currently supports (to the best of my knowledge) a manifest-first approach to building plug-ins (as apposed to POM-first) - this might be a factor in deciding if Maven/Tycho fits your project.
It seems that Tycho has not been driven forward much in the last year - but has anything else been created that fulfils this need or is there an easier way?
The project is definitely active (have a look at the git repository), regardless of the updates of its website and AFAIK Sonatype is using it (successfully) for m2eclipse.
I'm looking for a complete java development infrastructure with an integration of:
an IDE like eclipse,
a build system like Maven,
a version control system like subversion,
a continuous integration server like Hudson,
a repository manager like Nexus,
an automated release plugin like Maven Release Plugin.
Further I'd like to have:
a predefined multi component project structure
...and optionally:
an issue manager like Jira,
an integration with an open source hoster like sourceforge.
Evaluating all these systems could take a long time, making the setup of a running infrastructure a job of a month or longer.
At work I'm ready to setup each system individually, but for my private development at home I'd like to have something like Devware - A development environment virtual appliance (unfortunately I didn't find a download link) where everything is already installed and functional.
So, could you please give me some advice which combinations create a working infrastructure? Or even better where to find a preconfigured development infrastructure?
PS: I'm not committed to any of the named products, so feel free to suggest alternatives if they match better.
If you're looking to avoid some integration pains, check out SecureCI, which is a free download of various open-source products in an integrated stack.
Blurb from the site:
SecureCI™ provides organizations with an integrated suite of open source tools that assist in the automation of the software build, test, and deploy process. By integrating secure code analysis and web security testing technologies, SecureCI extends continuous integration to incorporate automated security analysis and security testing of applications as well.
The current version bundles these tools:
Project Management
Trac (0.11.5)
Sonar (1.10.1)
Security Scanning
ratproxy (1.58)
Development
Subversion (1.4.6)
Hudson (1.322)
Apache Ant (1.7.1)
Apache Maven (2.2.1)
Sonatype Nexus (1.3.6)
Testing
JUnit (4.6)
Cobertura (1.9.2)
Selenium Remote Control (1.0.1)
Code Analysis
Checkstyle (5.0)
FindBugs (1.3.8)
PMD (4.2.5)
JDepend (2.9)
As far as IDE integrations are concerned, later versions of Eclipse now come integrated with Mylyn, this provides a task focused API for connecting to various tools.
The Trac integration can be installed with the Connector Install Wizard.
Other Eclipse integrations to use:
Subversion integration: Subclipse and the Subclipse Mylyn integration)
Hudson plugin
Maven integration: M2Eclipse (also has some Mylyn connectors)
Code Coverage: ECLEmma (I find the Cobertura plugin doesn't work too well myself)
Selenium plugin
Checkstyle plugin
Findbugs plugin
PMD plugin
JDepend plugin or CAP
Or just use IntelliJ from JetBrains.
You might want to look into http://www.poweredbypulse.com. It provides easy to install pre-configured Eclipse instances. You can also build/configure your own.
It has been a while since I actually used this so it may have changed since then.
We have several products which have a lot of shared code and which must be maintained several versions back.
To handle this we use a lot of Eclipse projects, some contain library jars, and some contain shared source code (in several projects to avoid getting a giant heap with numerous dependencies while being able to compile everything from scratch to ensure that source and binaries are consistent). We manage those with projectSet.psf's as these can directly pull all projects out from CVS and leave a fully prepared workspace. We do not do ant builds directly or use maven.
We now want to be able to put all these projects and their various versions in a Continous Integration tool - I like Hudson but this is just a matter of taste - which essentially means that we need to get an automatic way to check out the projects to a fresh workspace, and compile the source folders as described in the project-files in each project. Hudson does not provide such an approach to build a project, so I have been considering what the best way to approach this would be.
Ideas have been
Find or write an ant plugin/converter that understands projectSet.psf's and map to cvs-checkout and compile tags.
Create the build.xml files from within Eclipse and use those. I tried this, and found the result to be verbose and with absolute locations which is not good with automatic tools putting files where they want to.
Write a Hudson plugin which understands projectSet.psf's to derive a configuration and build it.
Just bite the bullet and manually create and update the CI configuration whenever stuff breaks - I don't like this :)
I'd really like to hear about other peoples experiences so I can decide how to approach this.
Edit: Another option might be using a CI which knows better about Eclipse projects and/or project sets. We are not religious - this is just a matter of getting stuff running without having to do everything ourselves. Would Cruise Control be a better option perhaps? Others?
Edit: Found that ant4eclipse has a "Team Project Set" facility. http://ant4eclipse.sourceforge.net/
Edit: Used the ant4eclipse and ant-contrib ant extensions to build a complete workspace as a sjgned runnable jar file similar to the Runnable Jar facility in Eclipse 3.5M6. I am still depending on Eclipse to create the initial empty workspace, and extract the ProjectSet, so that is the next hurdle.
Edit: Ended up with a dual configuration, namely that Hudson extracts the same set of modules as listed in the ProjectSet.pdf file from CVS (which needs to have the same tag) causing them to be located next to each other. Then ant4eclipse works well with the projectSet.psf file embedded in the main module. Caveat: Module list in Hudson must be manually updated, and it appears that a manual workspace cleanup is needed afterwards to let Hudson "discover" that there is more projects now than earlier. This has now worked well for us for a couple of months, but it was quite tedious to get everything working inside the ant file.
Edit: The "Use Team Projects" with ant4eclipse and a Ctrl-A, Ctrl-C in Project Panel with a Ctrl-V in the CVS projects in Hudson has turned out to work well enough for us to live with (for mature projects this is very rarely changed). I am awaiting the release of ant4eclipse 1.0 - http://www.ant4eclipse.org/, currently in milestone 2 - to see how much homegrown functionality can be replaced with ant4eclipse things.
Edit: ant4eclipse is as of 20100609 in M4 so the schedule at http://www.ant4eclipse.org/node?page=1 is slipping somewhat.
Edit: My conclusion after using our ant4eclipse approach for a longer period is that the build script get very gnarly and is hard to maintain. Also the Team ProjectSet facility (which ant4eclipse use to locate the projects) which works well for CVS based repositories, but not after we migrated to git (which is a big thing in itself). New projects will most likely be based on maven, as this has good support in Jenkins.
I'm not completely sure I understand the problem, but it sounds like the root issue is that you have many projects, some of which are dependent on others. Some of the projects that are closer to the "leaf" of the dependency tree need to be able to use "stable" (or previously "released") versions of the more "core" projects.
I solve exactly this problem using Hudson, ant, and ivy. I follow a pattern demonstrated by Clark in Pragmatic Project Automation (he doesn't demonstrate the dependency problems and solutions, and he uses CruiseControl rather than hudson.)
I have a hand-written ant build file (we call it "cc-build.xml", because of our CruiseControl roots.) This file is responsible for refreshing the working space for the project from the CM repository and labeling the contents for future reference. It then hands off control to another hand-written ant build file (build.xml) that is provided by each project's developers. This project is responsible for the traditional build steps (compile, packaging, etc.) It is required to spit out the installable artifacts, unit test reports, etc, to the Hudson artifacts directory. It is my experience that automatically generated build files (by Eclipse or other similar IDE's) will never get close to getting this sufficiently robust for use in a CI scenario.
Additionally, it uses ivy to resolve its own dependencies. Ivy supports precisely-specified dependency versions (e.g. "use version 1.1") and it supports "fuzzy versions" (e.g. "use version 1.1+" or "use the latest version in integration status.") Our projects typically start out specifying a very "fuzzy" version for internal projects under ongoing development, and as they get close to a release point, they "freeze" the dependency version so that stuff stops moving underneath them.
The non-leaf projects (projects that are dependents for other projects) also use ivy to publish their artifacts to our internal ivy repository. That repository keeps all past builds of the dependents, so that any project can always depend on any other previous version.
Lastly, each project in Hudson is configured to have a build trigger that causes a rebuild when any of its dependent projects successfully build. This causes them to get built again with the (possibly) new ivy dependent version.
It is worth noting that once you get this up and running, consistent automated "labeling" or "tagging" of an automated build's inputs is going to be critical for you - otherwise troubleshooting post-build problems is going to result in having to untangle a hornet's nest to find the original source.
Getting all of this setup for our environment took quite a bit of effort (primarily in setting up the ivy repository and ant build files,) but it has paid for itself many times over in saved headaches in manually managing the dependencies and decreased troubleshooting effort.
Write a Hudson plugin which
understands projectSet.psf's to derive
a configuration and build it.
That seems like the winning answer to me.
I work with CruiseControl rather than Hudson but in my experience if you can create a plugin that solves your problem it will quickly payoff. And it is generally pretty easy to write a plugin that is custom fit for your solution as opposed to one that needs to work for everyone in a similar situation.
I have tried both Cruise Control (CC) and Hudson for our CI solution. We (as a company) decided on Hudson. But for your question "Does CC support Eclipse project build" the answer is no as far as I know. CC supports many more different build tools and Source Control systems but it is a bit more difficult to configure and use. As for Hudson, it is more simple to configure and use it. We developed our custom plugins for both CC and Hudson for the parts of our build cycle that they do not provide as is. As for plugin development, if you know / use Maven, Hudson is simpler too. But if you are not familiar to Maven, first you need to learn the basic usage of maven to successfully develop a Hudson plugin. But once you understand the basic usage of maven, plugin development, test and even debug is simpler in Hudson.
For your specific problem, I can think of a solution that makes use of Eclipse plugins as well. You can develop your own Eclipse plugin that for instance gets the psf files from a (configurable) folder, and use Eclipse internals to process these psf's. I mean you can use existing Eclipse source codes that takes a psf file, check-outs it's project definitions and compile these projects. This Eclipse plugin of yours may have a preference page (which you can access by Eclipse -> Window -> Preferences) and configure which folder it will use to look for psf files. Your Eclipse plugin should also have a way to start psf processing without user interaction. For this, you can use ipc to trigger your process. I mean your Eclipse plugin can listen for a port, and you can write another java application that will connect to your plugin through this port and trigger its process. As for CI part, you can use either CC or Hudson and use their external process execution support. If you are using Windows, you can write a bat file (for Linux sh file) that first launchs Eclipse that has your plugin installed. Then it launches your java application that will communicate with your Eclipse plugin to trigger your process. From your CI tool you will need to run your bat / sh file to trigger your process.