maven-jmeter-plugin release
A better JMeter Maven plugin
UPDATE: You can find the information about the JMeter Maven plugin here
Recently my co-worker James suggested we automate our tests on our project using JMeter and gave me his webpage about the trials and tribulations he went through to get it set up. It linked to a wiki page, in which someone had created a JMeter plugin for Maven.
Well awesome, it shouldn’t be too hard to set up. And it wasn’t, I had the JMeter tests up and running in a short amount of time. But one of the problems was that I wanted to set it up in a more generic way so that we could define different parameters on each of the CI environments we ran.
For this task, I first tried using filtering in maven, which I got working. But what you end up with is a JMX file that is basically unusable by default in JMeter. If you ever wanted to run it again standalone in JMeter, you’d have to modify the variables in the JMX file to work correctly. Vice versa, if you set up your test using JMeter, you have to remember to modify it so that the maven variables you need are in the places you need them.
JMeter already has a system in it where you can define variables in the JMX files (and give them defaults, fancy la la!). For example, say you want to define a variable for a host name. Inside your JMeter JMX file, you can do something like this:
<stringProp name="HTTPSampler.domain">${__P(someVariableName, localhost)}</stringProp>
Now, you have defined someVariableName to be a variable within your JMX file. The second value, in this case localhost, is the default if no variable override has been given.
The way to override these variables is with the -J option on the command, in this form:
-JsomeVariableName=yourhost.comand all the variables called someVariableName will have the value yourhost.com.
Now, with the minor modifications I have made to the JMeter Maven plugin, you can now define the values for these variables inside of your pom.xml, like so:
<jmeterUserProperties> <someVariableName>yourhost.com</someVariableName> </jmeterUserProperties>
and it is just the same as using -J on the JMeter command line.
The way we’re actually going to use it is to combine it with maven variables, like so:
<jmeterUserProperties> <someVariableName>${ourhostname}</someVariableName> </jmeterUserProperties>
So now, we can just do:
mvn -Dourhostname=ourspecialhost ...and be able to run site specific JMeter tests with only changing the arguments on the command-line.
I will be putting together a page in the next day or so with all the libraries needed to set this up, similar to the wiki page.
Using Git and Subversion in 5 Easy Steps
I recently wanted to use a distributed version control system to learn and to try it out, since I have been hearing great things about it. The only issue is that my team (and like 1 million other teams universe wide) currently uses Subversion, and trying to get them to switch over would be like trying to punch a redwood down.
But! Not all is lost. You can use git with Subversion. This can give you some of the benefits of using a DVCS without having to change everything you do. I believe you can do this also with Mercurial…I went with git because I had read somewhere it had the best support to working with Subversion. AND RANDOM INTERNET BLOGS ARE ALWAYS RIGHT.
First of all, I will say that I used this as a guide when I was working. It’s a great start to doing this stuff. I’ll also assume you can find and install git on your own, since you’re all-grow’d up now.
Step 1: Creating a local repo
Ok so let’s get started. The first step is to get the subversion library. That webpage I gave you gives you four different ways of doing it, but I decided to go with the fourth option, which is cloning the entire Subversion repository. You can do that by doing:
git svn clone https://svnserver/project/trunk
Now, you should know that this could take a while. You might as well go and eat dinner for the next three days while this completes. Just kidding, this took me about an hour or so while I was working remotely over a VPN, so it’s not so bad. Our project has about 8000 revisions, and about 230 MBs of files.
So you’re probably wondering “But now if I have the whole history, isn’t it going to take like…a bazillion bytes on my disk?” To that I say “Non”…it uses compression, and my git repo ended up being about 1 MB bigger than my subversion one.
Step 2: Create a branch
From there, you can start working in git! The first thing you’ll probably want to do is create a branch:
git branch someNeatoBranchTo change to that branch:
git checkout someNeatoBranchNow you are working on this particular branch. Note you can do this in one step by doing:
git checkout -b someNeatoBranch
which will create it and put you on it to work.
Step 3: Commit locally
Now you can edit the files to your heart’s content. And commit locally as often as you like, by doing
git commit -a
You can commit individual files by specifying them, but -a just grabs them all.
Step 4: Commit back to Subversion
Once you’re ready to commit back into the main Subversion repo, first you need to pull all the changes from there, to make sure there are no conflicts. You can do this by using this command:
git svn rebase
This will pull down the latest code and apply your code on top of it, merging if necessary. Then to commit back to Subversion, you use:
git svn dcommit
And you will notice that your files are committed back to the repo without any more intervention from you! But where are your comments? Well, all the comments from the commits you did locally will be used to commit to Subversion. It will also do that many commits. So if you did 5 different commits locally, it will turn into 5 different Subversion commits. As long as your team members don’t worry about the revision number spirialing up towards the heavens, it should be ok.
Step 5: Brunch!
This is a pretty simple workflow to get you started on using git with Subversion, but it’s not even half the story. There’s so much more powerful stuff with the branching aspect, and I even haven’t tried it yet to share work with my coworkers before commiting to svn (I’m kinda like a git island at the moment). But try it out, and then check out some of the resources below that helped me get started.
Also, you might want to check how my co-worker James one-upped me. He was working on some highly experimental code that he wanted to share with a teammate, and created a true git repo in approximately 8 seconds, from existing code.
Resources
I had to recently send some modified files to someone so that they could take a look at what I was doing. OH NOES! How do I gather them all up at once?
tar cvzf somefile.tar.gz `svn stat | awk '{print "test -f " $2 " && echo " $2}' | bash`
Word.
To break it down:
The svn stat command is getting all the files that have changed obviously.
The awk command its piped to is the real part that’s doing the work. The awk command prints
test -f file && echo file
Pipe that through bash, and you have commands, which essentially will echo the file if the file is a file. Simple? No? I mean, it will not print it out if it’s a directory, so you don’t have to worry about it adding entire directories.
Surround that whole thing in backquotes (that’s the one with the tilde (that’s the one next to the ’1′ key ( I’m not telling you where the ’1′ key is))) and give it as the argument to the tar command.
