This year I want to show an example of what is regarded as NetRexx’s biggest advantage: easy integration in the JVM environment, making everything more straightforward, more readable, and more fun than in other languages. When encountering a new environment where work needs to be done, it suffices to look up the javadoc of the library and go for it.
Recently there was an opportunity to do some work with git – actually, there was an application to be made, and I realized its requirements overlapped for a large part with what this version management system can do. I looked around for a library and found that in jGit, from the eclipse project.
For this small experiment with git I am using NetRexx in scripting mode. This means, I am not declaring classes and just script everything in one go, on seqentially executed lines; except one method that I pasted from another program.
package com.rvjansen
import org.eclipse.jgit.
import com.eaio.uuid.UUID
trace results
builder = FileRepositoryBuilder()
repository_ = builder.findGitDir(File("/Users/rvjansen/papiamento")).readEnvironment().build()
git_ = Git(repository_)
uuid_ = newUUID()
file_ = File(repository_.getDirectory().getParent(), uuid_);
file_.createNewFile();
out = PrintWriter(BufferedWriter(FileWriter(file_)))
out.println(Date())
out.close()
git_.add().addFilepattern(uuid_).call()
git_.commit().setMessage("Added file" uuid_).call()
repository_.close()
method newUUID() returns String static
return UUID().toString.toUpperCase
I do declare a package, as this is good practice to avoid name clashes, and I am importing the packages org.eclipse.jgit and my favorite uuid package, the one that can do real timebased UUID’s following the norm – as opposed to the java UUID that does something else. In this small program the test case to be done was to version data in files kept by git, with UUID’s as filename – as not to have to use a range in a generated name. Ranges are generally bad in applications, because they come back and bite you with limitations that you did not imagine at design time.
Next we see the ‘trace results’ statement. When prototyping it is a good thing to be able to see exactly what is going on, and this is the way to do it. I am initializing a git repository, and for clarity I am using an absolute directory path. For production apps I would not do that, but when prototyping, we don’t need any relativity to make mistakes with – with absolute paths we know where everything ends up. The reference to the git repository ends up in the variable git_.
Next we are creating a file, named after a UUID that we conjure up, and write the output of Date() into it. Note that Date() comes from the standard Java library, and yes, it’s deprecated, but it beats all forms of Calendar in shortness. Obviously, these files are going to end up containing other data anyway.
After we have closed the file, we add it (its file pattern) to the git repository and we commit it, with the obligatory message. Note that all the git api’s allow for the chaining of calls. Again, I would not do that in maintainable production code, but it is great to keep examples and prototypes short.
When writing this, in two passes (first the file stuff and then the git stuff) I used interpreted execution, looked at the trace output to see that everything worked (also, to see the type info that I could leave out in NetRexx but do like to know) and for quick edit/execute turnaround.
I am perfectly happy to be able to do this in a few minutes, and I think you would be too!
Meta: this post is part of the Java Advent Calendar and is licensed under the Creative Commons 3.0 Attribution license. If you like it, please spread the word by sharing, tweeting, FB, G+ and so on!
