1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
# How to submit a bug report
If you received an error message, please include it and any exceptions.
We commonly need to know what platform you are on:
* JDK/JRE version (i.e., `java -version`)
* Operating system (i.e., `uname -a`)
# How to contribute
We definitely welcome patches and contributions to Instrumentation! Here are
some guidelines and information about how to do so.
## Before getting started
In order to protect both you and ourselves, you will need to sign the
[Contributor License Agreement](https://cla.developers.google.com/clas).
[Eclipse](https://google-styleguide.googlecode.com/svn/trunk/eclipse-java-google-style.xml)
and
[IntelliJ](https://google-styleguide.googlecode.com/svn/trunk/intellij-java-google-style.xml)
style configurations are commonly useful. For IntelliJ 14, copy the style to
`~/.IdeaIC14/config/codestyles/`, start IntelliJ, go to File > Settings > Code
Style, and set the Scheme to `GoogleStyle`.
## Style
We follow the [Google Java Style
Guide](https://google.github.io/styleguide/javaguide.html). Our
build automatically will provide warnings for simple style issues.
We also follow these project-specific guidelines:
### Javadoc
* All public classes and their public and protected methods MUST have javadoc.
It MUST be complete (all params documented etc.) Everything else
(package-protected classes, private) MAY have javadoc, at the code writer's
whim. It does not have to be complete, and reviewers are not allowed to
require or disallow it.
* There MUST be NO javadoc errors.
* See
[section 7.3.1](https://google.github.io/styleguide/javaguide.html#s7.3.1-javadoc-exception-self-explanatory)
in the guide for exceptions to the Javadoc requirement.
* Reviewers may request documentation for any element that doesn't require
Javadoc, though the style of documentation is up to the author.
* Try to do the least amount of change when modifying existing documentation.
Don't change the style unless you have a good reason.
### AutoValue
* Use [AutoValue](https://github.com/google/auto/tree/master/value), when
possible, for any new value classes. Remember to add package-private
constructors to all AutoValue classes to prevent classes in other packages
from extending them.
## Building instrumentation-java
Run `./gradlew clean assemble check` on OS X or Linux, or run
`gradlew.bat clean assemble check` on Windows. This command performs the same
checks as the continuous integration build.
## Proposing changes
Create a Pull Request with your changes. The continuous integration build will
run the tests and static analysis. It will also check that the pull request
branch has no merge commits. When the changes are accepted, they will be merged
or cherry-picked by an Instrumentation core developer.
|
