From 8922f9a0cfcdecba09781211396e11d849d91931 Mon Sep 17 00:00:00 2001 From: Alex Eagle Date: Tue, 14 Oct 2014 21:25:55 -0700 Subject: [PATCH] Remove "html" suffix from links. This makes the URLs a lot prettier on errorprone.info. Sadly the local test server gives a 404 without the links. See https://github.com/barryclark/jekyll-now/issues/13 --- _layouts/bugpattern.html | 6 +-- _layouts/master.html | 4 +- bugpatterns.md | 2 +- compare-with-findbugs.md | 45 -------------------- developing.md | 88 ---------------------------------------- 5 files changed, 6 insertions(+), 139 deletions(-) delete mode 100644 compare-with-findbugs.md delete mode 100644 developing.md diff --git a/_layouts/bugpattern.html b/_layouts/bugpattern.html index 08a8775bfd8..ca8569f0e48 100644 --- a/_layouts/bugpattern.html +++ b/_layouts/bugpattern.html @@ -18,12 +18,12 @@
-

error-prone

 +

error-prone

Catch common Java mistakes as compile-time errors

View the Project on GitHub google/error-prone

diff --git a/_layouts/master.html b/_layouts/master.html index b00bdf5f783..6feb093b184 100644 --- a/_layouts/master.html +++ b/_layouts/master.html @@ -21,8 +21,8 @@

Catch common Java mistakes as compile-time errors

View the Project on GitHub google/error-prone

diff --git a/bugpatterns.md b/bugpatterns.md index 59a8a24e460..8e22e929d2c 100644 --- a/bugpatterns.md +++ b/bugpatterns.md @@ -12,7 +12,7 @@ are marked __On by default__, and each release promotes some experimental checks ##{{ maturity[0] }} {% for pattern in maturity[1] %} -__{{pattern.name}}__
+__{{pattern.name}}__
{{pattern.summary}} {% endfor %} diff --git a/compare-with-findbugs.md b/compare-with-findbugs.md deleted file mode 100644 index c8c7a0ff7ff..00000000000 --- a/compare-with-findbugs.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: How error-prone and Findbugs compare -layout: master ---- - -# Introduction - -Before starting error-prone, we worked with Findbugs author Bill Pugh to run Findbugs on Google's source code as changes are made, to identify newly added bugs. Our experience with Findbugs was mixed, because of the number of existing occurrences of Findbugs issues, and the difficulty of building it into code review tools. - -Major differences: - -* Findbugs inspects compiled bytecode; error-prone inspects Java source files -* Findbugs includes warnings for things like bad practices; error-prone only reports errors - -# Findbugs is better for - -**Catalog of detectors** - -Findbugs has a large number of detectors which have been built over time, and allows third-party plugins to contribute additional detectors. - -**Non-critical warnings** - -Findbugs results include a list of potential bad practices, as well as some false positives. If you have the inclination to inspect this list for things you care to fix, you can clean up your code. - -**Integration with IDE's** - -There are plugins for most IDEs which show Findbugs issues in real-time or at compile-time. These haven't yet been created for error-prone. - -# error-prone is better for - -**Preventing new occurrences** - -Errors which are caught sooner are cheaper to fix. - -By reporting errors in the Java compiler, error-prone gives the same user interface as syntax or type errors. This works well with existing tools, and is easy to enable in your build. This way, you prevent any occurrences from being added to your project. - -With Findbugs, you can add tooling to your build, but it's difficult to uniformly enforce this for your whole project since not all issues reported must be fixed, and not all developers run the tool. - -**Suggested fixes and refactoring** - -Since we inspect source files and have the AST available, we can suggest a code modification to correct an error. This will be useful for IDE plugins. It also lets us apply a fix for all existing occurrences in a large codebase like Google's, which is a prerequisite to enabling the error. - -**Ease of adding detector/checks** - -Adding a detector to Findbugs is difficult, as it requires knowledge of Java bytecode. Since error-prone operates on the AST, the model is already familiar to most Java programmers. \ No newline at end of file diff --git a/developing.md b/developing.md deleted file mode 100644 index 1264a062ef4..00000000000 --- a/developing.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Developing -layout: master ---- - -# Getting started - -We use the Maven build system. We are using version 3. [Download Maven](http://maven.apache.org/download.html) - -error-prone uses some compiler internals, so we don't support all JDK implementations. We test with OpenJDK 6 and 7, so those are currently recommended. Do whatever your system requires to use one of those JDKs. - -Build the library: -
-$ cd error-prone
-$ mvn -Ptools.jar package
-
- -If you don't want to remember the -P flag every time, just edit your `~/.m2/settings.xml`: -{% highlight xml %} - - tools.jar - -{% endhighlight %} -(if you don't have that file already, get the template at http://maven.apache.org/settings.html#Quick_Overview ) - -You'll also need to configure your IDE to build with a supported JDK. - -A Maven plugin for your IDE should setup the project very conveniently, and a git plugin can simplify source code management. The core developers use IntelliJ IDEA or Eclipse. - -It's very useful and recommended to locate the sources for your JDK and attach them in the IDE, so you can navigate into the javac libraries when needed. - -We generally follow the Sun style guide, and limit lines to 100 cols. - -# Write a checker - -Let's say you want to write a checker and contribute it to the project. Here are the steps you should follow. - -## Set up your work environment - -Follow the Getting Started steps above. Then create a branch in which to do your work. - -You should also add the check to the [Issue Tracker](https://code.google.com/p/error-prone/issues/list?can=2&q=Type%3DNewCheck) (if it is not already there), comment that you are taking the issue over, and change the status from "New" to "Accepted". - -## Write your checker - -Checkers are in the package com.google.errorprone.bugpatterns. Follow the example of one of the checkers in that package to create your own checker. Don't forget to write tests! - -## Request a code review - -A member of error-prone team needs to review your code and merge it into the mainline project. We use [https://code.google.com/p/rietveld/ Rietveld] for code reviews. - -Assuming you are in your work branch, and that branch contains all the changes you made, you want to diff the state of that branch against the master branch and upload the diff to Rietveld. - -To do that, first download the Rietveld [https://codereview.appspot.com/static/upload.py upload.py] script. Then run the following command: -
-$ upload.py --rev master
-
- -If you are using two-factor authentication, you may need to create an [https://support.google.com/accounts/answer/185833?hl=en application-specific password]. You can also choose a particular revision identifier to diff against, if you didn't do all your work in a branch. - -The upload.py script will output a link to the code review. Please go to the URL and edit the description to explain what your checker does. Then click "Publish + Mail Comments," put "eaftan@google.com" (important: the "@google.com" is necessary or we won't get your code review) in the reviewers field, and hit "Publish all my drafts." - -Now wait for your code review and address the comments. - -## Iterate on code review - -After you address a round of comments in the code review tool, please update your Rietveld code review with the diff from the previously uploaded revision. This lets your reviewer easily see the changes you made to address her comments. For example, if previously the head revision was 12345 and you uploaded a patch against master, and your Rietveld issue number was 987, you would use this command: -
-$ upload.py --rev 12345 -i 987
-
- -Update the review thread stating that you've addressed the comments. - -## Send us a patch - -After we've approved your code review, you need to get your changes to us. We use git-formatted patches for this. - -Create a patch that includes the changes against the master branch: -
-$ git format-patch master --stdout > mypatch.patch
-
- -Either email the patch to a team member or attach the patch to your code review request in the issue tracker. A member of the team will then merge your change into head: - -For the team: Apply the patch by typing -
-$ git am mypatch.patch
-
\ No newline at end of file