纯java实现的git操作库。
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

496 lines
16 KiB

<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (C) 2009-2010, Google Inc.
and other copyright owners as documented in the project's IP log.
This program and the accompanying materials are made available
under the terms of the Eclipse Distribution License v1.0 which
accompanies this distribution, is reproduced below, and is
available at http://www.eclipse.org/org/documents/edl-v10.php
All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
- Neither the name of the Eclipse Foundation, Inc. nor the
names of its contributors may be used to endorse or promote
products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.eclipse.jgit</groupId>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<artifactId>org.eclipse.jgit-parent</artifactId>
<packaging>pom</packaging>
<version>2.0.0-SNAPSHOT</version>
<name>JGit - Parent</name>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<url>${jgit-url}</url>
<description>
Pure Java implementation of Git
</description>
<scm>
<url>http://egit.eclipse.org/w/?p=jgit.git</url>
<connection>scm:git:git://egit.eclipse.org/jgit.git</connection>
</scm>
<developers>
<developer>
<name>Chris Aniszczyk</name>
</developer>
<developer>
<name>Christian Halstrick</name>
</developer>
<developer>
<name>Gunnar Wagenknecht</name>
</developer>
<developer>
<name>Kevin Sawicki</name>
</developer>
<developer>
<name>Mathias Kinzler</name>
</developer>
<developer>
<name>Matthias Sohn</name>
</developer>
<developer>
<name>Robin Rosenberg</name>
</developer>
<developer>
<name>Sasa Zivkov</name>
</developer>
<developer>
<name>Shawn Pearce</name>
</developer>
<developer>
<name>Stefan Lay</name>
</developer>
</developers>
<mailingLists>
<mailingList>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<name>jgit-dev Mailing List</name>
<post>jgit-dev@eclipse.org</post>
<subscribe>https://dev.eclipse.org/mailman/listinfo/jgit-dev</subscribe>
<unsubscribe>https://dev.eclipse.org/mailman/listinfo/jgit-dev</unsubscribe>
<archive>http://dev.eclipse.org/mhonarc/lists/jgit-dev</archive>
</mailingList>
<mailingList>
<name>GIT Mailing List</name>
<post>git@vger.kernel.org</post>
<archive>http://marc.info/?l=git</archive>
</mailingList>
</mailingLists>
<issueManagement>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<url>https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;component=JGit;product=JGit;classification=Technology</url>
<system>Bugzilla</system>
</issueManagement>
<licenses>
<license>
<name>Eclipse Distribution License (New BSD License)</name>
<comments>
All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
- Neither the name of the Eclipse Foundation, Inc. nor the
names of its contributors may be used to endorse or promote
products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
</comments>
</license>
</licenses>
<properties>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<jgit-url>http://www.eclipse.org/jgit/</jgit-url>
<jgit-copyright>Copyright (c) 2005, 2009 Shawn Pearce, Robin Rosenberg, et.al.</jgit-copyright>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format>
<bundle-manifest>${project.build.directory}/META-INF/MANIFEST.MF</bundle-manifest>
<jgit-last-release-version>1.3.0.201202151440-r</jgit-last-release-version>
<jsch-version>0.1.44-1</jsch-version>
<junit-version>4.5</junit-version>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<args4j-version>2.0.12</args4j-version>
<servlet-api-version>2.5</servlet-api-version>
<jetty-version>7.6.0.v20120127</jetty-version>
<protobuf-version>2.4.0a</protobuf-version>
<clirr-version>2.3</clirr-version>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
</properties>
<repositories>
<repository>
<id>jgit-repository</id>
<url>http://download.eclipse.org/jgit/maven</url>
</repository>
<repository>
<id>jetty</id>
<layout>p2</layout>
<url>http://download.eclipse.org/jetty/updates/jetty-bundles-7.x/${jetty-version}/</url>
</repository>
</repositories>
<build>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3</version>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<configuration>
<archive>
<manifestEntries>
<Implementation-Title>JGit ${project.artifactId}</Implementation-Title>
<Implementation-Version>${project.version}</Implementation-Version>
<Implementation-Vendor>Eclipse.org - JGit</Implementation-Vendor>
<Implementation-Vendor-Id>org.eclipse.jgit</Implementation-Vendor-Id>
<Implementation-Vendor-URL>${jgit-url}</Implementation-Vendor-URL>
</manifestEntries>
</archive>
</configuration>
</plugin>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
</plugin>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.4.1</version>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>1.5</version>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.3</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.1.2</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.8</version>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.9</version>
</plugin>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<findbugsXmlOutput>true</findbugsXmlOutput>
<failOnError>false</failOnError>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.6</version>
<configuration>
<sourceEncoding>utf-8</sourceEncoding>
<minimumTokens>100</minimumTokens>
<targetJdk>1.5</targetJdk>
<format>xml</format>
<failOnViolation>false</failOnViolation>
</configuration>
<executions>
<execution>
<goals>
<goal>cpd-check</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>clirr-maven-plugin</artifactId>
<version>${clirr-version}</version>
<configuration>
<comparisonVersion>${jgit-last-release-version}</comparisonVersion>
<minSeverity>info</minSeverity>
</configuration>
</plugin>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
</plugins>
</pluginManagement>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>translate-qualifier</id>
<phase>generate-resources</phase>
<configuration>
<target if="${translate-qualifier}">
<copy file="META-INF/MANIFEST.MF" tofile="${bundle-manifest}" overwrite="true"/>
<replace file="${bundle-manifest}">
<replacefilter token=".qualifier" value=".${maven.build.timestamp}"/>
</replace>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Build helper maven plugin sets the parsedVersion.osgiVersion property -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<executions>
<execution>
<id>set-osgi-version</id>
<phase>validate</phase>
<goals>
<goal>parse-version</goal>
</goals>
</execution>
</executions>
</plugin>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<encoding>${project.build.sourceEncoding}</encoding>
<quiet>true</quiet>
<links>
<link>http://java.sun.com/j2se/1.5.0/docs/api</link>
</links>
</configuration>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<inherited>true</inherited>
<executions>
<execution>
<id>attach-sources</id>
<phase>process-classes</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.jcraft</groupId>
<artifactId>jsch</artifactId>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<version>${jsch-version}</version>
</dependency>
<dependency>
<groupId>args4j</groupId>
<artifactId>args4j</artifactId>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<version>${args4j-version}</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<version>${junit-version}</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>${servlet-api-version}</version>
</dependency>
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-servlet</artifactId>
<version>${jetty-version}</version>
</dependency>
<dependency>
<groupId>com.google.protobuf</groupId>
<artifactId>protobuf-java</artifactId>
<version>${protobuf-version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<distributionManagement>
<snapshotRepository>
<id>jgit-maven-snapshot</id>
<name>JGit Maven Repository</name>
<url>dav:https://egit.googlecode.com/svn/maven/</url>
<uniqueVersion>true</uniqueVersion>
</snapshotRepository>
</distributionManagement>
<profiles>
<!-- Set -Djgit.java6.skip=true to compile with only Java 5 -->
<profile>
Switch build to Apache Felix maven-bundle-plugin 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>
15 years ago
<id>jgit.java6</id>
<activation>
<property>
<name>!jgit.java6.skip</name>
</property>
</activation>
<modules>
<module>org.eclipse.jgit.console</module>
</modules>
</profile>
<profile>
<id>static-checks</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
</plugin>
</plugins>
</build>
</profile>
</profiles>
<modules>
<module>org.eclipse.jgit</module>
<module>org.eclipse.jgit.generated.storage.dht.proto</module>
Store Git on any DHT jgit.storage.dht is a storage provider implementation for JGit that permits storing the Git repository in a distributed hashtable, NoSQL system, or other database. The actual underlying storage system is undefined, and can be plugged in by implementing 7 small interfaces: * Database * RepositoryIndexTable * RepositoryTable * RefTable * ChunkTable * ObjectIndexTable * WriteBuffer The storage provider interface tries to assume very little about the underlying storage system, and requires only three key features: * key -> value lookup (a hashtable is suitable) * atomic updates on single rows * asynchronous operations (Java's ExecutorService is easy to use) Most NoSQL database products offer all 3 of these features in their clients, and so does any decent network based cache system like the open source memcache product. Relying only on key equality for data retrevial makes it simple for the storage engine to distribute across multiple machines. Traditional SQL systems could also be used with a JDBC based spi implementation. Before submitting this change I have implemented six storage systems for the spi layer: * Apache HBase[1] * Apache Cassandra[2] * Google Bigtable[3] * an in-memory implementation for unit testing * a JDBC implementation for SQL * a generic cache provider that can ride on top of memcache All six systems came in with an spi layer around 1000 lines of code to implement the above 7 interfaces. This is a huge reduction in size compared to prior attempts to implement a new JGit storage layer. As this package shows, a complete JGit storage implementation is more than 17,000 lines of fairly complex code. A simple cache is provided in storage.dht.spi.cache. Implementers can use CacheDatabase to wrap any other type of Database and perform fast reads against a network based cache service, such as the open source memcached[4]. An implementation of CacheService must be provided to glue this spi onto the network cache. [1] https://github.com/spearce/jgit_hbase [2] https://github.com/spearce/jgit_cassandra [3] http://labs.google.com/papers/bigtable.html [4] http://memcached.org/ Change-Id: I0aa4072781f5ccc019ca421c036adff2c40c4295 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
<module>org.eclipse.jgit.storage.dht</module>
<module>org.eclipse.jgit.ant</module>
<module>org.eclipse.jgit.ui</module>
<module>org.eclipse.jgit.http.server</module>
<module>org.eclipse.jgit.iplog</module>
<module>org.eclipse.jgit.pgm</module>
<module>org.eclipse.jgit.junit</module>
<module>org.eclipse.jgit.junit.http</module>
<module>org.eclipse.jgit.test</module>
<module>org.eclipse.jgit.ant.test</module>
<module>org.eclipse.jgit.http.test</module>
Store Git on any DHT jgit.storage.dht is a storage provider implementation for JGit that permits storing the Git repository in a distributed hashtable, NoSQL system, or other database. The actual underlying storage system is undefined, and can be plugged in by implementing 7 small interfaces: * Database * RepositoryIndexTable * RepositoryTable * RefTable * ChunkTable * ObjectIndexTable * WriteBuffer The storage provider interface tries to assume very little about the underlying storage system, and requires only three key features: * key -> value lookup (a hashtable is suitable) * atomic updates on single rows * asynchronous operations (Java's ExecutorService is easy to use) Most NoSQL database products offer all 3 of these features in their clients, and so does any decent network based cache system like the open source memcache product. Relying only on key equality for data retrevial makes it simple for the storage engine to distribute across multiple machines. Traditional SQL systems could also be used with a JDBC based spi implementation. Before submitting this change I have implemented six storage systems for the spi layer: * Apache HBase[1] * Apache Cassandra[2] * Google Bigtable[3] * an in-memory implementation for unit testing * a JDBC implementation for SQL * a generic cache provider that can ride on top of memcache All six systems came in with an spi layer around 1000 lines of code to implement the above 7 interfaces. This is a huge reduction in size compared to prior attempts to implement a new JGit storage layer. As this package shows, a complete JGit storage implementation is more than 17,000 lines of fairly complex code. A simple cache is provided in storage.dht.spi.cache. Implementers can use CacheDatabase to wrap any other type of Database and perform fast reads against a network based cache service, such as the open source memcached[4]. An implementation of CacheService must be provided to glue this spi onto the network cache. [1] https://github.com/spearce/jgit_hbase [2] https://github.com/spearce/jgit_cassandra [3] http://labs.google.com/papers/bigtable.html [4] http://memcached.org/ Change-Id: I0aa4072781f5ccc019ca421c036adff2c40c4295 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
<module>org.eclipse.jgit.storage.dht.test</module>
<module>org.eclipse.jgit.pgm.test</module>
</modules>
</project>