Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Jan 10, 2010
  3. 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
    • Robin Rosenberg's avatar
      Recognize Git repository environment variables · eb63bfc1
      Robin Rosenberg authored 
      
This makes the jgit command line behave like the C Git implementation
in the respect.

These variables are not recognized in the core, though we add support
to do the overrides there. Hence other users of the JGit library, like
the Eclipse plugin and others, will not be affected.

GIT_DIR
	The location of the ".git" directory.

GIT_WORK_TREE
	The location of the work tree.

GIT_INDEX_FILE
	The location of the index file.

GIT_CEILING_DIRECTORIES
	A colon (semicolon on Windows) separated list of paths that
	which JGit will not cross when looking for the .git directory.

GIT_OBJECT_DIRECTORY
	The location of the objects directory under which objects are
	stored.

GIT_ALTERNATE_OBJECT_DIRECTORIES
	A colon (semicolon on Windows) separated list of object directories
	to search for objects.

In addition to these we support the core.worktree config setting when
the git directory is set deliberately instead of being found.

Change-Id: I2b9bceb13c0f66b25e9e3cefd2e01534a286e04c
Signed-off-by: default avatarRobin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      eb63bfc1
    • Robin Rosenberg's avatar
      Add support for creating detached heads · 5b13adce
      Robin Rosenberg authored 
      
An extra flag when creating a RefUpdate object allows the
caller to destroy the symref and replace it with an object
ref, a.k.a. detached HEAD.

Change-Id: Ia88d48eab1eb4861ebfa39e3be9258c3824a19db
Signed-off-by: default avatarRobin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      5b13adce
    • Shawn Pearce's avatar
      Use Constants.OBJECT_ID_STRING_LENGTH instead of LEN * 2 · 1ec393e7
      Shawn Pearce authored 
      
A few locations were doing OBJECT_ID_LENGTH * 2 on their own, as
the old STR_LEN constant wasn't visible.  Replace them with the
new public constant OBJECT_ID_STRING_LENGTH.

Change-Id: Id39bddb52de8c65bb097de042e9d4ed99598201f
Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      1ec393e7
    • Robin Rosenberg's avatar
      Get rid of a duplicate constant for SHA-1 length · db9f8126
      Robin Rosenberg authored 
      
Since Constants.OBJECT_ID_LENGTH is a compile time constant we
can be sure that it will always be inlined. The same goes for the
associated constant STR_LEN which is now refactored to the Constant
class and given a name better suited for wider use.

Change-Id: I03f52131e64edcd0aa74bbbf36e7d42faaf4a698
Signed-off-by: default avatarRobin Rosenberg <robin.rosenberg@dewire.com>
      db9f8126
  5. Dec 22, 2009
    • Nico Sallembien's avatar
      Fix typo in ReceivePack.java · a8817ed7
      Nico Sallembien authored 
      The comment indicates that a well-behaved client should not have
sent an update for a ref that already exists, but this in a block
that corresponds to a create command.
      a8817ed7
  7. Dec 18, 2009
  9. Dec 08, 2009
  11. Nov 29, 2009
  13. Nov 03, 2009
    • Shawn Pearce's avatar
      Move AWT based SSH authenticator to ui bundle · 27a497f8
      Shawn Pearce authored 
      
This way SWT based applications don't wind up loading this AWT
based code when using SSH.

Change-Id: I9080f3dd029c2a087e6b687480018997cc5c5d23
Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      27a497f8
    • Shawn Pearce's avatar
      Refactor the cached Authenticator data out of AwtAuthenticator · 91080357
      Shawn Pearce authored 
      
This makes it easier to swap out authenticator implementations and
yet still rely upon being able to configure at least one Authenticator
instance in the JVM and program it with data obtained from outside
of the user interface.

Change-Id: I8c1a0eb8acee1d306f4c3b40a790b7fa0c3abb70
Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      91080357
    • 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
  15. Oct 31, 2009
  17. Oct 16, 2009
  19. Oct 08, 2009
  21. Oct 05, 2009
  23. Oct 02, 2009
  25. Oct 01, 2009
  27. Sep 30, 2009
  29. Sep 29, 2009