Git and Subversion :- New Subversion Branch Created

If you have read any of my previous blog posts before, you know that I am use Git in order to track Subversion repositories. Recently, I had another experience that I had to resolve and I wanted to make sure that I share it with you.

The team decided to cut a branch of the code that I have been tracking. After they did that, I ran git svn fetch. After doing this, Git realized that a new branch was created and it started to search through the subversion repository to pull back any history that it might not have.

This probably is a good idea, if I were tracking the entire Subversion history, but I am not. The result was Git was starting to pull back history that I didn't have in my Git repo, nor history that I wanted. It would have taken hours to pull in that amount of history, and as I mentioned, I was not interested in retaining the whole entire repository.

In order to resolve this, I performed the following command:

git svn fetch -r:HEAD --no-follow-parent

I think that the most important part of this command is the --no-follow-parent. This tells git not to look back in time at the history, and just pull in the information from the specified starting point.

I hope that this helps someone else out there....

Pay it forward.

Git and Subversion :- Bringing others on board...

In the previous post, Pulling a Subversion Repository into Git Locally, I shared the process that I went through in order to pull Subversion into Git so that I can start using Git locally with Subversion as my remote repository. Since that time, I have been trying to figure out the best way to get Git to Subversion repositories set up for others on my team. I have gone through a lot of trial and error and now I believe that I have finally come up with an easy step-by-step solution.

Before I begin, let me first say that you probably want to follow these instructions for two main reasons:

Cloning a Subversion Repository is very time consuming
If you have never cloned a Subversion repository using Git, you will be amazed at how long this process can take (depending on how much history you want in Git). I typically chose 1000 revisions in the past, and that could take up to an hour or more. This is no fault of Git, instead, Subversion is to blame. With this process, only one person has to incur that time investment. Everyone else, can just reap the benefits without the hassle

Fetching too much data
This was the problem that has stumped me for months. While I was able to alleviate the first challenge of the time investment for everyone, I could not figure out why Git was trying to retrieve so much history from Subversion. This amount of history was even earlier than the 1000 revisions of the initial clone. Finally, I figured out that it has to do with a property called branches-maxRev. Through the use of this property, we can make sure that when you perform git svn fetch, that it will not attempt to retrieve any more history than necessary. So, let's get started

By this time, I am already assuming that you have followed the directions from Pulling a Subversion Repository into Git Locally, and you already have a Git repository with the amount of history from Subversion that you desire. From that point:

1. Navigate to your git repo. Not the .git folder, but the folder containing that folder
2. Open your browser to the git svn man page
3. Scroll to the bottom section titled Basic Examples, and look at the third example
4. Locally, start the git daemon server by typing: git daemon. This will start a git server on your local machine that will allow others to pull from you.
5. Follow the instructions from the Basic Example starting with mkdir all the way to the end. Please note that the line that section that says server:/pub/project must be replaced with a valid git url (for instance git://jdcarlflip.blogspot.com/path/to/git/repo)
6. Once you have finished those instructions, in your newly created repo, open the file .git/svn/.metadata
7. Inside of there, you want to put a line under the uuid similar to the following branches-maxRev = 11111 where 11111 is the revision number that you do not want to go past. If you don't know what to put in there, look back at your original repo that you cloned from, and use the same number.
8. After you have done this, type in git svn fetch, and it should not attempt to retrieve any revisions that are older than the ones you have already

If there are any questions, please let me know.....Enjoy.

Nifty little Java trick...

In Java, there are many times when you have to deal with collections.  The code that is required in order to build a collection can be pretty cumbersome and usually follows the following pattern:

List strList = new ArrayList;
strList.add("1");
strList.add("2");
strList.add("3");

This code above can easily be changed to one line of code as such:

List strList = Arrays.asList("1", "2", "3");

I have found this little trick especially useful when writing unit tests.

If you plan on using this test in production level code, then you should be aware that creating a list in this fashion, does not allow for editing the list later. Instead, you should wrap the newly formed list in a constructor like so:

List strList = new ArrayList(Arrays.asList("1", "2", "3"));

Enjoy...

Grand Rapids BarCamp 2009

Grand Rapids Barcamp 2009 starts tonight!!!

Unfortunately, this is going to be the first BarCamp that I will not be attending.  I was really looking forward to going, but I cannot work it into the schedule.  I hope that everyone has a great time tonight and tomorrow....

Object Oriented or Still Procedural Driven?

Well, according to Chris Richardson, I am not the Object Oriented Developer that I thought I was. In his talk at SpringOne 2007, he challenged his audience to question whether they are actually doing OOD (Design / Development) or if they have carried over the habits of Procedural Programming into the Java language.

I must admit, he has made me think. Many of the points in his article reflect the types of projects that I have been on - heavy service objects full of business logic while the domain objects are basically reduced to Value Objects / Entities to persist without any business logic being in them. His argument is that this is fundamentally procedural programming brought into an Object Oriented programming language. Instead, we should have the business logic contained within the domain model (which includes both business logic and state) and the service objects that use them are a thin layer around the domain model that clients delegate to.

Overall, I think that this may be a "purist" position on OOD, and I am suspect of the claims of ease of maintainability and supportability are really true. Of course, I am speaking from the position of not having any experience with this style of programming - but I am very curious about it. Ultimately, I do believe that he is promoting the Domain Driven Design approach to software. Does anyone have any experience with Domain Driven Design? Can anyone vouch for this style of programming?

SpringFramework Nugget...

Recently we were dealing with an issue in a Spring based application that was causing us some real problems. We had an integration test that we were using to perform some black box testing. Unfortunately, we were getting test failures because the unexpected state of the springletons (not true singletons, but through the use of spring, they act as singletons). When running a subset of our tests individually, they had no problem. However, when ran in a suite, those same tests that succeeded on their own, now failed.

After some digging, we found that a test that was running earlier was putting the springletons, in an unexpected state, affecting the remaining tests. In order to resolve this issue, we used the setDirty() (See section 8.3.1) on our integration tests to make sure that Spring would reload the objects anew.

I hope this little nugget of information helps someone else out there...

Model View Presenter

For those of you that did not come to the last Perl User Group meeting, you missed a great presentation which prompted a wonderful discussion on the Model-View-Presenter Pattern (MVP). Primarily being a J2EE developer and with many years of experience with the Struts Framework, I am very familiar with the Model-View-Controller (MVC). I was very interested, however, in this MVP pattern. This is mostly due to the thick client application development that I have been doing lately.

During the meeting, a lot of questions were raised regarding this pattern, and Jason Porrit was very patient with all of us (touche'). After the meeting, I decided to do a little more investigation, and found the following:

Martin Fowler Retires Model View Presenter Pattern

Yes. Believe it or not, this pattern has been retired by Martin Fowler. Well, I don't know if retired is the correct 'r'-word. Maybe it should say 'R'efactored instead. He has split up the pattern into the Supervising Controller and the Passive View. After reading both of the patterns, they sound very similar in detail and in practice. In the Passive View you put all of the widget population logic into the Presenter. All logic is pushed on the Presenter including the population of text fields or any other widgets available on the View. In the Supervising Controller, you push most of the logic onto the Presenter, but leave some of the logic of populating widgets in the View. Martin states:

"...the essence of a good Supervising Controller is to do as little as possible. Let the view handle as much as possible and only step in when there's more complex logic involved."

Atomic Object Presenter First
On a related note, Atomic Object also has their own variation of the MVP Design pattern called Presenter First (PF). After reading an article from Better Software magazine (referenced from their PF resources), I find this design pattern very attractive as well. What most attracts me is the concept of linking different PF triads in order to orchestrate behavior and a process. Please refer tot he Better Software article for more information on this.

Overall, I owe a big thanks to Jason for inspiring me to learn more about this design pattern. I look forward to hearing him present in the future.

CXF 2.0 Released...

At long last, I am very pleased to share in the celebration on the release of Apache CXF. Apache CXF is the culmination of two seperate projects: Iona Celtix and the open source tool XFire hosted at Codehaus, both serving the SOA community.

I have been using XFire on a number of contract projects lately, and I have found the product to be very easy to use and extremely reliable. Fellow blogger, netzooid, goes into more detail of what XFire fans can benefit from with this rebranding and stable release.

Congratulations once again to the entire team.

Eclipse RCP Presentation

I am just completing a tour where I presented Eclipse SWT / JFace and RCP to both the Grand Rapids Java User Group (GRJUG), and the Ann Arbor Java User Group (AAJUG).There are a few items that I am going to change in the content, but overall, the impression the audience gave me was that they were pleased.

I have been fascinated with Eclipse and Eclipse RCP for many years now, but never really had an opportunity to learn more about it. At one point, I tried to teach myself the framework for a contract, but was intimidated and decided to put it on the shelf for later. (For that contract, I just used SWT directly instead of using the Rich Client Platform.) After recently attending a training session on Eclipse RCP, I have found new confidence in the technology, and I am looking for opportunities to gain more experience.

Are you currently doing thick client application development? If so, what kind of technologies are you using? Are you using a Rich Client Platform? Eclipse or Netbeans or other???

Classicist or Mockist Test Driven Developer

I just read an interesting article titled "Mocks Aren't Stubs", by Martin Fowler. In this article, he explains the difference between a Classicist and Mockist TDDer (Test Driven Developer). After reading the article, I started to reflect on the TDDer style I have been practicing and if I needed to reevaluate my strategy.

When I first started practicing TDD, I didn't use Mock objects. Instead, I relied heavily on Dummies and Stubs. If I was unit testing object A that collaborated with object B, then I would have a stub implementation of B that had states that could be set. For instance, if I was testing method A.calculatePay(), that called B.getHourlyRate() that returned a Float, then the stub implementation of B would have a method called setHourlyRate() giving me the ability to control what was returned from the B.getHourlyRate() method. This approach did meet my needs, although it really cluttered up my testing package and the stubs soon became very messy. Imagine if B.getHourlyRate() returned a Float but also had the possibility to throw 3 different types of exceptions that should be handled differently in object A. If this was the case, I had a very complicated stub implementation of B in order to control whether to return the Float or throw 1 of the three exceptions. By doing this, I found myself writing more code to control the behavior of the stub implementation rather than testing A.calculatePay().

After I became familiar with mock frameworks, it really simplified my unit tests. Instead of creating a stub implementation of B, and programmatically controlling it's behavior, I leveraged a mock object framework that did most of the work for me. The Tests with Mock Objects portion of Martin Fowler's article shows examples of how this can be accomplished. What I found was an increase in productivity because I was no longer focused on building stub code to handle all of the different cases, but actually working on testing A.calculatePay().

Ultimately, whether you call yourself a Classicist or Mockist TDDer, in my opinion, as long as you are practicing TDD, you are on the right path.

Apache Geronimo First Look...Impressive

I have a tendency to be curious about everything. Software development and design, is no exception. Lately my curiosity has led me to taking a look at Application Integration Solutions.

Examining the experience that I have with various integration techniques, (Socket Layer Communications, Remote Method Invocation, Web Services) I realized that the one that I was missing was Message Driven Beans (MDB). So I decided the other night to give both MDBs and Geronimo a try.

After installing Geronimo I immediately went to their Wiki to learn more about the deployment architecture. I was very surprised to find source code for an MDB, along with step-by-step instructions on how to build and deploy it. I was excited, but I tempered my excitement by recalling all of the other tutorials that I have gone through in the past, that reportedly worked at one point and time, but not when you were running it locally on your machine. Has anyone had this type of experience?

So I took a deep breath, and decided to walk through the tutorial anyways. Imagine my excitement when everything worked perfectly the first time without any problems. In under 20 minutes, I had a fully functional MDB deployed on Geronimo. Instead of wasting precious time, trying to investigate problems with Geronimo or the given source code, I could now start investing time into learning more about MDBs.

Special kudos to Lasantha Ranaweera, who I am assuming is the developer who wrote this great introductory example of working with MDBs, as well as the Wiki editor that put together such a nice tutorial on how to build and deploy this application on Geronimo. With this level of quality in both source code and documentation, I am planning on using Geronimo for all of my JEE adventures of curiousity.