More than one year has passed since the last time I did update this category. Anyhow, now back on track again. First cd this year, a must have in my collection, Darkness On The Edge Of Town
rblog
Groovy XML-script that is copying elements and changing attribute values
Based on all the good examples provided by http://groovy.codehaus.org/ I’v managed to create a Groovy script that do
- Find all elements with a name attribute prefixed with ‘DEV_’
- For all found elements, search for element with identical name attribute, but without prefix ‘DEV_’. If element found, remove it
- Create a copy of the element with the ‘DEV_’ prefix and then
- Remove the prefix
- Change the value of the attribute driver
- Add the copy to the list of cars
- Write the updated XML to file
Click more to view the script. Sorry for the limited display of code in my blog.
[teaserbreak]
import groovy.xml.DOMBuilder
import groovy.xml.dom.DOMCategory
import groovy.xml.dom.DOMUtil
class CarExamples {
static def CAR_RECORDS = '''
<records>
<car name='HSV Maloo' make='Holden' year='2006'>
<country>Australia</country>
<record type='speed'>Production Pickup Truck with speed of 271kph</record>
</car>
<car name='P50' make='Peel' year='1962'>
<country>Isle of Man</country>
<record type='size'>Smallest Street-Legal Car at 99cm wide and 59 kg in weight</record>
</car>
<car name='Royale' make='Bugatti' year='1931'>
<country>France</country>
<record type='price'>Most Valuable Car at $15 million</record>
</car>
</records>
'''}
def reader = new StringReader(CarExamples.CAR_RECORDS)
def doc = DOMBuilder.parse(reader)
def records = doc.documentElement
use (DOMCategory) {
println "There are " + records.'*'.size() + " cars defined in the file"
def cars = records.'car'
println "The parent element for cars are " + cars[0].parent().getTagName()
def dev_cars = cars.findAll{it."@name".startsWith("DEV_")}
println " "
dev_cars.each {
def nameofdev = it."@name"
println "Dev name: " + nameofdev
def stringArr = nameofdev.split("DEV_")
def deleteMeName = stringArr[1]
println "Node to remove has name: " + deleteMeName
def deleteRecord = cars.find{ it.'@name' == deleteMeName }
if (null != deleteRecord) {
records.removeChild(deleteRecord)
}
def copyOfDev = it.cloneNode(true)
copyOfDev.setAttribute("name", deleteMeName)
copyOfDev.setAttribute("driver", "racer")
records.appendChild(copyOfDev)
println "\n"
}
}
outputFile = new File("resultfile.xml")
outputFile.write(DOMUtil.serialize(records))
Groovy startup error on Windows
Trying out Groovy on my laptop running Windows XP and kept getting the errormessage:
error: could not find client or server jvm under C:\apps\IBM\SDP\jdk\bin
please check that it is a valid jdk / jre containing the desired type of jvm
JAVA_HOME was set, tried to add the path to the jdk, but still did not help. Then found the solution at …startup-error-….html. Problem was that when issuing the command ‘groovy’ alone it runs the groovy.exe, but the .exe-file does not handle the paths correct for some reason. Running groovy.bat fixes the problem since it handles the paths correctly.
What (REALLY) caused my svn checksum mismatch problem
My previous post with almost the same title “What caused my svn checksum mismatch problem described the root cause to my problem, the perl search/replace command, but I did not understand what why the perl command
perl -pi -e ‘s#ojdbc14_10.2.0.2.jar#ojdbc6_11.1.0.7.0.jar#g’ `find . | grep jdbc.xml`
created the svn mismatch-problem. Thanks to input from Geir Sjurseth we got it figured out. Should really have figured it out by myself, but as many times before, I’m blind to the solution and need someone just to get me to view the problem from another angle, then the solution is as easy to find as the sun on the sky (or whatever analogy would be appropriate).
The problem is the
`find . | grep jdbc.xml`
command which would also change jdbc.xml-files in the .svn-folders. Changing the entire command to for instance
find . -name jdbc.xml -exec perl -pi -e ‘s#ojdbc14_10.2.0.2.jar#ojdbc6_11.1.0.7.0.jar#g’ {} \;
solves the whole problem. -exec is also preferable I’ve learned since that would not create a child process (fork)
Duct tape to the rescue for worn out cycling shoe covers
I’ve used my cycling shoe covers for a year now, or not exactly, since I’m using them only when wearing the winter cycling shoes. Anyhow, they started to get pretty worn out, even tho I’m only walking short distances with them. But whenever such a problem, duct tape to the rescue. So now they should be lasting at least the rest of this season (or at least I hope so because they where expensive…should have lasted longer if you ask me…)
Things to do on a Sunday evening
vi + name of file
shift + G (Goto last line in VI)
o (insert after line in VI)
Middle mouse button (paste in X-WIN32)
ESC (quit insert mode in VI)
shift + ZZ (Save and exit in VI)
…next file, times 140
All because SVN looses control when using perl search/replace
Good thing that I have Spotify and can use the time to get to know “Darkness on the edge of town”
What caused my svn checksum mismatch problem
@Update: See post 2011/01/17/what-really-caused-my-svn-checksum-mismatch-problem for final solution
Have been struggling with svn checksum mismatch problem which is annoying, but no show stopper due to the problem being possible to solve by workarounds as described in this blogpost glob.bushi.net.nz/…/subversion-checksum-mismatch-easy-workaround/
But still, I needed to figure out what the root cause was, and it turned out that the Perl search/replace was the sinner.
Issuing the command
perl -pi -e ‘s#ojdbc14_10.2.0.2.jar#ojdbc6_11.1.0.7.0.jar#g’ `find . | grep jdbc.xml`
then verifying the change by looking at the file using VI. But when issuing
svn status
svn was not able to see any changes. Then I added a xml-comment describing the change, saving and then svn commit I got the checksum error. After doing the workaround and then editing the file all manually, not issuing the Perl-command…voila, no problem. Have not been able yet to figure out why svn don’t like Perl search/replace changing the file…not sure if the -pi -e could be causing the problem, but I’m quite sure it has been accepted before.
The Dirt: Confessions of the World’s Most Notorious Rock Band
My latest book, the story of Mötley Crüe from the early days via their world wide success to their downfall. I expected an endless story of sex, drugs and rock’n roll…and of course it was, but most of all it is a sad story of sex, drugs and rock’n roll. How the enormous amount of girls and dope inflected on their music and friendship. We also get to know their personal life behind the headlines in the newspapers, Vince who drove the car while being drunk and causing the death of his friend, divorces and breakups and such. So not the happy book I did expect, but still a very good book, I would really recommend it!
YES!!! I’m back!! Using my bike to work
Things at Fornebu to report from this week
First, the Christmas tree fell down, wonder if someone had done it on purpose, because the tree did not look _that_ good when standing up. Do think it was fixed Friday afternoon, so it will be Christmas this year as well.
Walked back a bus stop when leaving work on Friday, just to make sure I got a seat in the bus. Saw this sign at Aker Solutions. WTF??? Slippery??? It is ….snow….with sand…slippery??? Also, note – there are still people walking on the lawn outside of the tape, you can see the new track have been made 🙂





