Moving from svn to git :Step 1:Setting up Git on Windows, with TortoiseGit as UI

So, my department is planning on moving from svn to git for version management and we have been instructed to research git and see how it works for us. Spent the day installing Git on my personal laptop and playing with it. Here is my "Git novice" attempt at blogging about my experience.

Btw, I am installing Git on my Windows 8 laptop,

Installing Git

This could not get easier. All I had to do was to follow the steps given in the Git Getting Started Guide

Since I was using windows, I followed the guidebook instructions for windows. Steps were:

- Go https://msysgit.github.com and click on Downloads.

- I downloaded the latest version Git-1.8.4-preview20130916.exe

Ran the exe and the wizard walked me through the process, I left all the default selections intact and Voila!!!, I had git installed.

Here is what the sneaky installer had created the a folder called Git under program files,

here are the contents of the folder

Clicking on Git Bash opened up the Git Bash shell.

Now that I had Git on my laptop, I needed a repository I could work against. I probably could have used one of the gazillion repositories on GitHub, however I decided to create my own.

I signed up on GitHub and created a repository.

I started the git bash and  followed some of the steps mentioned in the First Time Setup chapter of the "Getting Started" guide. I setup the username and email to match the values in my GitHub account, just wanted to keep things simple for my first attempt.

I skipped the rest of the configuration mentioned in the guide.

Cloning the repository

For starters I decided to clone the repository mentioned in the Git Start Up guide

I brought  up the git bash, changed folders to C:\\work and ran

git clone git://github.com/schacon/grit.git

Within a blink of an eye a folder called grit was created under C:\\work

Here is how the git bash looked

And this is how the newly created directory looked:

So what just happened?

Apparently, .git has all the data for the repository pulled down, so that is now my local repository while the working copy is in the grit directory, all ready to roll.

Yay!!! That was simple. Now I was so eager to clone my very own repository. 

So followed the same pattern ie"

git clone git://github.com/<MyGitUserName>/<MyRepositoryName>

Ex: git://github.com/gsmsengupta/mysandbox

Before I knew the repository was downloaded and git was nice enough to let me know that the repository was empty. It was indeed empty. I needed to ato add something.

Adding and Commit files

I created a new file under C:\work\mysandbox and called it SandyBeach.txt

executing git status warned me of the un tracked file:

Next step adding the file to tracked status:

git add SandyBeach.txt

On running git status again, git let me know that a new tracked file has been added and that file has not been commited.

So I ran git commit.

As I had not set up my preferred editor in the 'Git Config' step, running git commit opened a VIM session, I entered some comments and saved the VIM. That completed the commit as shown below.

Push changes to remote repository

I wasn't done yet. I needed to push the changes to the remote repository that I had created on Git Hub.

Here is where I encountered my first road block.

As per the guide, I executed the following command:

git push origin master

However got presented with the following:

fatal: remote error:

  You can't push to git://github.com/gourijamenon/mysandbox.git

  Use https://github.com/gourijamenon/mysandbox.git

Here is a screen shot of the same:

What just happened here???

Did some research on the net and found out that github does not support push over git:// protocol.

So I had to use https as suggested.

The revised command was:

git push  https://github.com/gourijamenon/mysandbox.git

This now asked me for my GitHub username and password, and yay!!!! Pushed the file.

Though I had created a pretty useless text file, I could not be more proud. I had just commited it using git bash.

Installing TortoiseGit

Enough of bash commands, I was so ready for some UI click actions. I am pretty comfortable with TortoiseSVN so naturally gravitated towards TortoiseGit.

This again was very straightforward, visit site TortoiseGit download and install, piece of cake.

I was prompted to restart the laptop which I did. After restart, all my git repos now had the familiar green check and right clicking started giving me the TortoiseGit options. Check out the TortoiseGit website for details.

I added a few new files, right clicking prompted me to add. I could commit the files to the local repository. No problems till now.

I was ready to claim victory when I realized that I had not pushed the changes to GitHub.

So I right clicked and selected Push, here is what I saw:

I clicked OK and got the now familiar  You can't push to git:// use Https:// error

No problem I thought, I know exactly what to do, I need to change to Https protocol.

So I click on the Push, and click the manage button on the resulting screen:

That gave me an option to add the Https Option:

Ohhh...it requires a putty key, now where do I get that. Went back to research mode and came across two very helpful articles:
https://help.github.com/articles/generating-ssh-keys shows how to generate the ssh keys and add it to the repository.
http://olelynge.blogspot.com/2012/04/tortoisegit-and-ssh-keys.html gives step by step instructions on how to get tortoiseGit to use the key to  enable ssl.

So now that I had the Https thingie configured I selected that from remote destination dropdown and proudly clicked okay and guess what....TortoiseGit does not support Https, here is the screen shot of the spectacular crash and burn

Now what??? Dead End??? Not yet.... there is one more protocol I could try. SSH.

Went back to Manage Remote Destination and configured SSH.

URL was sshified as git@github.com:gourijamenon/mysandbox.git
I believe the for ssh access of github the URl pattern is:
git@github.com:<gitusername>/<yourgitrepo>


Here is a screen shot:

Went back, right click-->Push-->Selected remote destination configured to use SSH protocol.

Clicking on Okay prompted me for the key paraphrase:

After I entered the paraphrase...oh the sweet joy ........the changes were pushed to the remote repo.

Maven 101: Day 3 :Compile, Test, Package and Install

 
Goto Prev: Understanding POM

Maven loves its directory structure..:)

Maven is all about standardization, it has a default directory structure and the dudes and dudettes at Maven do insist that we stick with the default/recommended directory structure as much as possible.
Now they have provided a way for us to override it using the project descriptor see Apache Maven Tutorial : Directory structure explanation. I am not even considering going down that route. I am happy with the default and recommended structure.

I plan to go back to inspecting the directory structure after each step ie, compile, test and package.

 

Compile

Finally time to run mvn compile.

Here is how the project looks before I hit mvn compile.

So the structure is 

/namaste/src
/namaste/src/main
/namaste/src/main/java
/namaste/src/test
/namaster/src/test/java

namaste: The project folder
src: This folder contains all the material required for building the project
main: This folder contains the material for the main build artifact
test: This folder contains the material for unit tests
java: You will find this folder under both main and test. Under the java folder we see the package structure. This is the folder where you will place your java files.

/main/java/com/gsm/app contains the class App.java.

This is how App. java looks.

/test/java/com/gsm/app contains the test class AppTest.java. This class implements the JUnit test for App.java.
Here is the screen shot for AppTest.java

Next step mvn compile. 

Now that I have a fully compiled maven project let me inspect the directory structure.

So compiling the project has added the folder target. This folder is a peer to src and created under namaste.

So the location of the folders created after compile is:

/namaste/target
/namaste/target/classes

Under the classes folder we see the project structure and the java class, App.class.

target: This directory holds all the output of the build

Test

Next step, mvn test. This runs the maven test and two new directories get created.

The test classes get compiled and placed under /namaste/target/test-classes.

A test report is created and placed under /namaste/target/surefire-reports.

Package

Next I ran mvn package.

This resulted in the creation of the jar and the maven-archiver folder.

Both these artifacts were created under the /namaste/target folder

Here is a screen shot of the target folder after I ran mvn package.

Under the maven-archiver folder, I spotted a pom.properties file, I am yet to figure out what do with it. Maybe someday I will be mavenlightened enough to know the answer to that, for now moving on.

Install

Ran mvn install and that copied the files to ./m2/repository. It created the following folder structure under ./m2/repository.

/com/gsm/app/namaste/1.0-SNAPSHOT

The 1.0-SNAPSHOT folder contained the following files.

Question: What is a Maven Repository?
 Detailed answer to this question can be found at :Intro to Maven Repos.
However, here is the summary:
There are two types of repositories remote and local. Remote: These are hosted repositories that contain artifacts that need to be shared among various developers. Maven's central repositories are remote repositories that contains the common maven artifacts. Local: which is a copy of your installation, usually lives on your local box and contains artifacts that you downloaded from the remote repositories and the artifacts created by your build effort.

Most corporates have an internal hosted remote repository, this repository has artifacts downloaded from the Maven Central repositories and   artifacts released by the the internal team.
A repo manager is usually used to host such a repository ex. Sonatype Nexus


 Phew !!!! So ready to call it a day.

Goto Prev: Understanding POM

Maven 101: Day 2: Understanding POM

Goto Prev: Day 1: Install and Setup                          Goto : Next: Compile, Test, Pckg,Inst

This is Day 2 of my maven journey. On Day 1, I setup maven on my laptop and created a maven project.

I also tried to understand the basics of the command that I used to create the maven project.

Today I plan to understand the basics of POM.

I am going back to my trusted Apache Maven Tutorial as a guide.

Introduction to POM- Project Object Model

This is an XML file that contains the project and configuration details required by Maven to build the project. You can specify project dependencies, plugins that would be used and information like version, description etc. When we execute a maven goal, Maven looks for the POM in the current directory, it reads the POM to get all required information to execute the goal.

Maven has a default POM, this POM is called the Super POM, all POMs extend the super POM unless explicitly set. The Super POM has meaningful default configurations and these configurations are inherited by the POMs created in a project. Here is a snippet from the Maven 2.1.x super POM, this snippets show the Super POM contains default values for some common directories:

 <directory>${project.basedir}/target</directory>
    <outputDirectory>${project.build.directory}/classes</outputDirectory>
    <finalName>${project.artifactId}-${project.version}</finalName>
    <testOutputDirectory>${project.build.directory}/test-classes</testOutputDirectory>
    <sourceDirectory>${project.basedir}/src/main/java</sourceDirectory>

One good thing about inheriting default is that you only have to specify a handful of things in your project's POM and rely on Super POM for the rest. The minimum required values for a project POM are as follows:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.gsm.app</groupId>
  <artifactId>namaste</artifactId>
  <version>1.0-SNAPSHOT</version>
</project>

project: This is the top level element of all pom.xml files

modelVersion : This is the version of the object model used by this POM. Not something I as a beginner would worry about. I plan to go with what ever the skeleton archetype gives me.

groupId : The unique identifier of the organization that created the project.

artifactId : The unique name of the primary artifact

version : The version of the artifact generated by the project.

This minimal pom does not require you to specify a packaging type, it uses the default value , which would be "jar".

For a project built with the above minimal POM the out put would be a jar file named as follows:

namaste-1.0-SNAPSHOT.jar

Since the above POM does not specify repositories it will download any required files (dependencies)

from the default maven repository http://repo.maven.apache.org/maven2.

It inherits this value from the Super POM.

Parent Project

Please don't quote me on my description of a Parent Project , but from what I gathered. Parent projects can be used at least in these two contexts:

 

Inheritance: If you have several Maven projects with similar configurations, you can pull the similar configurations our and make a parent project. You then specify this common project as the parent project for the rest of your Maven projects and the child projects would inherit all the parent project configurations.

Aggregation: If you have a group of projects that always need to be  built together, you can create a parent project and declare all the required projects as its modules. You then build only the parent project and the rest will get built automatically.

You can use either Inheritance or Aggregation or both as long as :

• Every Child POM has a reference to its Parent POM
• Parent Poms packaging is set set to "pom"
• Parent POM has references to its child modules' directories

So if our project Namaste is now a parent project of project Smile. And the directory structure is:

• Namaste
• pom.xml
• Smile
• pom.xml

Here is how their pom.xml files would look.

Namaste:

*Using Aggregation, ie build Namaste and Smile builds along with it.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.gsm.app</groupId>
  <artifactId>Namaste</artifactId>
  <version>1</version>
  <packaging>pom</packaging>

  <modules>
    <module>../smile</module>
  </modules>
</project>

Smile:
 *Using Inheritance to inherit properties from Namaste

<project>
  <parent>
    <groupId>com.gsm.app</groupId>
    <artifactId>namaste</artifactId>
    <version>1</version>
    <relativePath>../parent/pom.xml</relativePath>
  </parent> 

 <modelVersion>4.0.0</modelVersion>

 <version>1</version> 

 <groupId>com.gsm.app</groupId>

 <artifactId>smile</artifactId>

 </project>

If we want to use the same version number or group ID as the parent, we have the option of leaving that out in the child pom. Thus the child pom will look something like this:

<project>
  <parent>
    <groupId>com.gsm.app</groupId>
    <artifactId>namaste</artifactId>
    <version>1</version>
    <relativePath>../parent/pom.xml</relativePath>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <artifactId>smile</artifactId>
</project>

POM Variables/Properties

You can use predefined or user defined variables, the idea is to specify the value for the variable once and reference it everywhere else.
Any  single valued element in the model can be referenced as a variable. So if you need to access the value of the  groupId you would access it as ${project.groupId}, sourcedirectory would be
${project.build.sourceDirectory}.

You also get ready made variables that you can be used, For ex.
${project.basedir} : gives you the current directory of the project

You can define properties and use them as a variable later in the pom.

 Important point to note is that the variables are processed after inheritance and thus child values will override parent values.

Goto Prev: Day 1: Install and Setup                             Goto : Next: Compile, Test, Package Install                                                                                             

Odds & Ends : Jboss Apps Moving to RAC servers

So we decided to move to the new Oracle RAC servers.

Pre RAC:

We have JEE applications running on Jboss 4.X. These had cute little ds files where we configured the path to the servers as such:

 <xa-datasource-property name="URL">jdbc:oracle:thin:@TheDatabaseDNS:1521:DBServiceString</xa-datasource-property>
 <user-name>SomeUser</user-name>
 <password>SomePass</password>

Post RAC

The xa-datasource property had to be changed to:
<xa-datasource-property name="URL">jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(HOST=DNSToRACHHost1)(PROTOCOL=TCP)(PORT=SomePort)) (ADDRESS =(HOST = DNSToRACHost2)(PROTOCOL  = TCP)(PORT = SomePort))(LOAD_BALANCE = on) (FAILOVER = on) (ENABLE = broken)(CONNECT_DATA=(SERVICE_NAME=SOMESERVICENAME)(SERVER = dedicated) (FAILOVER_MODE = (TYPE = select) (MET OD = basic) (RETRIES = 240) (DELAY = 2))))</xa-datasource-property>


I was not sure this would work as this was nothing like the I had seen till now, but guess what this freaky thing does work.

Check out the following link for more info:
Jboss Oracle Rac config



 

Maven 101: Day 1

Day 1:Get the ball rolling

I have been on Ant for ages, yeah yeah call me a troglodyte. Anyways, we are going to move to maven pretty soon, so thought of dabbling in it and getting familiar. So Maven I choose thee as my first 'learn it yourself' project.

Fun fact: Maven is Yiddish for "One who understands, based on an accumulation of knowledge"

Download and install maven.

This was a breeze. I downloaded maven 3.1.0 onto my brand new Windows 8 laptop.
Followed the steps for Windows given on Apache Maven Install. Doc.

•  Downloaded the maven binary zip from Apache Maven Download  and extracted. 
•  
• I extracted it to a folder call c:\work. This resulted in the following folder structure
• C:\work\apache-maven-3.1.0-bin\ and
  C:\work\apache-maven-3.1.0-bin\apache-maven-3.1.0
• Set the M2 environment variable to :
  C:\work\apache-maven-3.1.0-bin\apache-maven-3.1.0\bin
  
  
• The PATH variable was set to include the M2 variable ie C:\work\apache-maven-3.1.0-bin\apache-maven-3.1.0\bin


• Confirmed that JAVA_HOME was set correctly and that, Java Home was included in Path. Maven is a Java tool so Java needs to be there before you can make any headway with Maven.  In my case JAVA_HOME was set to
  
  
  • C:\Program Files\Java\jdk1.7.0_40
  And the PATH variable included
  • C:\Program Files\Java\jdk1.7.0_40\bin

Now I was ready to try the mvn --version command. So I opened a command window and typed it.
Nothing...happened...:(, mvn not recognized. Tried the age old developer trick, Reboot.
Voila!! mvn is now a recognized cmd. Was the Reboot necessary, dunno for sure.

mvn --version displayed the following:

Declared Victory!!!!
 

Got bored of the mvn --version output in about 30 seconds. Time to move on.

Configuring Maven on my lappy

Went through the following Apache Guide to Configure Maven

I was installing maven on my private laptop, did not want to complicate matters by meddling with the default settings. Maybe later, not now. Did not have any need for configuring HTTP proxy either.

My first Maven Project

Created my first maven project : Namaste

Fun fact: Namaste, derived from Sanskrit "Namaskar", I bow to thee. So yeah, I Indianized the "Hello World"

Here is the command I used.

mvn archetype:generate -DgroupId=com.gsm.app -DartifactId=namaste -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false 

It took like for ages to get this first project created, but the dudes and dudettes at Apache had already warned  about it. They had mentioned that the first time I run this command, maven will download all the required plugins into my local repository. My connection did not time out, but it did take for ever..:)

The project was created successfully and everything, but at this point I did not know how, why or what.
So decided to take the command apart and figure out what each piece did:

archetype:generate

Here "archetype" is Maven Plugin and generate is the goal.

Here is a summary of what I understood. For details check out page : Apache Documentation on Archetypes

Q: What is an archetype? How is it used?

A :  An archetype is nothing but a Maven project template. The archetype author creates an archetype and installs it in the organizations repository. The developers can now use the archetype to generate projects in a consistent fashion. All the developers use the same archetype to create their project structure and thus standardization and best practices implementation is easy to achieve.

Q: What is a maven plugin? What is a goal?

A: Maven is a collection of plugins, where each specific task is implemented as a goal. Thus "archetype" plugin has a goal called "generate". This task implements the generation of a project structure from the archetype. Or in other words a plugin is a collection of related goals

To summarize, when I typed mvn archetype:generate, our ever so wise Maven realized that I meant to use the archetype plugin to generate a project structure.

Fun Fact: Archetype came into English from Greek via Latin. Original Greek word: archetupon,  meaning "first moulded". Plain english meaning of Archetype: A prototype which is copied or emulated by others.

If archetype:generate was the only command typed in by me, maven would ask me a series of questions which would give it enough information to create a project structure. This mode is called the interactive mode.  Details on the interactive mode available at Apache Archetype Plugin Usage

However, I had volunteered all the information before hand, thus had no need for interactive mode. Here is what the rest of the command means:

 -DgroupId

 Here is how I conveyed package structure information to maven. Thus maven now knows that the package structure for my project is com.gsm.app.

-DartifactId

Here is how I conveyed the project name; the artifact name in mavenese (I just made that up)

-DarchetypeArtifactId

 Now that I have told maven what my project should be called and what my package structure should look like, maven would be eager to go ahead create the project structure. But wait, Maven says: you requested a create from an archetype, care to tell me which one? Oh yes -DarchetypeArtifactId is how I let maven know which archetype I would like my project structure to be based on.

Here I chose maven-archetype-quickstart but I could have chosen:

maven-archetype-j2ee-simple : To create a simple J2ee project structure
or maven-archetype-simple : To create a simple maven project.
 Etc. Etc.

You get the idea, the project structure depends on the archetype I choose, thus I choose the archetype with the project structure I want. Simple rule of life, choose that which will give you what you want...:D

-DInteractiveMode

Setting this false, as I have already told maven all it needs to know. I don't need to interact with it further. Setting this to false to keep maven from asking questions.

Final Result: A beautiful Maven project

Just for fun also decided to create one with the j2ee archetype (maven-archetype-j2ee-simple) , decided to name it heyjee ,here is what I got.

Also noticed that running archetype:generate with archetype ids for quick start and the j2ee resulted in these files being downloaded in the maven repository:

Under .m2\repository\org\apache\maven\archetypes
 In found the following archetypes which I believe were downloaded by archetype:generate.

POM : The Project Object Model

Oh, btw, here is the pom.xml for my very first maven project. A dependency to Junit is automatically added to the pom.xml. As per my understanding, this is due to the archetype pom information.

Enough for Day 1 I guess. So signing off.

Goto :Next Day 2: POM explained