- Jun 28, 2010
-
-
Matthias Sohn authored
Change-Id: I589267e6cfd0514383c2a3da51c9b7a659f77844 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Jun 18, 2010
-
-
Matthias Sohn authored
Starting with 0.9 we do no longer support ganymede. http://dev.eclipse.org/mhonarc/lists/egit-dev/msg01277.html Change-Id: Ibf40342f67d9706e86336748f15d10ea47278096 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Jun 14, 2010
-
-
Shawn Pearce authored
Change-Id: I84173ece5100f1fcb78168e2e102b649d9466c08 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Change-Id: I21efed66921eb7e1e4010fccc9fa9af6c4150fc1 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Matthias Sohn authored
Created wrong tags for 0.8.3 hence creating another version. Change-Id: I4e00bbcffe1cf872e2d7e3f3d88d068701fb5330 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Jun 13, 2010
-
-
Matthias Sohn authored
Change-Id: I845da83c74475d74ec25d68f53c0a4738a898550 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Jun 02, 2010
-
-
Shawn Pearce authored
Change-Id: Id86e5876b2f684b2a272c07061a276b054ba410d Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Change-Id: I3d4ac7d0617a3575019e2ed748ed2a298a988340 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- May 11, 2010
-
-
Matthias Sohn authored
EGit Tycho builds on build.eclipse.org frequently hit corrupted artifacts which leads to broken builds. Cleaning up these corrupted files is tedious since it requires file system access on the build server. Hence we want to switch to use job-local m2 repositories. This requires that build artifacts are shared between the jgit and egit build jobs via p2. Therefore the bundle org.eclipse.jgit.junit needs to be exposed via p2 repository. Change-Id: I0ccd7763eede117cb68240fdd25f13d6e6f6a2c1 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Apr 10, 2010
-
-
Matthias Sohn authored
Change-Id: I99bac3376d9460ab94b548bd2f83be6fbc6ecbe3 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Apr 05, 2010
-
-
Robin Rosenberg authored
The JSch bundle in Eclipse 3.4 does not export its packages with version numbers. Use Require-Bundle on version 0.1.37 that comes with Eclipse 3.4 There is no 0.1.37 in the maven repositories so the pom still refers to 0.1.41 so the build can get the compile time dependencies right. Bug: 308031 CQ: 3904 jsch Version: 0.1.37 (using Orbit CQ2014) Change-Id: I12eba86bfbe584560c213882ebba58bf1f9fa0c1 Signed-off-by:
Robin Rosenberg <robin.rosenberg@dewire.com>
-
- Mar 22, 2010
-
-
Shawn Pearce authored
Change-Id: Ifad1a5a6f2909d709fd7834b32b9b9949b2e5633 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Change-Id: Ica516f1e34335ca7a05b071fd527027b10bb7e73 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Mar 21, 2010
-
-
Shawn Pearce authored
Since the API is changing relative to 0.7.0, we'll call our next release 0.8.1. But until that gets released, builds from master will be 0.8.0.qualifier. Change-Id: I921e984f51ce498610c09e0db21be72a533fee88 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Change-Id: I5afdc624b28fab37b28dd2cc71d334198672eef3 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Mar 19, 2010
-
-
Shawn Pearce authored
Change-Id: I9b00a4041c19115e81326afd2213b98603f789ad
-
- Feb 08, 2010
-
-
Matthias Sohn authored
Change-Id: Ie4133083a1cb1730f3dba52c0b8d359c7ed845e6 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Jan 23, 2010
-
-
Shawn Pearce authored
Change-Id: I45caafbad4daac827f661d38c7f719e9b5511dd4 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Matthias Sohn authored
Translate the version qualifier using maven-antrun-plugin since we want manifest-first and currently cannot rely on Tycho for the JGit build. Introduce property for Eclipse p2 repository to enable builds against other Eclipse versions. Change-Id: I62c4e77ae91fe17f56c5a5338d53828d4e225395 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Jan 15, 2010
-
-
Matthias Sohn authored
As discussed on the jgit-dev list here: http://dev.eclipse.org/mhonarc/lists/egit-dev/msg00654.html - Define a separate JGit feature. - As of now create a separate JGit update site and zip it. Change-Id: Ie4026f15f6250c4933dccf6f31b5009b90c036bc Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Jan 12, 2010
-
-
Shawn Pearce authored
Since Robin reverted using the maven-bundle-plugin to produce the OSGi manifest, there is no reason for us to reference it from our build process anymore. Also, when Robin reverted the to the Eclipse way of doing things, we failed to update the ignore files to ignore our generated files but not ignore our tracked .classpath. Finally, we cannot delete the MANIFEST.MF file during a Maven build, as this is once again a source file. Change-Id: I53f77f2002cb4285f728968829560e835651e188 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Jan 10, 2010
-
-
Robin Rosenberg authored
This restores the ability to build using just Eclipse without strange procedures, extra plugins and it is again possible to work on both JGit and EGit in the same Eclipse workspace with ease. Change-Id: I0af08127d507fbce186f428f1cdeff280f0ddcda Signed-off-by:
Robin Rosenberg <robin.rosenberg@dewire.com>
-
- Dec 28, 2009
-
-
Shawn Pearce authored
Tycho isn't production ready for projects like JGit to be using as their primary build driver. Some problems we ran into with Tycho 0.6.0 that are preventing us from using it are: * Tycho can't run offline The P2 artifact resolver cannot perform its work offline. If the build system has no network connection, it cannot compile a project through Tycho. This is insane for a distributed version control system where developers are used to being offline during development and local testing. * Magic state in ~/.m2/repository/.meta/p2-metadata.properties Earlier iterations of this patch tried to use a hybrid build, where Tycho was only used for the Eclipse specific feature and P2 update site, and maven-bundle-plugin was used for the other code. This build seemed to work, but only due to magic Tycho specific state held in my local home directory. This means builds are not consistently repeatable across systems, and lead me to believe I had a valid build, when in fact I did not. * Manifest-first build produces incomplete POMs The POM created by the manifest-first build format does not contain the dependency chain, leading a downstream consumer to not import the runtime dependencies necessary to execute the bundle it has imported. In JGit's case, this means JSch isn't included in our dependency chain. * Manifest-first build produces POMs unreadable by Maven 2.x JGit has existing application consumers who are relying on Maven 2.x builds. Forcing them to step up to an alpha release of Maven 3 is simply unacceptable. * OSGi bundle export data management is tedious Editing each of our pom.xml files to mark a new release is difficult enough as it is. Editing every MANIFEST.MF file to list our exported packages and their current version number is something a machine should do, not a human. Yet the Tycho OSGi way unfortunately demands that a human do this work. * OSGi bundle import data management is tedious There isn't a way in the MANIFEST.MF file format to reuse the same version tags across all of our imports, but we want to have a consistent view of our dependencies when we compile JGit. After wasting more than 2 full days trying to get Tycho to work, I've decided its a lost cause right now. We need to be chasing down bugs and critical features, not trying to bridge the gap between the stable Maven repository format and the undocumented P2 format used only by Eclipse. So, switch the build to use Apache Felix's maven-bundle-plugin. This is the same plugin Jetty uses to produce their OSGi bundle manifests, and is the same plugin used by the Apache Felix project, which is an open-source OSGi runtime. It has a reasonable number of folks using it for production builds, and is running on top of the stable Maven 2.x code base. With this switch we get automatically generated MANIFEST.MF files based on reasonably sane default rules, which reduces the amount of things we have to maintain by hand. When necessary, we can add a few lines of XML to our POMs to tweak the output. Our build artifacts are still fully compatible with Maven 2.x, so any downstream consumers are still able to use our build products, without stepping up to Maven 3.x. Our artifacts are also valid as OSGi bundles, provided they are organized on disk into a repository that the runtime can read. With maven-bundle-plugin the build runs offline, as much as Maven 2.x is able to run offline anyway, so we're able to return to a distributed development environment again. By generating MANIFEST.MF at the top level of each project (and therefore outside of the target directory), we're still compatible with Eclipse's PDE tooling. Our projects can be imported as standard Maven projects using the m2eclipse plugin, but the PDE will think they are vaild plugins and make them available for plugin builds, or while debugging another workbench. This change also completely removes Tycho from the build. Unfortunately, Tycho 0.6.0's pom-first dependency resolver is broken when resolving a pom-first plugin bundle through a manifest-first feature package, so bundle org.eclipse.jgit can't be resolved, even though it might actually exist in the local Maven repository. Rather than fight with Tycho any further, I'm just declaring it plugina-non-grata and ripping it out of the build. Since there are very few tools to build a P2 format repository, and no documentation on how to create one without running the Eclipse UI manually by poking buttons, I'm declaring that we are not going to produce a P2 update site from our automated builds. Change-Id: If7938a86fb0cc8e25099028d832dbd38110b9124 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Nov 03, 2009
-
-
Shawn Pearce authored
If we are on a Java 6 JVM we should have the Console class available, unless the user has redirected /dev/null to stdin. When there is a console present we would prefer to use that for command line prompts as that is what the user expects from a command line tool. Change-Id: Ibaf87bb5540371d94d96d1b7e94ca002f752e5bd Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
The LocalDiskRepositoryTestCase class is derived from the current RepositoryTestCase code and is meant for application (or our own) tests to subclass and access temporary repositories on the local client disk. Change-Id: Idff096cea40a7b2b56a90fb5de179ba61ea3a0eb Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Drop our simple and stupid jgit.sh and instead rely upon Maven for the command line based build. Maven is relatively simple to download and install, and doesn't require the entire Eclipse IDE. To avoid too much refactoring of the current code we reuse the existing src/ directory within each plugin, and treat each of the existing OSGI bundles as one Maven artifact. The command line wrapper jgit.sh no longer works in the uncompiled state, as we don't know where to obtain our JSch or args4j from. Developers will now need to compile it with `mvn package`, or run our Main class from within an IDE which has the proper classpath. Bug: 291265 Change-Id: I355e95fa92fa7502651091d2b651be6917a26805 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-