How to set and get the environment variables with nodejs

Using nodejs as alternative to bash scripting, It may be useful to know the environment variable management.

Get an environment variable:

 var value_variable = process.env.<variable_name>

Example:

 var java_home = process.env.JAVA_HOME;
 console.log("JAVA HOME: " + java_home);

Output:

 JAVA HOME: /opt/jdk1.6

Set an environment variable:

 process.env['VAR'] = "value";

Example:

 process.env['JAVA_HOME'] = "/opt/jdk1.8";
 var java_home = process.env.JAVA_HOME;
 console.log("JAVA HOME: " + java_home);

Output

 JAVA HOME: /opt/jdk1.8

Creating an efficient branching system - Git Flow and BPF

The best approach is to leave the Master branch as the latest stable version of your repository and develop the branching system around it.

Git Flow [1] and Branch Per Feature (BPF) [2] are two models based on this approach.

Git Flow

In 2010, a Dutch iOS developer, Vincent Driessen, published the article Git flow. In this article, he presents how he sets up his branch model. His branching strategy starts by creating two main branches:

• master
• develop

The master branch is the main branch of the project and will be in the ready-for-production state. They are on the remote repository (origin).
So, whenever you clone the repository on the master branch, you will have the last stable version of the project, which is very important.

The develop branch reflects all the new features for the next release. When the code inside the develop branch is stable (this means that you have done all changes for the next releases and tested it), you reach the stable point on the develop branch. Then, you can merge the develop branch into Master.


Around these two branches, Vincent Driessen also used other branches that can be categorized into three types:

• Feature branches
• Release branches
• Hotfix branches 

Feature branches

A feature branch is named based on what your feature is about and will exist as long as the feature is in development. 

Feature branches only exist in local developer repositories; do not push them on the remote repository. 

When your feature is ready, you can merge your branch feature to develop and delete the branch.
Execute the following steps:

1. Go back to the develop branch;
2. Merge the branch to develop by creating a new commit object;
3. Delete the branch (the branch explains a feature that is now part of the develop branch, so there is no reason to keep it);
4. Push your changes on the remote dev repository.

The steps described above can be made with the following git commands:

# step 1
$ git checkout develop
# step 2
$ git merge --no-ff featureBranch
# step 3
$ git branch -d featureBranch
# step 4
$ git push origin develop 

Release branches

You will use the release branch to update your code for minor changes between two big releases. It's named the version number of the project.
At this point, an example will be necessary to explain the process. Let's imagine that we released our website and it is tagged as Version 1.0. We are working on the next big release that will include a blog. While developing your next great feature on a feature branch called "blog", you have a minor bug on production. So, we create a release branch from the dev branch, which we will name "release-1.1":

$ git checkout -b release/1.1 develop

We can fix this bug, but before releasing it, there is a tricky part. Fortunately, this is easy to understand.
First, you have to merge this branch release into master:

$ git checkout master
$ git merge --no-ff release/1.1

Then, you can tag your project to the new release version:

$ git tag -a 1.1

You will probably notice that your dev branch didn't include the changes!
To fix this, you have to merge it into the dev:

$ git checkout develop
$ git merge --no-ff release/1.1 

When it's done, delete the release branch:

$ git branch -d release/1.1

Hotfix branches

These kinds of branches are very similar to release branches. It will respond to fixing a critical bug on production.
The goal is to quickly fix a bug while the other team members can work on their features.
For example, your website is tagged as 1.1, and you are still developing the blog feature on the blog branch. You find a huge bug on the slider inside the main page, so you work on the release branch to fix it as soon as possible.
Create a hotfix branch named:

$ git checkout -b hotfix/1.1.1 master

Fix the bug and merge it to master (after a commit, of course):

$ git checkout master
$ git merge --no-ff hotfix/1.1.1
$ git tag -a 1.1.1

Similarly, like the release branch, merge the hotfix branch into the current release branch (if it exists) or dev branch. Then delete it:

$ git checkout develop
$ git merge --no-ff hotfix/1.1.1
$ git branch -d hotfix/1.1.1

Branch Per Feature (BPF)

As mentioned earlier, Git flow might suit your project when you use a GitHub project, but the is not always the case. 

This model was described by Adam Dymitruk in 2012. He tried to combine the power of Git with Continuous Integration.

He gave some tips for a more efficient branching strategy:

• Divide your project into several sprints. 
• For each sprint, there are several features to develop. 
• The features should be small. Develop a small part of the feature, and for each of them, create a dedicated feature branch. So, there will be a lot of branches with few commits in it. 
• Merge your branch to the dev branch when it's ready. 
• Use a Continuous Integration tool on a Quality Assurance branch so that you will be notified sooner when something is wrong on your feature. 
• When it passes the tests, your QA branch is merged into master and you just have to tag the new version.

Ideally every time you start a sprint, create the feature branches and QA.
The aim of this strategy is:

• All your work is split under feature branches.
• All feature branches start from master (from the last release). When you start a sprint, you create your feature branches at the same time.
• Test your code sooner.

The QA branch is like the develop branch from Git flow; you shouldn't deploy it, but you have to recreate it on every release.

Links:

[1] Git Flow: http://nvie.com/posts/a-successful-git-branching-model/
[2] Branch Per Feature: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Create and using a Git repo into a SVN environment

If you want to use Git as your versioning system, you shouldn't only migrate every repository from SVN to Git, but you should also use Git locally. The Git-svn command will help you do this. It so happens that your team doesn't want to change its versioning system, or a project is way too big to migrate on a new versioning system. So, Git has a solution for you; how about using Git features without anyone knowing or caring?

The following diagram explains how to use Git inside an SVN environment. When executing a Git command, the SVN environment will not notice it because the Git-svn command will convert all your commands.

Setting up your repository

You assume that you already have an SVN repository and you want to use Git locally. As a first step, clone the SVN repository using this command:

$ git svn clone -s http://mysvnrepo/svn/myproject myproject_gitsvn_local

The -s option stands for standard layout, which means that your subversion layout has three directories (trunk, branches, and tags). You can, of course, forget this option if your repository does not have a standard layout.
This creates a Git repository under the myproject_gitsvn_local directory that is mapped to the trunk folder of your subversion repository.
As Git doesn't track empty directories, the empty directories under the trunk won't appear inside your Git repository.
Sometimes you might have to clone a big repository. In this case, checking out the commit history will be lengthy because the repository is too big. There is a way to clone it without waiting for a long time. You can do this by cloning the repository with the earlier version of the repository:

$ git svn clone -s -r625:HEAD http://mysvnrepo/svn/myproject myproject_gitsvn_local

There is one last thing to set up. Every file ignored by SVN has to be ignored by Git too. To do this, you have to transfer them into the .gitignore file by using this:

$ git svn show-ignore > .gitignore

There is an alternative method that uses the update-index command:

$ git update-index --assume-unchanged filesToIgnore

Working with Git SVN

Once your repository is ready, you can work on it and start executing Git commands as we saw earlier. Of course, there are some commands to execute when you want to push or pull from the SVN repository. When you want to update your local Git repository, just type this:

$ git svn rebase

To commit back to SVN, use the following command:

$ git svn dcommit

Sooner or later, you will add the .svn folder to the staging area in Git. Hopefully, there is a way to delete it:

$ git status -s | grep .svn | awk "'print $3'} | xargs git rm -cached

Managing Git submodules

A git submodule is helpful for a project that requires dependency on another project. For example, this can be a library that was developed by you or another team. It can be hard to manage when the library is updated and you made some custom code inside your project.

Git handles this by using submodules. It allows you to manage a Git repository as a subfolder of another Git repository, which in turn lets you clone a repository isolated from the commits of the current repository.

The following points will be illustrated in below:

• Adding a submodule.
• Cloning a project with submodules.
• Removing a submodule.
• Using a subtree instead of a submodule.
• Adding a subproject with a subtree.
• Contributing on a subtree.

Adding a submodule

Let's imagine you want to add the "myutil" library that helps you development of your feature. The first thing to do is to clone the library's Git repository inside your subfolder:

$ git submodule add https://mygitserver/scm/myutil.git myutil

You now have the myutil project inside the myutil folder.
You can do everything you want inside it, such as add modifications, change the remote repository, push your changes in the remote repository, and so on.
While you add the Git submodule, Git adds two files, myutil and .gitmodules.
Let's see this with the git status command:

$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>…" to unstage)
# new file: .gitmodules
# new file: myutil

Git sees the myutil folder as a submodule, so it won't track the changes if you're not in this folder. An important fact is that Git saves this addition as a nonregular commit of this repository, so if someone clones your website, Git can recreate the same environment.

Cloning a project with submodules

If you clone a project using submodules Git will add all files other than the submodule files:

$ git clone https://mygitserver/scm/myproject.git
$ ls
myfile.txt myutil
$ cd myutil
$ ls
$

The myutil folder is created, but it is empty. You will have to execute these two commands to initialize the import submodule:

$ git submodule init
$ git submodule update

Your repository is now up to date. Using submodules can be interesting if you want to separate and isolate some parts of your code.
If you execute a git pull command on your project, you will not have the last version of the submodule. To do this, you have to execute git submodule update every time you want to update your submodule.

Removing a submodule

To remove a submodule from your project, you have to execute these steps:

1. Delete the lines of the submodule from the .gitmodules file.
2. Delete the submodule part from .git/config.
3. Delete the submodule from Git by executing this command:

   $ git rm -cached submodule_path

4. Commit and delete the untracked files.

Using a subtree instead of a submodule

The use of git module is not a best practice because you have to use git submodule update every time, and you will probably forget to do this. The second problem is that Git doesn't really handle merging into a submodule. It detects SHA conflicts, but this is all. It's left to you to find out what should be done.
Thankfully, there is the subtree, which is better in a few ways:

• Easy to manage for light workflow.
• While you clone a superproject, the subproject's code is available too.
• Subtree doesn't use files such as .gitmodules. 
• The most important point is that contents can be modified inside your project without having a copy of the dependency elsewhere.

Git subtree is available since version 1.7.11 of Git delivered in May 2012.

Adding a subproject with a subtree

Firstly, we need to tell Git that we want to include a project as a subtree. We use the git remote command to specify where the remote repository of this subtree is:

$ git remote add –f myutil_remote https://mygitserver/scm/myutil.git

Now, you can add the subtree inside your project using the remote repository:

$ git subtree add --prefix myutil myutil_remote master --squash

This will create the subproject. If you want to update it later, you will have to use the fetch and subtree pull commands:

$ git fetch myutil_remote master
$ git subtree pull myutil myutil_remote master --squash 

Contributing on a subtree

Obviously, you can commit your fixes to the subproject in the local directory, but when you push back upstream, you will have to use another remote repository:

$ git remote add info-myutil https://mygitserver/scm/myutil.git
$ git subtree push --prefix=myutil info-myutil master
Git push using: info-myutil master
Counting objects: 1, done.
Delta compression using up to 1 thread.
Compressing objects: 100% (1/1), done.
Writing objects: 100% (1/1), 170 bytes, done.
Total 1 (delta 1), reused 0 (delta 0)
To https://mygitserver/scm/myutil.git
.................................................... -} master

Git subtree can be an easy way if you have to frequently update your subproject and want to contribute to it with less effort.

JBoss 7.1.1 - java.io.IOException: No space left on device - start failed

 Issue: "java.io.IOException: No space left on device" - JBoss AS 7.1.1

The following exeption could happen during the start of JBoss AS but the file system (or disk partition) is not 100%.  

Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content
        at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:91) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
        ... 5 more
Caused by: java.io.IOException: No space left on device
        at java.io.FileOutputStream.writeBytes(Native Method) [rt.jar:1.6.0_37]
        at java.io.FileOutputStream.write(FileOutputStream.java:282) [rt.jar:1.6.0_37]
        at org.jboss.vfs.VFSUtils.copyStream(VFSUtils.java:442)
        at org.jboss.vfs.VFSUtils.copyStream(VFSUtils.java:422)
        at org.jboss.vfs.VFSUtils.unzip(VFSUtils.java:872)
        at org.jboss.vfs.VFS.mountZipExpanded(VFS.java:536)
        at org.jboss.vfs.VFS.mountZipExpanded(VFS.java:567)

Solution

Remove the temp files:

 $JBOSS_HOME/standalone/tmp/*
 $JBOSS_HOME/standalone/configuration/standalone_xml_history/*

Restart the JBoss AS.

Technology stack

• OS: centos (linux distribution)
• JDK 1.6_x
• JBoss as 7.1.1 

OutOfMemoryError: Increase heap size or lower gwt

Issue

You may encounter the following exception during the maven build of gwt project:

  Compiling 1 permutation
  Compiling permutation 0...
  [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads
  java.lang.OutOfMemoryError: Java heap space
  at java.util.HashMap.resize(HashMap.java:462)
  at java.util.HashMap.addEntry(HashMap.java:755)
  at java.util.HashMap.put(HashMap.java:385)
  at java.util.HashSet.add(HashSet.java:200)
  at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:639)
  at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:438)
  at com.google.gwt.dev.jjs.ast.JParameterRef.traverse(JParameterRef.java:45)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:144)
  at com.google.gwt.dev.jjs.ast.JVisitor.acceptImmutable(JVisitor.java:152)
  at com.google.gwt.dev.jjs.ast.JMethodCall.visitChildren(JMethodCall.java:250)
  at com.google.gwt.dev.jjs.ast.JNewInstance.traverse(JNewInstance.java:84)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:125)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:120)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116)
  at com.google.gwt.dev.jjs.ast.JMethodCall.visitChildren(JMethodCall.java:248)
  at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:241)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:125)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:120)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116)
  at com.google.gwt.dev.jjs.ast.JRunAsync.traverseOnSuccess(JRunAsync.java:101)
  at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer.traverseFromRunAsync(ControlFlowAnalyzer.java:1008)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.computeAllButOneCfas(CodeSplitter.java:716)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.mapExclusiveAtoms(CodeSplitter.java:976)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.determineExclusivity(CodeSplitter.java:757)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.execImpl(CodeSplitter.java:804)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.exec(CodeSplitter.java:259)
  at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.compilePermutation(JavaToJavaScriptCompiler.java:401)
  at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:134)
  at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:195)
  at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:49)
  at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
  at java.lang.Thread.run(Thread.java:662)
          [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...)
       [ERROR] Unrecoverable exception, shutting down
 com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
  at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56)
  at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
  at java.lang.Thread.run(Thread.java:662)
       [ERROR] Not all permutation were compiled , completed (0/1)

Solution 1

To resolve this exception, you can setting, increasing memory values, the "MAVEN_OPTS" as environment variable and retry the maven build.

 MAVEN_OPTS="-Xmx2048m -XX:MaxPermSize=1024m"

Solution 2

Add "extraJvmArgs" tag under configuration tag for gwt-maven-plugin as shown in the next example:

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>gwt-maven-plugin</artifactId>
            <dependencies>
                <dependency>
                    <groupId>com.google.gwt</groupId>
                    <artifactId>gwt-user</artifactId>
                    <version>${gwtVersion}</version>
                </dependency>
                <dependency>
                    <groupId>com.google.gwt</groupId>
                    <artifactId>gwt-dev</artifactId>
                    <version>${gwtVersion}</version>
                </dependency>
                <dependency>
                    <groupId>com.google.gwt</groupId>
                    <artifactId>gwt-servlet</artifactId>
                    <version>${gwtVersion}</version>
                </dependency>
            </dependencies>
            <executions>
                <execution>
                    <phase>prepare-package</phase>
                    <goals>
                        <goal>compile</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
  .....
                <extraJvmArgs>-Xmx896M -Xms896m -XX:PermSize=64m -XX:MaxPermSize=128m</extraJvmArgs>
  .....
            </configuration>
        </plugin>

Technology stack

I used these solutions using:

• java 1.6
• gwt 2.5.1
• maven 3.2.1

How to update a spring xml in war without rebuild

Spring Framework overview

Spring makes it easy to create Java enterprise applications. It provides everything you need to embrace the Java language in an enterprise environment, with support for Groovy and Kotlin as alternative languages on the JVM, and with the flexibility to create many kinds of architectures depending on an application’s needs.

Scenario

Suppose your software uses the spring framework via xml files and a spring xml file is contained in a jar inside the war package in lib folder but this file must be fixed.
It's possible update the file xml without a new build because this file during build stage is not compiled (as all xml files) but just moved into jar.
As first step, we need extract the war package to extract the jar using the command below:

 jar -xvf my-web-app-1.0.war

Now in our file system we have the war package and Its contents.
To simplify I suggest you move the jar to another folder.
Suppose the spring xml inside the jar in META-INF folder. So we reproduce (into path location of jar target) the same folder structure and use the following command:

 jar -uf my-jar-1.0.jar META-INF/my-spring-conf.xml

Now the jar contains the xml file updated.
The last step is the update of war package. Similarly to jar update, into path location of war target, we create a folder with lib name and put the jar updated and use the following command:

 jar -uvf my-web-app-1.0.war lib/my-jar-1.0.jar

Now the war package contains the spring xml with the update ant it is ready for the deploy into the application server.