1<!--- 2 Licensed to the Apache Software Foundation (ASF) under one or more 3 contributor license agreements. See the NOTICE file distributed with 4 this work for additional information regarding copyright ownership. 5 The ASF licenses this file to You under the Apache License, Version 2.0 6 (the "License"); you may not use this file except in compliance with 7 the License. You may obtain a copy of the License at 8 9 http://www.apache.org/licenses/LICENSE-2.0 10 11 Unless required by applicable law or agreed to in writing, software 12 distributed under the License is distributed on an "AS IS" BASIS, 13 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 14 See the License for the specific language governing permissions and 15 limitations under the License. 16--> 17<!--- 18 +======================================================================+ 19 |**** ****| 20 |**** THIS FILE IS GENERATED BY THE COMMONS BUILD PLUGIN ****| 21 |**** DO NOT EDIT DIRECTLY ****| 22 |**** ****| 23 +======================================================================+ 24 | TEMPLATE FILE: contributing-md-template.md | 25 | commons-build-plugin/trunk/src/main/resources/commons-xdoc-templates | 26 +======================================================================+ 27 | | 28 | 1) Re-generate using: mvn commons:contributing-md | 29 | | 30 | 2) Set the following properties in the component's pom: | 31 | - commons.jira.id (required, alphabetic, upper case) | 32 | | 33 | 3) Example Properties | 34 | | 35 | <properties> | 36 | <commons.jira.id>MATH</commons.jira.id> | 37 | </properties> | 38 | | 39 +======================================================================+ 40---> 41Contributing to Apache Commons BCEL 42====================== 43 44You have found a bug or you have an idea for a cool new feature? Contributing code is a great way to give something back to 45the open source community. Before you dig right into the code there are a few guidelines that we need contributors to 46follow so that we can have a chance of keeping on top of things. 47 48Getting Started 49--------------- 50 51+ Make sure you have a [JIRA account](https://issues.apache.org/jira/). 52+ Make sure you have a [GitHub account](https://github.com/signup/free). 53+ If you're planning to implement a new feature it makes sense to discuss you're changes on the [dev list](https://commons.apache.org/mail-lists.html) first. This way you can make sure you're not wasting your time on something that isn't considered to be in Apache Commons BCEL's scope. 54+ Submit a [Jira Ticket][jira] for your issue, assuming one does not already exist. 55 + Clearly describe the issue including steps to reproduce when it is a bug. 56 + Make sure you fill in the earliest version that you know has the issue. 57+ Find the corresponding [repository on GitHub](https://github.com/apache/?query=commons-), 58[fork](https://help.github.com/articles/fork-a-repo/) and check out your forked repository. 59 60Making Changes 61-------------- 62 63+ Create a _topic branch_ for your isolated work. 64 * Usually you should base your branch on the `master` or `trunk` branch. 65 * A good topic branch name can be the JIRA bug id plus a keyword, e.g. `BCEL-123-InputStream`. 66 * If you have submitted multiple JIRA issues, try to maintain separate branches and pull requests. 67+ Make commits of logical units. 68 * Make sure your commit messages are meaningful and in the proper format. Your commit message should contain the key of the JIRA issue. 69 * e.g. `BCEL-123: Close input stream earlier` 70+ Respect the original code style: 71 + Only use spaces for indentation. 72 + Create minimal diffs - disable _On Save_ actions like _Reformat Source Code_ or _Organize Imports_. If you feel the source code should be reformatted create a separate PR for this change first. 73 + Check for unnecessary whitespace with `git diff` -- check before committing. 74+ Make sure you have added the necessary tests for your changes, typically in `src/test/java`. 75+ Run all the tests with `mvn clean verify` to assure nothing else was accidentally broken. 76 77Making Trivial Changes 78---------------------- 79 80The JIRA tickets are used to generate the changelog for the next release. 81 82For changes of a trivial nature to comments and documentation, it is not always necessary to create a new ticket in JIRA. 83In this case, it is appropriate to start the first line of a commit with '(doc)' instead of a ticket number. 84 85 86Submitting Changes 87------------------ 88 89+ Sign and submit the Apache [Contributor License Agreement][cla] if you haven't already. 90 * Note that small patches & typical bug fixes do not require a CLA as 91 clause 5 of the [Apache License](https://www.apache.org/licenses/LICENSE-2.0.html#contributions) 92 covers them. 93+ Push your changes to a topic branch in your fork of the repository. 94+ Submit a _Pull Request_ to the corresponding repository in the `apache` organization. 95 * Verify _Files Changed_ shows only your intended changes and does not 96 include additional files like `target/*.class` 97+ Update your JIRA ticket and include a link to the pull request in the ticket. 98 99If you prefer to not use GitHub, then you can instead use 100`git format-patch` (or `svn diff`) and attach the patch file to the JIRA issue. 101 102 103Additional Resources 104-------------------- 105 106+ [Contributing patches](https://commons.apache.org/patches.html) 107+ [Apache Commons BCEL JIRA project page][jira] 108+ [Contributor License Agreement][cla] 109+ [General GitHub documentation](https://help.github.com/) 110+ [GitHub pull request documentation](https://help.github.com/send-pull-requests/) 111+ [Apache Commons Twitter Account](https://twitter.com/ApacheCommons) 112+ `#apache-commons` IRC channel on `irc.freenode.net` 113 114[cla]:https://www.apache.org/licenses/#clas 115[jira]:https://issues.apache.org/jira/browse/BCEL 116