Anyone (not just committers) can share contributions to WSO2's open-source software products. Your work will be recognized: if your contribution - feature enhancement, bug fix, or other improvements - is accepted, your name will be included as an author in the official commit logs. Read on for details on how you can contribute.
Note: When you contribute a feature, be sure to include proper documentation as described in Documentation Guidelines.
When contributing to WSO2 code base by way of a patch, make sure you identify the correct Git repository that needs to be forked. For more information on WSO2 Git repositories, see WSO2 GitHub Repositories. If you still are not sure which repository to fork, send an email to dev@wso2.org so that a WSO2 team member can advise you.
You do not need to build any dependencies, as everything you need will be automatically fetched from the Maven repository (Nexus) when you are building the product on your machine. Make sure the build server has an active Internet connection to download dependencies while building.
If you are working with a branch instead of a tag, there is a high possibility that the forked repository may differ from the upstream repository (the remote repository that you forked) because it will likely have changed since you forked it. Therefore, always sync the forked repository with the upstream repository before issuing a pull request to prevent the request from being rejected. (Tags are static by definition, so the files in a tag should not have changed, making this step unnecessary when working with a tag instead of a branch.)
Follow these instructions to contribute to the WSO2 code base. Be sure to follow the WSO2 GitHub Guidelines above.
Fork the respective code base to your Git account.
Clone the code base to your local machine, and then change to the local directory where the code was cloned.
git clone <GITHUB_REPOSITORY_URL>
cd <REPOSITORY_NAME>
For example, if the repository is wso2-synapse:
git clone https://github.com/wso2/wso2-synapse.git
cd wso2-synapse
Set your working directory by doing one of the following:
To work with code on a project that is under development, set your working directory to the appropriate branch using the checkout command as follows:
git checkout <REMOTE_BRANCH>
For example, to work with a branch named refactoring:
git checkout refactoring
To work with code in a project that was already released, set your working directory to the appropriate tag for that release using the checkout command as follows:
git checkout tags/<TAG_NAME> -b <LOCAL_BRANCH>
For example, to work with the v5.1.0 tag, which represents the IS 5.1.0 product release:
git checkout tags/v5.1.0 -b v5.1.0
Tip: To help avoid confusion, set the local branch name to the same name as the remote branch.
Build the product using Maven. For details, see Using Maven to Build WSO2 Products.
If you need to add a new file to the repository:
Add the new file.
git add <FILE_NAME>
For example:
git add mycode.java
Commit the newly added file to your local repository.
git commit -m "<COMMIT_MESSAGE>"
For example:
git commit -m "Add a new file"
If you need to update an existing file in the repository:
Open the file that you want to update and make the necessary changes.
Commit the changes to your local repository.
git commit -m "<COMMIT_MESSAGE>" -a
For example:
git commit -m "Update the clauses in the terms and conditions file" -a
If you are working with a branch instead of a tag, sync the upstream repository with your local branch.
git remote add <REMOTE_NAME> <UPSTREAM_GIT_REPO_URL>
git fetch <REMOTE_NAME>
git merge <REMOTE_NAME/BRANCH_NAME>
For example:
git remote add wso2_upstream
https://github.com/wso2/wso2-synapse.git
git fetch wso2_upstream
git merge wso2_upstream/refactoring
Push the changes to your own Git repository.
git push
Send a Git pull request to the WSO2 Git repository.
Your pull request will be authorized after it has been reviewed by the team lead, release manager, or responsible person for the corresponding Git repository.