I thought they were out to get me

First, some background:

Keith just recently changed our can’t-mock-dis Startup service from a plain ol’ Singleton (in the Gang-of-Four sense, not in the Spring sense) to an Abstract Factory so that — woohoo! — we can now mock out the Startup service and its application-context-creatin’ slowness when we want to.

This gives us such great flexibility in the testing department, and the cost is a slightly wordier syntax when you’re getting an instance of the real StartupSvc.  This syntax changed from:

StartupSvc startupSvc = StartupSvc.getStartupSvc();

to

StartupSvc startupSvc = new StartupSvcFactoryImpl().getStartupSvc();

But these calls aren’t littered throughout the application code — it’s kicked off by ServletContextListeners and such — so there are really only a few places that even have to change.  It’s great!

A Happy Move

So anyway, earlier this week when Keith committed his changes, I had eventually Maven Eclipsed a couple of prototype .war projects I was working on and noticed that I needed to update to the new syntax for getting an instance of the StartupSvc.  I was glad to see that the abstract factory stuff had been committed.

But then today, I Maven Eclipsed again, and now Eclipse was saying it didn’t know what a StartupSvcFactoryImpl was and trying to get me to return to the old syntax.

Reversion Revulsion

It appeared that Keith had reverted his changes and removed the abstract factory.  Had he encountered a nasty problem and reverted it until we could figure out a solution?  I didn’t want to go back to the old way!  Why didn’t he tell me?!  (This last one was a bit hypocritical on my part, since I’m not very good yet myself at noticing when my changes are breaking changes that will affect others on the project and notifying them accordingly.)

Silly Me

Then I realized that, oops, hadn’t I just Maven Install’d the Startup module (with a minor change I needed to test with on my other project) to my local Maven repository from my local working copy?  And how long had it been since I had updated the source code of that project?

Oopsy oops, I had just made the StartupSvc revert, by installing an older version.  I just updated the Startup project from Subversion, then Maven Installed it again, then Maven Eclipsed my .war prototype… and the abstract factory is back.

Silly me!  :)

They wouldn’t take a hint

There is a small but loyal band of files-and-directories* that routinely appear each time we create a new Java project.  (I believe the appearance of many of these has to do with the fact that we use Maven.)  They are from two different families — we have .classpath, .checkstyle, and .project File, and .settings and target Directory.  (Another Directory whom we see a bit less frequently, shows up only when we generate local javadoc.  He just goes by “doc”.)

While we appreciate the work these files-and-directories do for us, we really don’t want them in our Subversion repository; so the first thing we usually do after committing the skeleton of a new project is to go svn:ignore these; after which, they politely bow out of sight.

But then there they are again to greet the next new project.  How to help them understand in a more permanent way?

---

Fixing my auto-props issue the other day got me looking at my Subversion config file, and it turns out that in the [miscellany] section there’s a global-ignores setting that’s just what I needed for this type of communication.  I uncommented that line and added the following to the end of it: “ .checkstyle .classpath .project .settings target doc“

When I committed the project the first time, the usual fit-to-ignore files-and-directories didn’t show up, and even when I generated local javadoc, Subversion knew not to process the doc directory.  Wooha!

*Kind of like Rabbit’s friends-and-relations in Winnie-the-Pooh… remember?

Refactoring to interfaces: if only Subversion could understand

There is a refactoring I do in Eclipse sometimes that confuses Subversion:

Suppose I have a class named MessageSender.  It does not implement an interface; it just does the work itself.  Now perhaps I want a MessageSender to be an interface and have a MessageSenderImpl.  To accomplish this change, I:

1. Rename MessageSender to MessageSenderImpl.
2. Extract Interface on MessageSenderImpl and call it MessageSender.

At this point, I can see that Subversion is confused, because there is a little red X in the icon for MessageSender.java in the Package Explorer:

If I commit my changes now, MessageSender.java will be deleted and the build will be broken if I have any code using the new interface.

My current workaround is to:

• Revert MessageSender.java, then
• Replace With Previous from Local History

But this is more work than it oughter be, ain’t so?

Update 10/13/2008: Karl’s comment inspired me to post my question to the Subclipse email list, where Mark Phippard told me that an enhancement to Subclipse released in Subclipse 1.4.3 fixes this issue.  (I was using Subclipse 1.4.2).  I upgraded Subclipse to the current version (1.4.5) and now my two-step refactoring works (i.e., after step 2 the file is marked as changed rather than marked for deletion, so I don’t have to do my workaround).

Thanks, Karl and Mark!

If you forgot to set your svn:keywords…

Somehow the Subversion auto-props didn’t cause my svn:keywords to automatically be set in my classes, and now I had 32 classes that, if I set the properties through Eclipse, I’d have to fix manually.

Me no like 32 repetitions of same thing.

So I looked for a way to do it from the command line.

Here’s a way that worked for me:

(I ran the following once from the project’s src/main/java, and once from src/test/java)

svn propset -R svn:keywords "Author Id Revision Date" .

Part of why this works so easily is that, guided by the Maven defaults, we’re set up with our Java source code split out from the other files into src/{main,test}/java.  If the XML configuration files were in the same directory with Java source code, it would take more work to set the property on just the Java files, I think.

Update 10/10/2008: Ben (“New Ben”, I mean) helped me find two good things!

Why auto-props weren’t working

Even though I had the line

*.java = svn:keywords=Author Id Revision Date

in the [auto-props] section of my Subversion config (C:\Documents and Settings\myUserName\Application Data\Subversion\config), it wasn’t adding those keywords on commit.

It turns out there was one additional thing to do: in the [miscellany] section of the same config file, I needed to uncomment the line that reads:

enable-auto-props = yes

Ha!

Mass Keyword-Adding Using Eclipse

The other thing Ben showed me was how to recursively set the keywords from within Eclipse.

1. Right-click on the source folder (src/main/java, for instance) and choose Team -> Set Property…
2. For Property name, enter svn:keywords (a warning appears at this point, but we will satisfy it soon)
3. In the “Enter a text property” box, enter (in my case) Author Id Revision Date
4. Check the Set property recursively box
5. Click OK.

I then repeated this procedure on the src/test/java folder.

Thanks, Ben!

We will not, sir, render…

Today I moved a concepts-n-usage document from MagicDraw out to Subversion, and made a link from MagicDraw out to the Subversion, uh, version.  The problem being, when I go there, it is rendered as raw HTML!

Initial Tries

I tried “view page source” and it looked just the same.  I tried to find a URL parameter to pass to tell it to render the HTML, but didn’t come up with anything.

Worries

Visions began to go through my mind of having to maintain the document in MagicDraw (but the html text control in MagicDraw is clunky… response is sluggish, and it’s too easy to accidentally delete things from your document, possibly without knowing it –  it really seems like it’s designed for use as a possibly multiline text box, not multipage documents); or export a copy of what’s in Subversion to some location on the network that is then referenced (but how to automatically keep that up to date with the repository?  Ug…) or have two versions, one in Subversion and one in MagicDraw and try to always remember to keep them in sync (I don’t know that I could ever be happy with that though, especially not after reading Test-Driven Development!)

Searching

So it was with angst and worry that I started looking for information about Subversion, and rendered vs. raw html.  My search eventually led me to the section in the online Subversion book dealing with file content type.  It took a few minutes for it to sink in, but finally I realized that there was a subversion property named svn:mime-type, and it looked like if I could set that, it might help with my rendering issue.

I wondered if you could set the Subversion properties in Eclipse.  You can:

But what to set it to?  (Now stop your snickering, all you MIME-savvy folks, I’m not hip on all this stuff so I have to look it up, okay? ;)

I looked through the MIME text media types, and text/html looked like the best thing, so I set that:

…and committed my changes…

Solved

…and now my link from MagicDraw renders beautifully:

I think there’s a way to set up Subversion to do this automatically for .html documents so that I wouldn’t have to explicitly set a property, but this is good enough for me today!

Plurals and intuition

I just downloaded the Bitronix Transaction Manager to try out its JNDI server (and probably also its transaction management).  The JNDI server is only in the yet-to-be-released version 1.3, so I needed to use a Subversion client to check out and build from source code*.  As this was (I think) my first time doing a checkout from an external Subversion repository (though I think I’ve checked out code from an external CVS repository once or twice), I wasn’t sure what I was doing…  I followed the instructions, but kept getting errors.

I decided to try checking out a project from somewhere else.  I tried the Maven 2.0 source and that checked out fine.  Hmm.

After hmm-ing for a moment or two, I noticed that the URL for the Maven source code used the https protocol, so on a hunch I tried modifying the Bitronix checkout URL to use https… it worked.

So, obviously I should have tried that, right?  :)

It’s an interest of mine when a hunch leads me to the right solution, to try to reverse engineer what made me think to try that hunch, to see if it’s something that could be taught to someone else.  In this case I was in the process of separating concerns (“Is it the remote server or my Subversion client that seems to be having the trouble?”), when I noticed that the protocols used were different.  So I guess part of it is noticing little details — or is it noticing important details and developing good judgment on when a detail might be important?

* Well… come to think of it I could have used the snapshot Maven repository… but I wanted to see the source and the tests, to get a better idea of what this is, and of its quality.