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