In the beginning the man created CVS. And CVS had some precursors as well, and I don’t care about them as I’m not historian. Thing is only some spirit said, let’s create some software guidelines based on them: and there was Software Guidelines. Java EE software guidelines. Some other spirit saw many years later these guidelines, that they were good: and it wondered why doesn’t our actual code follow them. And it said, let the team create for each file an informational header filled with version-related information: and it was so.
Now, it might be that the world has, you know, evolved. It might be that such headers would be redundant today, in a world where with a rightclick you can see the history of your file, repository, contributor, whatever. But the headers’ necessity was written in stone tablets, I mean in Software Guidelines mind you… so headers shall be. Why would YOU refuse a paying customer, eh? I wasn’t in the decision loop, lucky me, otherwise I would have had some struggle with my cognitive dissonance. Yes, you’d have versioning information in front of you when you print a class, but who does print code files nowadays? If one still uses VI to program and can’t take advantage of the IDE to show versioning info, does that person actually have a team who could profit of this information or it’s just programming Tetris clones in a garage?
But enough said. Work is work, and I never wrote Maven plugins before. I said Maven plugin because, although Subversion does have for the hardcore RCS-ers keywords substitution, nobody wanted to pollute the code with redundant information. The plugin will just have to spit out a directory of Java files with the desired headers (feels like the 00’s again with their code generation frenzy). If I google around, I see there are articles recommending headers as late as 2010 (or even later?) so it came to my big surprise that there’s no Maven plugin doing this task. There’s a Maven plugin adding license headers with variable replacement, it’s just it generates ONE header and applies it to all source files. There’s another Maven plugin which reads the working copy revision number and sets it as a project property – unfortunately it’s per project and not per file.
So… which way now? The SVN plugin I just found was small but using all kind of internal SVNKit accesses so I thought, here are the nice SVNClient interfaces, let’s give them a run. I know could have started from scratch, but given the world of thousands new projects every day, I thought I’d extend a bit the above mentioned license plugin and maybe, if the owner agrees, the resulted code can be used also by other poor folks like us.
…and a couple of days later (nonsense time included) there was the Maven plugin. It was really no big deal now that I look back, but it was my first plugin so I had to get familiar with the almighty Mojo (surprise, it’s just a goal). And yes, using TestNG was also new for me, although I can’t really say it meant a big improvement over JUnit for me (you DO use the one or the other, right? RIGHT?). I realize I could actually use the dependency test…. let me add that quickly.
And if you didn’t know the blog I linked above (Otaku, Cedric’s blog – the guy of TestNG), I recommend you to take your time and read it. Totally worthy.