1. Create a GitHub account if you don't have one already
2. Fork wildfly repository into your account
https://github.com/wildfly/wildfly
3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/wildfly.git Cloning into 'wildfly'... remote: Counting objects: 533023, done. remote: Compressing objects: 100% (170/170), done. remote: Total 533023 (delta 60), reused 0 (delta 0), pack-reused 532777 Receiving objects: 100% (533023/533023), 140.25 MiB | 1.75 MiB/s, done. Resolving deltas: 100% (210143/210143), done. Checking connectivity... done. $ cd wildfly
4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/wildfly/wildfly.git
5. As a precaution, disable merge commits to your master
git config branch.master.mergeoptions --ff-only
6. Use maven (via build.sh or build.bat)
Building WildFly 8 requires Java 8 or newer, make sure you have JAVA_HOME set to point to the JDK8 installation. Build uses Maven 3.
$ ./build.sh ..... [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] WildFly: BOM ..................... SUCCESS [1.834s] [INFO] WildFly: Parent Aggregator ....... SUCCESS [0.022s] [INFO] WildFly: Domain Core ............. SUCCESS [3.051s] [INFO] WildFly: Server Manager .......... SUCCESS [0.204s] [INFO] WildFly: Server .................. SUCCESS [0.283s] [INFO] WildFly: Domain Controller ....... SUCCESS [0.084s] [INFO] WildFly: Process Manager ......... SUCCESS [0.314s] [INFO] WildFly: Remoting ................ SUCCESS [0.390s] [INFO] WildFly: Build ................... SUCCESS [5.696s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------
7. Pulling later updates from upstream
$ git pull --rebase upstream master
From git://github.com/wildfly/wildfly
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
(--rebase will automatically move your local commits, if you have any, on top of the latest branch you pull from, you can leave it off if you do not).
Please note that --rebase is very important if you do have commits. What happens is that when git pull can't fast forward, it does a merge commit, and a merge commit puts the sucked in changes ON TOP of yours whereas a rebase puts them BELOW yours. In other words a merge commit makes the history a graph, and we prefer a cleaner, easier to follow linear history (hence the rebasing). Further once you do a merge commit it will be difficult to rebase the history before that commit (say you want to combine two commits to one later) as described in point 13. Luckily the option set in step 5 will prevent this from happening.
One way to not forget --rebase the rebase option is you may want to create an alias
$ git config --global alias.up "pull --rebase"
and then just use the new alias instead of pull
$ git up upstream master
One last option, which some prefer, is to avoid using pull altogether, and just use fetch + rebase (this is of course more typing)
For some reasons tags are not updated (e.g. not part of an active branch). Update the tags with
$ git fetch --tags upstream
8. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
$ git push Counting objects: 192, done. Delta compression using up to 4 threads. Compressing objects: 100% (44/44), done. Writing objects: 100% (100/100), 10.67 KiB, done. Total 100 (delta 47), reused 100 (delta 47) To git@github.com:[your user]/wildfly.git 3382570..1fa25df master -> master
You might need to say -f to force the changes. Read the note on 12 though before you do it.
If you fetch the tags separate you have to push the tags also
git push --tags
9. Working with WildFly Core
During work on WildFly 9, the WildFly codebase was split into two separate projects -- full WildFly and WildFly Core. The WildFly Core project includes the code for the server kernel, along with a minimal set of extensions that most any distribution based on WildFly kernel technology would want to have (e.g. logging.) The full WildFly project then depends on the maven artifacts produced by WildFly Core and adds in the extensions needed to provide the functionality most users associate with an application server.
The https://github.com/wildfly/wildfly repo mentioned above is for full WildFly. If you want to work on WildFly Core, the information above all applies, except you'll need to fork and clone a different github repo: https://github.com/wildfly/wildfly-core
$ git clone git@github.com:[your user]/wildfly-core.git Cloning into 'wildfly-core'... remote: Counting objects: 533023, done. remote: Compressing objects: 100% (170/170), done. remote: Total 533023 (delta 60), reused 0 (delta 0), pack-reused 532777 Receiving objects: 100% (533023/533023), 140.25 MiB | 1.75 MiB/s, done. Resolving deltas: 100% (210143/210143), done. Checking connectivity... done. $ cd wildfly-core
10. Discuss your planned changes (if you want feedback)
- On mailing list - https://lists.jboss.org/mailman/listinfo/wildfly-dev
- On IRC - irc://irc.freenode.org/wildfly or https://webchat.freenode.net/?channels=wildfly
- On Zulip - https://wildfly.zulipchat.com
11. Make sure there is a JIRA somewhere for the enhancement/fix
https://issues.jboss.org/browse/WFLY (for WildFly full)
https://issues.jboss.org/browse/WFCORE (for WildFly Core)
12. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
13. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'WFLY-XXXX Frunubucate the Fromungulator' git commit -m 'WFLY-YYYY Tripple Performance of Fromungulation' git push origin my_cool_feature
Note that git push references the branch you are pushing and defaults to master, not your working branch.
14. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream git rebase -i upstream/master # if you have conflicts fix them and rerun rebase # The -f, forces the push, alters history, see note below git push -f origin my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to revise the branch history (and thus, they will then need to rebase on top of your branch once you push it out).
15. Get your changes merged into upstream
- Read the documentation to ensure that you follow a good Pull Request Standards WildFly Pull Request Standards and Guidelines
- Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 13.
- Send a github pull request, by clicking the pull request link while in your repo's fork
- An email will automatically be sent to the pull request list (http://lists.jboss.org/pipermail/jbossas-pull-requests)
- As part of the review you may see an automated test run comment on your request.
- After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
- Don't forget to switch back to master and pull the updates
git checkout master git pull --ff-only upstream master
- Update the master branch of your github repository (otherwise you will see a message like 'Your branch is ahead of 'origin/master' by XXX commits.'
if you use 'git status' on your local master branch.git push origin master
Appendix A. Adding a new external dependency
- Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of provided scope).
- Add your dependency to any AS modules that require it, but only with group/artifact.
- Edit build/pom.xml and add your dependency with only group/artifact.
- Create a directory in build/src/modules corresponding to the module's name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
- Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
- Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the module name. The group/artifact listed in the nested maven-resource element(s) refer to the Maven group/artifact name.
- Important: Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
- Important: Do not introduce a dependecy on the "
system" module. If you need access to JDK classes which are not covered by any other dependency, use the "javax.api" module as a dependency.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
Appendix B. Adding a new AS submodule
- Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
- Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do not include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
- Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
- Add the new submodule to the modules section element of the top-level pom.xml
- Add your submodule dependency to any AS modules that require it, but only with group/artifact.
- Edit build/pom.xml and add the new submodule with only group/artifact.
- Create a directory in build/src/main/resources/modules corresponding to the submodule, with a version of "main", like this: "build/src/main/resources/modules/org/jboss/as/new-subsystem/main".
- Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
- Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
Appendix C. Profiling with JProfiler
Performance tuning is an important part of AS7 development. In order to use JProfiler on a standalone AS 7 instance, first you need to add the following to your standalone.conf file:
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=com.jprofiler -agentlib:jprofilerti -Xbootclasspath/a:/path/to/jprofiler/bin/agent.jar"
The "jboss.modules.system.pkgs" property tells JBoss Modules to allow the "com.profiler" classes to be found from any class loader, which is essential to allow the JProfiler agent to run.
It's easiest to then just set up your JProfiler session as "Remote", and start the server and the profiler in any order. That's it!
Appendix D. Importing into Eclipse
The directory "ide-configs/eclipse" contains both formatter and code templates. Use these to pass the CheckStyle enforcer during the build if coding from Eclipse.
Tips & Tricks!
Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash_completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
Partial Builds
It's common when working on a particular module to need to build that module and the overall AS distribution numerous times. Doing a full AS build can be overly time consuming in this situation. The maven rf and pl options can be helpful in limiting the build to a subset of all the AS modules. See this quick introduction to both of these maven switches.
A fairly common thing is to work on a single subsystem, so you need that subsystem built, and to also have the full AS dist rebuilt so the new version of the subsystem's jar ends up in build/target. To do this, for example with the ejb3 subsystem, you would:
mvn install -pl ejb3,build
IDE Integration
Eclipse
Follow the steps mentioned here http://community.jboss.org/wiki/HackingAS7usingEclipse
Checkstyle Errors
If you need to first verify that your changes pass the checkstyle audit, do this first.
mvn checkstyle:checkstyle
Then you can proceed with the build.
Adding Subsystem Scripts
If you have a need to add a script to WildFly, then definitely it should finally land inside bin/util directory. One important thing that you will need to have as part of your subsystem pom is the following plugin.
maven-jar-plugin org.jboss.as.security.vault.VaultTool
Substitute your main class.
How do I ensure that my code does not blow up the testsuite?
First try to run the tests as part of the build before sending a pull request.
$> ./build.sh clean install -DallTests
Sometime there are test failures that are not related to your code changes. Try to discuss this on the mailing list or IRC.
You can get a full run using
$> ./build.sh clean install -DallTests -fae
This additional option will allow the build to continue even when there are test failures. Doing this, you can get a stock of all the test failures and figure out how many are related to your code changes.
Comments