If you tried Subversive before, it’s time to try it again

Helios’ Subversive release is a vast improvement over previous versions!  If you’ve tried Subversive before and didn’t like it, it is time to try it again.

For those who aren’t aware, Subversive is an Eclipse client for accessing Subversion.  In March 2009, I blogged about both choices of Eclipse client: Subversive and Subclipse.

Installing Subversive in Helios

  1. Launch Eclipse
  2. Help > Install new software
  3. Choose “Subversive SVN Team Provider” and “Subversive Revision Graph”.
  4. Eclipse prompts you to restart the workspace
  5. Go to Subversion perspective
  6. Eclipse launches the “Subversive Connector Discovery” for you to pick a connector.  I chose SVN Kit 1.3.2.  Be careful.  The latest versions of the connectors are not at the top.

New Features

All the new features are documented on the wiki.  The biggest things:

  • Subversive is an incubator project and in the Helios release train.  This means it was designed to work at the launch of Eclipse 3.6.
  • Better tag awareness – I can now do a compare with tag and see list of tags for project.  It is also fast.  Not CVS level fast, but that is because of the way SVN data is stored – something a plugin can’t do anything about.  It is faster than before which is appreciated.
  • Can compare by tag/date/revision or generate a diff file
  • Revision Graph optional feature (see screenshot up top).  This was pretty much the only thing I switched to Tortoise SVN for and now it is in my main tool.  It is also easier to use than Tortoise’s version.  It has the following features:
    • Handles tags/branches/etc
    • If you mouseover a box, you see author, date and full commit comment
    • If you right click a box, you can compare to the trunk (which it calls ‘HEAD’ oddly enough), show history or branch/tag from that revision.
    • The image scrolls well.

What is still missing?

It’s still a pain to look at all the changes to a file.  This is something that is easy in CVS, but not SVN.  It is better than it was in the past release, but still a pain.  I recognize this is a number of operations in SVN, but it would be nice if a tool could automate it.  Since none of the other Subversion plugins have this feature either, I can’t call it a fault of Subversive though.

Comparison with Subclipse

In fairness to Subclipse, Subclipse also has an optional revision graph feature at this time.  Most of the logic from my previous post still applies.  I still like Subversive “just a bit better.”

What’s next?

I think the big question is whether Subversive will get promoted to actually be part of Eclipse.  It looks a lot more promising than 18 months ago.

—-

See my review of Eclipse 3.6 itself.

product review: infinitest

Want to run your JUnit tests as soon as you change the code?  That’s what infinitest strives to do.  The starting point is infinitetest.org which directs you to the corporate site.

What does it do?

Infinitest installs as a plugin to your IDE.  In Eclipse, it adds a bar to the bottom of your screen.  I’d say I lost about an inch of real estate.  Not much, but if you have a lot of other plugins, this could be a problem.

Every time you change Java code, it sees which unit tests should be re-run and changes the bar to the appropriate color:

  • black – waiting for changes – when open workspace and haven’t done anything yet
  • green – all is well
  • yellow – no tests were affected by this change
  • red – one or more tests are failing (could be from this change or a previous change)

The bar, also tells you how many “test cases” were run.  They mean the number of test classes rather than the actual number of tests so this number isn’t as useful as it sounds.

Does it require a lot of configuration?

No.  The entire user guide is two screens long.  Configuring it took me less than two minutes – which were spent looking up the name of my integration test runner and package so infinitest didn’t run them.   I also looked at the preferences and saw it had a default of half a second before giving up on a test.  That’s a good length.  No unit test should take that long.

What do I need to run/install it?

Infinitest runs as an Eclipse or IntelliJ plugin.  I tried it in Eclipse.  You install from an update site.  My only concern is they don’t provide a manual zip file style local update.  Now granted, neither do many other products, but they take the time to write:

If you are behind a firewall, you may have limited access to the Internet. This can cause problems accessing the update site. If you use a web proxy to connect to the Internet, make sure that you have correctly entered your proxy settings into Eclipse under Preferences->General->Network Connections.

If it’s enough of a problem to document, I think it’s enough of a problem to realize you have customers that aren’t allowed do download any plugins without having an approved body do it.

How much does it cost?

The initial install is for a 30 day trial.  After that, you have to decide if you are an “individual” or “corporate” user.  Once you decide you either fill out a form saying you are an individual or pay $150 per seat (perpetual license) and a license is e-mailed to you.  Just copy/paste the license into your IDE and you are done.

individual – you own the copyright.  In other words you aren’t selling what you write.  From talking to the vendor, it sounds like open source and code I write for JavaRanch fall into this category.

corporate – code you write for someone else to make money – also known as your job.

How well did it work?

I have three Java projects in the workspace I used to test:

  1. JForum – The JavaRanch fork of JForum.  About 200 classes and a bunch of unit tests.
  2. PickWinners – The program JavaRanch uses to pick winners in the book promotion.  About a dozen classes and about the same number of tests.  Both unit and integration tests.
  3. Play – this has one class and no unit tests.  I use it to test out “what does this code do”

My attempts:

  1. Edited a file in my Play project – it ran all the test cases in JForum and PickWinners.  At first, it looked like it wasn’t using dependencies, but I think this was because it was the first run and it though nothing had run yet.
  2. Edited the file in Play project again. This time it correctly realized no tests were affected.
  3. PickWinners now has 5 errors of type “Infinitest Test Failure” – All are errors accessing the database from my integration tests.
  4. After adding infinitest.filters, I had to clean the project to remove the failures.  (This was documented in the manual page.)  It does re-run tests that are still unfiltered.  It took me to passes to get the right filters.
  5. Made another change to PickWinners – it’s still running JForum tests
  6. Cooked and ate dinner (in other words, a bunch of time passed)
  7. Tried again – all of a sudden it  started picking up only the truely dependent tests.  Maybe there was a learning curve?  Cool.
  8. Almost everything I tried after dinner did pick up the correct tests based on dependencies.  It (usually) found tests that use the class indirectly.  It got faster and finding dependencies when I repeatedly edited the same class.  I assumed it cached the result.  Which is good because when doing real development, this is what happens.

What problems did I encounter?

  1. The JForum project doesn’t show the test failures as compiler errors.  The PickWinners project does.  The JForum project also complains sporadically about a class not being found that is in the same project.  Note: this problem temporarily went away after I restarted my workspace.  It came back after I introduced a failing test and corrected it.
  2. As I wrote above it usually finds the relevant tests.  For example, I changed the implementation of post.setText() to use the value “hi” instead of the passed in value.  I expected a whole gaggle of tests like the following to run and fail.  None of them did.

    @Test
    public void noCodeTags() {
    post.setText(“test”);
    PostCommon.processText(post);
    String actual = post.getText();
    assertEquals(“transformed post”, “test”, actual);
    }

  3. I have to assume this won’t work for reflection based code.  I don’t have any on hand.  While I could write some, it doesn’t sound like it work from the vendor’s description.  And if the vendor admits it won’t work, I’m inclined to believe them.

Final thoughts

I like the emphasis on “keeping the bar green.”  If you always see it on the screen, it reminds you it exists.  I haven’t had it installed for long, but I’m already used to it being there and relying on it.  Even if it isn’t perfect, it’s great to have present.

It worked well enough to be useful on my home projects.  I’m not sure how well it would function in my work environment where compiles involve a lot more code.  The “find the proper tests phase” was noticeable at home.  It could be better at work (faster machine) or worse (much bigger workspace.)

not sure how well it would work in my work environment where compiles involve a lot more code

eclipse 3.5 – four good, 1 bad feature

I’ve been using Eclipse 3.5 for a couple months now making it a good time to share the features that affected me the most – 4 good; 1 bad.

Getting started

Quick install with favorite plugins:

My Eclipse 3.4 workspace was starting to get corrupted making it a good time to make a clean break.  It wasn’t too time consuming to download/install Eclipse and create a new workspace.  I also installed the plugins I use regularly as I wanted them installed before switching to do development in the new workspace.
Sysdeo – For Tomcat with Eclipse.
Subclipse – For Subversion repository access.  The install of this one leaves something to be desired, but that’s not Eclipse’s fault.  it’s a license thing.
Ecl emma – For code coverage.
PMD – For static analysis.

Workspace setup:

1) Pulling in the source code from SVN is trivial.
2) I tweaked a few settings in the preferences.  I could create an epf file, but I hadn’t changed much in the old workspace.  This was a good opportunity to look at the new preferences in any case.
3) Then there’s the “what I need to do project” – it’s not committed to SVN (which is an accident waiting to happen) – but I have all the information in my gmail account or in my head.  The bulk of that project was a “todo.txt” file which I used to keep track of what tasks I wanted to work on for JavaRanch.  This file is now gone.  Which brings me to my favorite feature #1.

Features

Favorite feature #1 – Task Lists

This feature is awesome!  It replaced my “todo.txt” file for keeping track of stuff. (It’s different than //TODO or //FIXME because it isn’t necessarily tied to code.)  You can specify the status, a due date, categories and estimates.  I’m one of those organized types who likes keeping lists.  At work, I have a piece of paper I write on as I code with little things that come to mind, test cases I need to write, other tasks, etc.  At home, I was using the “todo.txt” file in Eclipse because I have less desk space than at work.  This makes the transition to an actual task list system a natural one and a pleasure.  I also started using gmail’s tasks around the same time.  They serve different purposes.  Eclipse for development.  Gmail for other things.  Did I mention I really like this feature?

Favorite feature #2 – “Open with”

When you use “open type” there is a drop down next to open that lets you choose the “open with” option.  This is really nice.  I can’t count the number of times I’ve tried using open type on a JSP to have it tell me my encryption settings aren’t correct.  I know the solution – open in a text editor – but that wasn’t the default before.  A minor annoyance, but nice to see it resolved.

Favorite feature #3 – Export/import JUnit results

Being able to send an XML file to co-workers about failing tests beats a screenshot.   Especially in terms of seeing the stack trace for “it works on my machine” type bugs.

Favorite feature #4 – Generate toString

This speaks for itself. And easy way to generate toString so it spits out all the fields is a nice time saver.

And the worst feature

Code formatting.  What happened?  This used to work intuitively and well in Eclipse 3.4.  In Java, it gets rid of my careful placed (for readability) whitespace between lines.  I checked the preferences and “number of empty lines to preserve” is set to one.  HTML is much worse.  If I format a bunch of lines containing one <input> per line, Eclipse turns this

<input type="hidden" name="action" value="moveAllSave" />
<input type="hidden" name="module" value="${moduleName}" />
<input type="hidden" name="source_forum_id" value="${sourceForumId}" />
<input type="hidden" name="log_type" value="0" />
<input type="hidden" name="log_description" value="bulk move from admin console">

into this
<input type="hidden" name="action" value="moveAllSave" /> <input
type="hidden" name="module" value="${moduleName}" /> <input
type="hidden" name="source_forum_id" value="${sourceForumId}" /> <input
type="hidden" name="log_type" value="0" /> <input type="hidden"
name="log_description" value="bulk move from admin console">

Huh?  That didn’t happen before.   I tried setting “never join lines” but it doesn’t take effect for HTML. I guess I’m not relying on the code formatting.  Unfortunate as it will slow things down.  But yuck.  Just look at it.