The POM (Project Object Model) defines the principal characteristics of the project (groupID, artifact name, version, type), it’s dependencies, a set of properties and any plugins required to correctly build the source code. In the case of WSO2 products, this root pom.xml will contain mostly dependencies (3rd party or other WSO2 artifacts/projects).
Identifying which component you need to modify is an exercise in debugging, code analysis and troubleshooting which will be the topic of a later blog. For now, let’s assume we have identified the required component as being the WSO2 version of the Axis2 engine. This component is listed in the pom.xml under its dependencies:
<dependency>
<groupId>org.apache.axis2.wso2</groupId>
<artifactId>axis2</artifactId>
<version>${axis2.wso2.version}</version>
</dependency>
The version number is a variable placeholder that links back to the properties listed in the same (or in the parent) pom.xml:
<axis2.wso2.version>1.6.1-wso2v23</axis2.wso2.version>
With this information we can search the WSO2 official GitHub account for the correct repository to clone: axis2, this gives us two options of which we want wso2-axis2 (https://github.com/wso2/wso2-axis2). Once cloned it’s crucial that we use the correct version. Typically, these repositories have multiple versions in them and we need to work with the specific version declared on the product (v1.6.1-wso2v23). Each release version is tagged and it’s to the tags that we must look. Not to be confused with the branches which might have the same and/or similar names it’s the Tagged commit that holds the correct code version. Typically, after a repository clone we will be at the HEAD commit of the master branch. To change the repository to the correct commit, enter the command:
> git checkout tags/v1.6.1-wso2v23 -b v1.6.1-wso2v23-custom
The above command will checkout the desired version and create a new local branch with the given name. At this point you might want to do some Git administration (setting up your own remotes & removing the official GitHub repository so that you do not try to push your custom code to the official repository).
Another alternative to find the source code for a specific artifact would be to search for it in WSO2’s Nexus.
Here you can enter the artifact’s name and you will be shown a list of all the different available versions of that specific artifact. You can directly download the source code directly for most of the listed artifacts.
Once you make the necessary code changes, assign your code a new version by changing the project’s pom.xml and build it, for example:
<modelVersion>4.0.0</modelVersion>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2</artifactId>
<version>1.6.1-wso2v23-custom</version>
This will create a new, modified version of the axis2 component and install it on your local maven repository. If you are doing team development, it’s advisable to setup a central nexus server to hold these artifacts so others have access to your custom code.
The last step in building a customized WSO2 product would be to go back to the product repository and updating its pom.xml to use your custom version of the component instead of the original one by changing the property field to:
<axis2.wso2.version>1.6.1-wso2v23-custom</axis2.wso2.version>
It should be noted that if you need to make changes to a dependency further down the dependency chain you must rebuild all the components from the lowest layer all the way up to the main product, changing and applying new version numbers on each step along the way.
Since the build process already takes quite a while to go through all the dependencies and components it might be desirable to skip tests if you are confident that your changes will not break the code or introduce bugs. You can do this by adding a command like argument to the maven build command:
> mvn clean install -Dmaven.test.skip=true
The above command should run the whole build process start to finish, but occasionally there might be issues with older/newer versions of the JDK used for building the source. WSO2 has a big open source community and typically these issues will have already been detected and documented by the community in WSO2’s GitHub repository. If you encounter such issues your first action should be to search there for an open issue.
If you have any questions or comments, feel free to fill out the form below. I will be happy to answer them!
