Skip to content

Latest commit

 

History

History
110 lines (68 loc) · 5.38 KB

Contributing.md

File metadata and controls

110 lines (68 loc) · 5.38 KB

Contribution Guide

Please make sure you read and understand this document before starting development on Fuse Tooling as it helps us to merge your pull requests faster and keeps the commit history clean.

Get the code

The easiest way to get started with the code is to create your own fork at github, and then clone your fork:

$ git clone [email protected]:<you>/fuseide.git
$ cd fuseide
$ git remote add upstream git://github.com/fusesource/fuseide.git

At any time, you can pull changes from the upstream and merge them onto your master:

$ git checkout master               # switches to the 'master' branch
$ git pull upstream master          # fetches all 'upstream' changes and merges 'upstream/master' onto your 'master' branch
$ git push origin                   # pushes all the updates to your fork, which should be in-sync with 'upstream'

The general idea is to keep your 'master' branch in-sync with the 'upstream/master'.

Building JBoss Fuse Tooling

To build JBoss Fuse Tooling requires specific versions of Java (1.6+) and +Maven (3.0+). See this link for more information on how to setup, run and configure build.

This command will run the build:

$ mvn clean package

If you just want to check if things compiles/builds you can run:

$ mvn clean package -Dmaven.test.skip=true

But do not push changes without having the new and existing unit tests pass!

Contribute fixes and features

JBoss Fuse Tooling is open source, and we welcome anybody who wants to participate and contribute!

If you want to fix a bug or make any changes, please log an issue in the JBoss Fuse Tooling JIRA describing the bug or new feature and give it a fitting component type. Then we highly recommend making the changes on a topic branch named with the JIRA issue number. For example, this command creates a branch for the FUSETOOLS-1234 issue:

$ git checkout -b fusetools-1234

After you're happy with your changes and a full build (with unit tests) runs successfully, commit your changes on your topic branch (with good comments). Then it's time to check for any recent changes that were made in the official repository:

$ git checkout master               # switches to the 'master' branch
$ git pull upstream master          # fetches all 'upstream' changes and merges 'upstream/master' onto your 'master' branch
$ git checkout fusetools-1234       # switches to your topic branch
$ git rebase upstream master        # reapplies your changes on top of the latest in master
                                      (i.e., the latest from master will be the new base for your changes)

If the pull grabbed a lot of changes, you should rerun your build with tests enabled to make sure your changes are still good.

You can then push your topic branch and its changes into your public fork repository:

$ git push origin fusetools-1234         # pushes your topic branch into your public fork of JBoss Fuse Tooling

And then generate a pull-request where we can review the proposed changes, comment on them, discuss them with you, and if everything is good merge the changes right into the official repository.

Testing the Update Site

If you introduced new dependencies or changed versions it is always a good idea to check if the update site still contains everything needed to install successfully. To test the update site contents here's what to do:

  • download and install a plain vanilla Eclipse Kepler, Luna or whatever version used currently
  • run this vanilla Eclipse
  • in Eclipse choose Install new software, then Add to add a new update site
  • choose Local in the following dialog and set the location to file:///site/target/repository
  • close the dialog with OK and then select the new added update site from the drop down box
  • then in the tree below check all the JBoss Fuse Tooling entries
  • hit Next to install the software
  • if all is fine it should install without errors, otherwise it will point you to the problem when you examine the details

Code generation

IMPORTANT:

This step is only required if the Apache Camel model, the documentation or used archetypes and xml catalogs changed! Usually thats the case if the underlying Apache Camel version changed.

How to generate model classes

From the fuseide directory type:

cd tools/ide-codegen
mvn compile exec:java

The generator then runs and updates the sources. Don't forget to commit and push the regenerated source files.

How to generate archetypes and latest XSDs

From the fuseide directory type:

cd tools/ide-buildtools
mvn compile exec:java

Be sure to have the file

<userhome>/.repo.fusesource.com.properties

which should contain the credentials for the FuseSource Nexus EA repository like

username=<your login>
password=<your password>

Without this file the build will not work!

Changing versions before / after a release

There is a bash script called changeVersion.sh in the root folder of the project. You can use that for changing the bundle and maven versions in an easy way.

Invocation:

./changeVersion.sh <oldVersion> <newVersion>

Example:

./changeVersion.sh 7.3.0-SNAPSHOT 7.3.0