We used our LICENSE file to describe both the license of the package,
and also the header template that should appear at the start of
all Java files we create. This creates a confusing situation for
readers who just want to consume the package, because our file
header template starts off in the middle of a sentence.
Move our template header to a separate file, and reformat the text
of the license to be something more readable by a person reviewing
the project's terms of use.
Change-Id: If318e64c06683ea14e0240914c2d057c9199ce98
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Windows doesn't permit us to edit a file in-place with Perl.
So create backup files when we perform the edit, and remove them
when we are done. This is a tad slower on POSIX systems, but is
much more portable.
Change-Id: I429c7d698924cb32e709363f5da82f7232bbdab2
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Tag the version number and API range in the OSGi manifest files
whenever we bump the pom.xml files.
Change-Id: I7c38b51f7139c02bef6b0e67d3f9199cbcdc8a39
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The script merges explicit copyright statements in all Java
sources with author information from git history, updates the
copyright headers accordingly, and updates the license headers
to EDL. For recognized copyright formats see the test data in
tools/fix-headers.tst.
To fix headers only in the current working directory:
./tools/fix-headers.pl
To fix the headers for all revisions (don't do this if you don't
understand the implications of rewriting history) run:
./tools/rewrite-history.sh
Authors are mapped to employer copyright statements through a
hardcoded table in the top of the script. This is a crude but
simple way to list date ranges under which certain changes need
to be attributed to copyright holders other than the author.
Change-Id: I654d758658cded02d91324c385f336bcc57fd85f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
We can now use `tools/version.sh --release` to update the MANIFEST.MF
and Maven POM files with the current version number of this project,
so they appear in any build product created.
The counterpart --snapshot option be used to reset files to use
their natural *-SNAPSHOT and *.qualifier state during development.
We use a simple Bourne shell script with Perl calls because we
must edit both Maven pom.xml and OSGi bundle MANIFEST.MF in order
to store the correct data for our parallel build systems. In the
future we should use a native Java solution which relies upon JGit
to compute the `git describe` portion.
Until we tag our first official release a "tagged snapshot" can be
made by creating an artifical annotated tag first:
git tag -a -m "initial contribution" v0.5.1 046198cf5f21e5a63e8ec0ecde2ef3fe21db2eae
tools/version.sh --release
Resulting in a version string like "0.5.1.50-ge16af83".
Change-Id: Ic2bbae75bf96fc8831324c62c2212131277f70e4
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now supply an exported format description for anyone to import
into their own workbench, and all projects reference this style in
a consistent way.
Change-Id: Ic243544a761ef2db29025a89ba6bb932a3a3ce34
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This script can be executed by a developer to download and graft
on the old JGit history, from before we moved the project to the
eclipse.org namespace and the Eclipse Foundation servers.
Executing this script is only necessary if you need to run log or
blame past the migration boundary, and isn't always recommended when
it comes to pushing objects to a remote server. As mentioned in the
script, it is best to use a specialized repository with this graft,
not your main work repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Matthias Sohn