Structure of WSO2 code repository

This blog post targets explaining the structure of WSO2 code repository used until release of WSO2 carbon 4.2.0 release. Until carbon 4.2.0 release, WSO2 maintained code repository [1] based on svn.

Carbon code repository is consist of 3 spaces named,
  1. orbit
  2. kernel
  3. platform

Orbit

Orbit space [2] contains 3rd party libraries that are not maintained by WSO2, but are used by WSO2 products in operations.

Kernel

Kernel space [3] builds the base of all WSO2 products, WSO2 carbon server [4]. All other WSO2 products are produced by adding some specific functionality to generic WSO2 carbon server. Kernel space contains generic functionality shared by all WSO2 products such as caching, clustering, management console UI and 3rd party libraries that are necessary to support these generic functionalities.

Unlike 3rd party libraries included in orbit space these 3rd party libraries are maintained by WSO2. Therefore these 3rd party libraries have two part version numbers like X.Y.Z-wso2vN. First part this version number  (X.Y.Z) refers to the version number of 3rd party released code that WSO2 used to make changes. "N" in the second part of the version number (wso2vN) refers to version of the code changed by WSO2. For example 1.6.1-wso2v10 of the axis2 pom.xml file [5] in carbon 4.2.0 release means, base code for this release is taken from axis2, 1.6.1 release and this is the 10th version release with WSO2 code changes.

You can find more details about kernel building process by reading "WSO2 carbon building process"[6] blog post.

Platform

Platform space [7] contains implementations of specific functionality that can be added to generic carbon server to perform some special tasks and 3rd party libraries necessary for these specific operations. Code for these 3rd party libaries are maintained by WSO2 and version numbering of these 3rd party sources follow the same pattern used in kernel space.

Dependencies between code spaces


Orbit, kernel and platform spaces should be built in the mentioned order as later spaces depend on the previous space. Build process of WSO2 carbon is managed using apache maven. User can checkout necessary branch or trunk of needed code repository and build using maven with necessary build phases. Steps to be followed to build WSO2 carbon 4.2.0 code base is explained in "Building from source" page [8].

References

[1] https://svn.wso2.org/repos/wso2/carbon/
[2] https://svn.wso2.org/repos/wso2/carbon/orbit/
[3] https://svn.wso2.org/repos/wso2/carbon/kernel/
[4] http://wso2.com/products/carbon/
[5] https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.2.0/dependencies/axis2/1.6.1-wso2v10/pom.xml
[6] http://sameerak-blog.blogspot.com/2015/05/wso2-carbon.html
[7] https://svn.wso2.org/repos/wso2/carbon/platform/
[8] https://docs.wso2.com/display/Carbon420/Building+from+Source

Popular posts from this blog

Running a Docker build agent on Azure Kubernetes Service (AKS)

Image
In this blog post, we are going to run the Docker build agent we created in a previous blog post and run it on Azure Kubernetes Service (AKS).  Prerequisites   1. An Azure DevOps project to connect the AKS hosted build agent. We are going to use the PartsUnlimited project we created in an  earlier post  which meets these criteria. 2. Have Docker installed on your local machine with the ability to create and run Windows containers (Refer to the troubleshooting section on this post for instructions on how to switch). 3. Have Azure CLI installed on your machine. Steps First, we are going to tag the previously created docker build agent with a new tag more suitable for version control, and run it to test operation. 1. To create the docker agent we need to create a new folder and download the following Dockerfile file . ( Link to the normal view ) and start.ps1 file . ( Link to the normal view ) files into a local folder as follows. 2. Then open a Powershell window and change the director
Read more

Azure DevOps Docker DotNet Build Agent

This blog post presents how to create and run a DotNet Azure DevOps pipeline as a Docker container. However, there is a slight problem when running VSTest on this container, and the remedy to this problem is explained in this post. Sources related to this container are located in this GitHub repo . Steps to create, run and test Docker DotNet build agent  Clone this GitHub repo to the local machine. Open a Powershell window and navigate to the folder where the cloned project is located. Execute “ docker build -t dockeragent:latest . ” to create the Docker image. Execute “ docker run -e AZP_URL=<Azure DevOps instance> -e AZP_TOKEN=<PAT token> -e AZP_AGENT_NAME=mydockeragent -e AZP_POOL=<(optional) pool to register the agent under> dockeragent:latest " to run a container based on the created image. Please remember to replace the placeholders with the information related to your Azure DevOps project. In a web browser navigate to the Agents tab under the Agent pool y
Read more

Building Azure DevOps pipelines with a Docker agent

Image
 In this post, we are going to create a Docker image to use as a build agent to Azure DevOps pipelines. The process followed in this blog post is similar to the process followed in the post where we used an Azure VM as the build agent . The difference is, instead of using an Azure VM as an agent, we are going to run a Docker container as an agent on localhost. Prerequisites   1. An Azure DevOps project to build using the Docker agent. We are going to use the PartsUnlimited project we created in an  earlier post  which meets these criteria. 2. Have Docker installed on your local machine with the ability to create and run Windows containers (Refer to the troubleshooting section on how to switch). Steps There are a lot of steps involved in creating a Docker agent and running the build pipeline on it. So I will add subtopics between steps to group steps related to a specific subtask. 1. Creating the Agent pool and generating personal access for the new build agent 1.1. Navigate to  dev.azu
Read more