December 1, 2014

Gradle script to list xml files recursively from specified directory

In the previous article, we saw how to list xml files recursively from the specified directory using Ant Script.

Here is the code snippet to do the same in Gradle script.

import groovy.io.FileType

// defining defaulttasks
defaultTasks 'listfile'

task listfile ()<< {
// user defined property - srcdir
ext.srcdir = "D:\Src"
println ' '
}
listfile.doFirst {
    print '-----------------------------------------'
}

listfile << {
def list = []
def dir = new File(listfile.srcdir)
dir.eachFileRecurse (FileType.FILES) { file ->
  if(file.name.endsWith('.xml')) {
    list << file
}
}
println 'List of xml files: \n-----------------------------------------'
list.each {
  println it.path
}
 println '-----------------------------------------'
}

November 30, 2014

Ant Script to list xml files recursively from specified directory

Here is the code-snippet to list the files recursively in the specified directory using <foreach>, <path> &  <fileset>

<project name="ListFilesProject" default="listfiles" basedir=".">
    <description>
           List Files recursively
    </description>
  <!-- set global properties for this build -->
  <property name="src.dir" value="D:\src" />
 
  <target name="listfiles" description="list the files" >
   <echo message="listfiles xml files in the given directory"/>
   <taskdef resource="net/sf/antcontrib/antlib.xml"/>
   <foreach target="list_xml_file" param="xml_File" >
         <path>
             <fileset dir="${src.dir}" casesensitive="yes" includes="**/*.xml" />
         </path>
    </foreach>
  </target>
 
  <target name="list_xml_file">
          <echo message="${xml_File}"/>
  </target>
 
</project


Note:

Usage of <foreach> requires ant-contrib-1.0b2.jar. Download it from http://mirrors.ibiblio.org/maven/ant-contrib/jars/ant-contrib-1.0b2.jar place it under <Ant Installation Dir>\ant\lib

*.xml       ->  lists all the xml files from the specified directory
**/*.xml  - > lists all the xml files from all the sub-directories under specified directory

The * matches all files in the directory while ** matches the all the files in the entire directory tree.

November 9, 2014

BIT Alumnae Grand Reunion @ Bangalore

BIT started taking initiatives to inaugurate Alumnae chapter in different cities to lay a platform for fellow Alumnae to network and I am glad to be nominated as a Secretory for Bangalore Chapter.
Here is the picture from Bangalore Chapter Inauguration and also spoke on my experience from College to Corporate along with our responsibilities of  giving back to the family, environment, society & college.

Proud to be a BITian! and this is my first non-techical lecture :) 




The central theme of the talk:


“Return Gift”
Parents with school going kids might be familiar with the term and how do we relate that to ourselves..
We are indebted to many people in our life like our family members, our college, mother earth, society etc. on various grounds. By all means we continue to support our family but now it’s our turn to pause, turn back and see, how we can pay back. 
1.       Giving back to the earth:
Let’s preserve the natural resources for our own kith n kin and set an example for our next generation. This will imbibe the principals of conservation to our kids.

2.       Giving back to the society:
We can certainly associate ourselves with one of the trust worthy NGOs to lend a helping hand to the needy.
Two of the BIT Alumni – 1st batch textile students – Murugesh & Rajkumar have formed a group named SWASAM in the year April 2009 with our college mates and their colleagues contributing only 100/- per month and these two persons have been instrumental in routing that money to couple of ashrams in Avinashi, Coimbatore & Pollachi. Now there are 177 members in the group and in the past 6 years, these two people have never missed or delayed to send even a single monthly report. That’s the power of the Alumni & the power of networking. 
So it doesn’t mean that some of you should coin an impressive name like SWASAM and start collecting moneyJ. It is just an example and there are ‘n’ no. of ways to give back to the society.

3.       Giving back to the college:
I personally feel there is a Void in the path from College to Corporate i.e. the transition of a student to an employee or an entrepreneur. Alumni can play a vital Role to mend the gap
·         Emphasising the value of Communication & Presentation Skills, creating an awareness on corporate Etiquette etc. 
College authorities have been doing this but when we talk, the impact & influence will be manifold.
·         We can be a mentor for a student
·         And even committing yourselves for a “Guest Lecture”.
For various reasons, you may not be able to travel down to the college but the technology advancements like video conferencing can tie the knot to mend the gap.

I would like to end with a note from The Alchemist by Paulo Coelho "When you wanted to achieve something, the whole world conspires to help you achieve the same".

Wish you all a very great success in life.


Recordinghttps://www.youtube.com/watch?v=kgUrYYqc59o from 16th to 25th minute.


October 20, 2014

JENKINS ISSUE: Illegal Argument exception

This article talks about Illegal Argument Exception occuring in Jenkins v1.559 during build time.

After migrating from SVN to Git, java.lang.IllegalArgumentException started to occur atleast couple of times a week on daily build, while checking out the source code. Re-starting the Jenkins Slave on the build server, helped us to go past the issue temporarily and root cause exploration continued.

Earlier the assumtions & focus was to rule out options around issues with Git installation / configuration but later narrowed down that the incorrect version of Jenkins Slave installed was the causing IllegalArgumentException.

Solution:
Updating the Jenkins slave from v2.2.x to  2.37 resolved the issue.

July 30, 2014

To launch PDF as ReadMe file on the Installation Success using InstallShield



This will guide you to how to open a PDF at the end of the installation if the read me check box is selected by the user. To achieve these are the steps needs to be followed
1.      Registry search for adobe reader location
2.      Create a custom action to launch readme file
3.      Modify the SetupCompleteSucess Dialog
4.      Add some properties to Property Manager

Registry search for adobe reader location
·         Open InstallShield and go to Behavior and Logics & System search
·         Now right click and add a new system search
·         Click and choose for registry entry and enter the following values
o   Registry root: HKEY_LOCAL_MACHINE
o   Registry path: SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe
o   Registry value: path
·         Click next and Store the value in this property, in that field enter ADOBEPATH. Just leave the option "Store the value in the property".

Custom Action
·         Go to custom actions and create "New EXE" -> "Path referencing a directory" and name it as LaunchReadMePDF.
·         Set the "Working Directory" to documents folder path(In my case it is INSTALLDIR).
·         Set the "Filename & Command line" to "[ADOBEPATH]AcroRd32.exe" "[INSTALLDIR]ReadMe.pdf"
·         Set "Return Processing" to "Asynchronous (No wait for completion)"

SetupCompleteSuccess Dialog
·         Go to Dialogs & SetupCompleteSuccess Behavior
·         In the Controls go to OK and add an event and  enter the following
Event = DoAction
Argument = LaunchReadMePDF
Condition = LAUNCHREADME

Property Manager
Go to Property Manager and add the following Properties
·       ·           SHOWLAUNCHREADME and set it to -1
·       ·           READMEFILETOLAUNCHATEND and set to 1

For this process to work Readme.pdf file should be deployed to INSTALLDIR as part of file copy or you can change the path accordingly.

April 22, 2014

First look at Git - A quick refence to git commands!

This article has quick reference to key commands in Git ..

  • A commit in Git records the snapshot of your project. Each commit will have references to previous commits and thus the history is preserved.
    >> git commit

  • Branches in Git are incredibly light weight and are mere references to the commit; there is no storage overhead. Hence Git Enthusiasts chat the mantra, “branch early, and branch often”.
    >> git branch [name]   - create a branch
    >> gti checkout [name] – switch to branch
    >> gti checkout [name]; git commit – switch to branch and commit to the newly created branch

     
  • Merging – is the process of combining work between branches.
    >> git merge [name]  -> merge the branch [name] to the checked out branch

  • Rebasing is the second way of combining work between branches, which essentially takes a set of commits, “copies” them and moves it to selected branch.
    >> git rebase [name] -> rebase the checked out branch to the branch [name]
  • Head is the symbolic name for the currently checked out commit
  • Detaching HEAD just means attaching it to a commit instead of a branch
    >> git checkout master -> HEAD is master branch
    >> git checkout C1   -> Head is commit C1
  • Git Hashes
    Most DVCS tools, including Git, Mercurial, and Veracity, use cryptographic hashes. There are many algorithms for computing Git hash and Git uses
    SHA-1 (Secure Hash Algorithm)
     Git uses hashes in two important ways.
  • When you commit a file into your repository, Git calculates and remembers the hash of the contents of the file. When you later retrieve the file, Git can verify that the hash of the data being retrieved exactly matches the hash that was computed when it was stored. In this fashion, the hash serves as an integrity checksum, ensuring that the data has not been corrupted or altered.

  • Git also uses hash digests as database keys for looking up files and data.
  • Relative Reference
    In Git, each commit is referenced by unique hash and specifying the git by hash is not the most convenient way. Hence we have relative reference, where you start from somewhere memorable like a branch or a commit.
Let’s see how caret (^) & tilde (~) help us achieve that
Use ^ to move upward one character at a time
>> git checkout master^  -> moves the reference (HEAD) to one level up
>> git checkout HEAD^ -> moves the reference to one level up
So at this point, we have moved the reference to two commits up.
Use ~<num> to move number of times upwards
>> git checkout HEAD~
  • Branch forcing
You can reassign a branch a commit with –f (by force) option
>> git branch –f master HEAD~5
  • Reversing Changes in Git
Git Reset   >> git reset HEAD~1 -> moves the head revision one level up on our local repository. However this does not change on the remote branch in DVCS.
Git Revert >> git revert HEAD-> reverse the changes on the local repository and share the changes with others. This creates a new commit whereas git reset does not.
  • Git Cherry-pick
>> git cherry-pick <commit 1> <commit 2> <…>

>> git cherry-pick C3 C4 C8   -> copies the commits C3, C4 & C8 to the checked out branch. Note: each commit may be from same or different branches
  •  Git interactive rebase
Git cherry-pick can be used only when you know git hash (C3, C4 & C8 in the above example). Git interactive rebase comes into picture when you do not know the git hash.
>> git rebase -i  HEAD~4 - -aboveAll  -> once you enter the command, git list the hashes corresponding to 4 revision, which you re-order or remove and proceed.

>> git commit - -amend
  • Git Tags
Git Tags are used to permanently mark historical points (i.e. certain commits like major releases / big merges) in the project history as “milestones” that can be later referenced like a branch. They are ready-only. You cannot checkout from a tag and modify.
>> git tag <tag name> <commit number>

>> git tag v1 c1
  • Git Describe
>> git describe <ref>  -> where ref resolves to a commit, if not specified, git assumes the latest checked out commit or HEAD.
The output of the above command is
<tag>_<numCommits>_g<hash>
Where tag is the closest ancestor tag in history, numCommits is how many commits away that tag is, and <hash> is the hash of the commit being described.                                     
  •  Multiple Parents
Like tilde (~), caret can also have number but this is use to go upwards to parents rather than commits.
>> git checkout master^2

>> git checkout HEAD~; git checkout HEAD^2; git checkout HEAD~2  => can be combined into one command say git checkout HEAD~^2~2
  • Git Remotes
Git Remotes are nothing but copies of your own repository on local computer, which have a bunch of great properties out of which backup, sharing and collaborating are predominant.
Commands to create git remotes:
git clone – Traditional git world, git clone is used to make your own local copy from remote but here we are using it to create remote repository out of your local one.
  •  Git Remote Branches
Remote branches are always displayed in the format <remote name>/<branch name>
When you checkout from Git Remote, git commit will not automatically update the remote branch. Instead git just checkouts the code and creates a detached HEAD for you.
Remote branches reflect the state of the remote repositories since you last talked to those remotes.
  •   Git Fetching
 >> git fetch -> helps you to fetch data from a remote repository which are missing in local repository and updates the <remote name>/master to reflect the changes.
It talks to the remote repository through internet (via protocol like http:// or git://).
It is important to note that Git Fetch does not modify the user’s local copy or working copy (i.e. master).
  •  Git Pulling
>> git pull -> is literally git fetch followed by git merge (example: git fetch; git merge <remote name>/master -> Latest code is fetched from the remote master to <remote name>/master on your local and later merged to local master.
  • Git Pushing
>> git push -> is opposite of git pull, is responsible for uploading your changes to a specified remote and updating that remote to incorporate your new commits. It’s basically a command to publish your work.
git push is literally git fetch followed by git rebase.
  • Diverging History
Here are 3 different ways to update your local repository to update the changes from remote before you push your changes to remote
>> git fetch; git rebase <remote name>/master; git push
>> git fetch; git merge o/master; git push
>> git pull - -rebase  -> shorthand for git pull and rebase (whereas git pull is just shorthand for a fetch and a merge)
>> git pull; git push
  • Why rebase & why not merge while updating the remote?
Rebasing makes your commit tree look very clean since everything is in a straight line, hence some developers prefer rebase.
Where Rebasing modifies the (apparent) history of the commit tree but merge preserves the history, hence some developers prefer merge.
  • Remote Tracking
Remote tracking is property which establishes the connection between your remote branch, <remote name>/remote branch, which is set automatically when you clone the git repository.

By default, when you checkout <remote name>/master, git checks out to a local repository with the same name.
You are free to specify a different name with the following command.
>> git checkout -b NotMaster <remote name>/master -> this creates a new branch NotMaster to track <remote name>/master
>> git checkout -b NotMaster <remote name>/master
>> git branch -u <remote name>/master NotMaster -> git branch –u is to set tracking on remote branch
>> git branch -u <remote name>/master NotMaster; git commit; git push.
  •   Git Push Arguments
>> git push <remote name> <place>
>> git push origin master  -> Go to the branch named "master" in my repository, grab all the commits, and then go to the branch "master" on the remote named "origin." Place whatever commits are missing on that branch and then tell me when you're done.
The above example is where both the source and the destination has the same name. Many a times that can be different as well. <place> will be resolved into <source>:<destination> for different source and destination. This is commonly referred to as a colon refspec. Refspec is just a fancy name for a location that git can figure out
>> git push origin master:newBranch -> If the remote branch does not exist, git will create and move changes from source.
  •  Git Fetch Arguments
Git fetch arguments is similar to Git Push Arguments except we are downloading the changes to local.
>> git fetch origin <source>:<destination>
  • Oddities of <source> in git push, git fetch
>> git push origin :<branch name>
>> git fetch origin :bugFix
 Leaving source blank means, sending nothing. In push sending nothing will delete the destination whereas in fetch, sending nothing will create a new branch.
  •  Git Pull Arguments
>> git pull origin master  -> fetches the commits from origin master and merges it to the currently checkout branch
 The above commands are based on my leanings and understanding from the interactive visual training guide.