Martin Woodward

Jeffrey Fredrick just announced that CruiseControl 2.7.2 is now available for download: http://tinyurl.com/2zm9mz.

There are lots of bug fixes, lots of changes to the Dashboard and some new plug-ins, but the bit that is of most interest to me was (from the release notes)

TeamFoundationServer source control
----------------------
* Fix compatibility with Microsoft Visual Studio Team Foundation Server 2008 (CC-735). Submitted by Martin Woodward.

This was to work around an issue that came up when using CruiseControl (java version) to talk to a TFS2008 server (TFS2005 worked fine and still does).  If you are attempting to use CruiseControl with TFS 2008 then you should go with CruiseControl 2.7.2.  For that matter - if you are using CruiseControl.NET with TFS then you should also take a look at the latest release of the integration to TFS - as that contains the same fix allowing you to happily talk to a 2008 version of Team Foundation Server (also using the TFS 2008 client API's).

Anyway, congratulations to the CruiseControl team on the 2.7.2 release!

At EclipseCon 2008 this morning, we just announced that Teamprise 3.0 has been released!  If you've been wondering why I have been quiet on the blog lately - but also why anything I have been talking about is Team Foundation Build related, then you are about to find out why :-)  First of all, I'd encourage you to go visit the shiny new website at http://www.teamprise.com.  Our marketing team had too much fun putting that together, including getting a real, live, massive Teamprise power button made up and shipped in a huge crate from New York to be photographed and used as the new site/icon image.

The full release notes are available here, but as has been the tradition for the past few Teamprise releases, I thought I would give you a run down of my favourite new features in the 3.0 release.

At a high level, the features in 3.0 can be summarised as:-

• Full Team Foundation Build integration (including ability to execute Ant based builds)
• Check-in policy support
• Recursive folder compare
• Single sign-on (from Microsoft Windows machines)
• "Destroy" command for version control
• Show deleted items and undelete from Source Control Explorer UI
• much much more (see release notes)

While it is not my area, I should also mention that we've taken this opportunity to make our licensing more affordable for smaller teams.  We have been very pleasantly surprised by the number of people buying 1 to 20 licenses at a time.  Originally, Teamprise pricing was skewed to the Enterprise customers (i.e. simple, all inclusive and with steep volume discounts).  So we have done a couple of things to help out the smaller companies:-

• You can now purchase the various components (Teamprise Plug-in for Eclipse, Teamprise Explorer, Teamprise Command Line Client) individually as well as the Teamprise Client Suite which gives you the lot.
• We have lowered the initial prices for a single seat, meaning that people buying one or two licenses can now get the same discounts that used to only be available to folks purchasing 100.

If you have any licensing issues / queries then feel free to contact me, or you can talk to the sales team direct at sales@teamprise.com.  Anyway - back to the part of this release that I do know about - the technology. 

The first feature I want to talk about is one that I had no involvement with.  It's one of those features that many people will not notice because it just works but anyone who has done any Java to .NET web service interop work will instantly recognise as being a little bit clever.

Single Sign-On

The initial log-in screen has undergone a big overhaul.  On Windows machines you are given the option to use "default credentials", i.e. the username and password that you are logged onto windows with.  It obviously doesn't know your password, but does some JNI magic to get the native Windows API's to handle the authentication logic with Team Foundation Server.  While you are also on the login screen, you may notice the Profile feature.  This is an area that many people probably won't use, but we added for our power users and for ourselves.  Basically, the profiles feature allows you to store sets of servers/credentials that you commonly use to connect to Team Foundation Server and then you can bring up the details using a simple drop down.  Makes it much easier to switch between your production TFS instance and your CodePlex project for example - or switch credentials if you are a TFS administrator.

Check-in Policy Support

In Visual Studio, check-in policies are implemented as a .NET assembly runs every time a policy is evaluated or configured.  The policy also has full access to the .NET API's, the Visual Studio API's as well as anything it might want to pinvoke out to on the Win32 API side.  As you can imagine, this presented us some problems when we wanted to have check-in policies that ran the same in Eclipse on Windows Vista as Teamprise Explorer on the Mac or Aptana on Ubuntu - therefore we have had to develop a parallel Teamprise check-in policy framework.

As we were doing this, we took the opportunity to learn from some of the feedback folks have been having with the Visual Studio check-in policies.  While our framework and SDK will look very familiar to anyone that has developed a custom check-in policy for Visual Studio, you will notice some differences.

Firstly, we supply different policies out of the box.  The vast majority of custom check-in polices that people deploy are things like "Check for Comments" etc, so we just shipped the common ones our customers wanted to prevent them from having to write their own.

Secondly, we make use of the Eclipse plug-in framework to implement our policies as extension points.  This means that they are easy to deploy (using the Eclipse update site mechanisms built in to the IDE).  We have also separated the configuration (stored as a blob of XML data in our framework) from the implementation - represented by the plug-in deployed.  The again makes it easier to deploy, especially when it comes to version 2 of a policy...

Thirdly, all of our policies can be scoped by the path in version control to which they correspond - you are not limited to per Team Project scoping and you do not have to wrap your policies in a custom policy to get more detailed scoping like you do with the current Visual Studio framework.

Team Foundation Build Integration

Anyone that has been following this blog for a while, or who attended the Team Build talk I did at TechEd with Brian Randell, will notice that I have been increasingly involved in the inner workings of Team Foundation Build.  Now you can see the fruits of that labour.

In Teamprise we now have full integration with the shiny new build functionality in TFS 2008 as well as support for TFS 2005.  Backwards compatibility with the TFS 2005 server is very similar to if you were using a Visual Studio 2008 client, accept that ours is slightly more backwards compatible (you can create new builds on a TFS 2005 server as well as manage build qualities etc).  However it is with TFS 2008 that you get to see the majority of the features.  I could go on about this aspect all day as their are so small things that I am proud of, but at a high level you can:

• View existing build definitions
• Manage builds in Build Explorer
• Queue new builds
• View build report
• Edit Build Quality
• Delete build
• Manage Build Qualities
• Open Drop Folder
• New/Edit Build Definition

• Edit Retention Policies
• Keep Build
• Set Queue Priority
• Postpone Build
• Stop/Cancel Build
• Delete Build Definition

One of the smaller features I will call out is that from the build definition in the Team Explorer, you can right click and do a "View Build Configuration" that will open the Source Control Explorer at the place in which the TFSBuild.proj file is stored so that you can check it out and edit it.  A feature that I added solely for my own sanity during dogfooding :-). 

All this would be fairly academic, if you didn't have some way to do a cross-platform build using Team Foundation Build.  In the current release, we provide a the Teamprise Extensions for Team Foundation Build which basically Ant enables the Team Foundation build server.  The Teamprise extensions are a set of MSBuild targets that insert the Ant build process into the standard Team Build mechanism as well as a custom MSBuild We hope to extend this to support in the near future to some of the other common build/test tool-chains in the cross-platform world.  However, the Ant integration case will help a lot number of people out there.

Best yet, the Teamprise Extensions for Team Foundation Build are available free of charge for everyone - wether or not you are a Teamprise customer.  Also, if you want to see how they work and customize them to meet your own non-standard build system then the source is available under the permissive open source Microsoft Public License (MS-PL).

I would personally like to thank the Team Foundation Build Team (especially Buck Hodges and Aaron Hallberg) who have been incredibly helpful through the development of the build functionality in Teamprise 3.0 while they were also busy working on TFS 2008. 

Hopefully that gives you a quick flavour of Teamprise 3.0 and where we are going with this release.  If you head over to the new site now and take a look at the many improvements we've made, we'd love to hear what you think.

The blogosphere today is buzzing with news of the other launch happening today, but there is one a bit closer to my own heart - Eclipse 3.3 (Europa) has been released.  I'm downloading it right now.

I've been running Eclipse 3.3 since Milestone 3 at the start of the year, and as the releases have been coming out it has been getting better and better.  Interestingly, the download site today has broken down Eclipse into separate versions geared towards downloading the parts that different audiences are interested in - bringing the straight "Eclipse IDE for Java Developers" down to 78MB.  The version I need "Eclipse for RCP/Plug-in Developers" is a more substantial 153MB.

My immediate needs in Eclipse 3.3 was support for the Windows Vista native UI widgets (including things like the Vista tree control).  The version of SWT that was shipping at the time of Vista launch had a weird bug which caused the JVM to crash randomly, but was fixed early in the 3.3 codebase.  SWT in the 3.3 release has also got a version which renders using WPF rather than Win32.  I'm still not really sure what the reasoning behind a WPF version, but it is funny to compile Teamprise Explorer against this version of WPF and then zoom in using the magnification tool in Vista and everything is all smooth as it is vector based.  Performance sucks with the WPF version - but still.  With Teamprise Explorer compiled against the 3.3 Win32 SWT libraries, performance is super with the application looking more native on Vista than ones written using .NET 3.0.

Other the next few weeks I'm also going to try looking into some of the additional Europa projects.  The whole organization of the Eclipse Open Source project is very interesting to watch.  Today sees the simultaneous launch of 21 separate open source projects - many of which have dependencies on other projects.  The complexity is very interesting and yet (from the outside at least) seems to work impressively well.  Eclipse has been very good at doing releases every year, with substantial improvements as well as incremental changes.

As I write, I am 89% done downloading.  I'll let you know how I get on.  If anyone is queuing for the other launch, be sure to let me know how that goes.

So, the day after I get made a Microsoft MVP I do two posts about Java - go figure.  Anyway, today I had one of those moments where you thought you understood something and then realize you didn't and probably a lot of your code that you've written over the past 10 years doesn't work as well as you thought...  All this with the humble String.compareTo method.

Take the following strings:-

• charlotte
• Chloé
• Raoul
• Real
• Réal
• Rico

In .NET, if you want to perform a standard case insensitive, dictionary based comparison between two strings then you can use the String.Compare method.  This does a culture based, case insensitive comparison.

In Java, if you were to do use the Comparable interface which makes use of the standard String.compareTo method to sort a list, you would end up with:-

• Chloé
• Raoul
• Real
• Rico
• Réal
• charlotte

That is because compareTo looks at the unicode value of the character and sorts on that - which for those of us that tend to live in the ASCII range tends to work ok (only that lowercase letters come after the uppercase ones) - however if you have a language that uses one of the many other characters it doesn't work so well.  If you had a language where M comes before A in the alphabet you are totally screwed.

This is were you should be using the java.text.Collator class in Java.  The Collator class does locale sensitive string comparisons - i.e. allowing you to do a dictionary base sort of a set of strings.

Dope.  One of those classes I should have been using for a while...  I thought I was just being dumb, but then a couple of other people I mentioned this to were not aware of the issue so I thought it worth a blog post.

One of the things that Java IDE's have always had over Visual Studio is the ability to target older versions of the VM from the latest and greatest versions of the tools.  For example, I develop in Eclipse 3.2 day to day, but I target Eclipse 3.0 on Java 1.4 for compilations and to debug against.  That way I get errors in Eclipse 3.2 if I try to use a method that isn't in the Eclipse 3.0 object model.  Very useful.  That said - I had a problem recently because my IDE was telling me that I couldn't use the "assert" keyword which was introduced in Java 1.4 (which we require for Teamprise).

The problem was in Windows, Preferences, Java, Compiler.  Source compatibility was set to Java 1.3 and .class file compatibility set to Java 1.2 - I corrected these preferences to make them allow Java 1.4 source and class files and now the assert keyword works just fine.

Teamprise currently requires a Java JRE with DES encryption available in the JVM for the magic of NTLM authentication to work correctly.  Unfortunately, the GCJ that ships by default with Ubuntu and other Debian based distributions does not have one.  The easiest way around this is to install a JRE from one of the other vendors (such as Sun, IBM or BEA) – all of which are free (as in beer).

Since Sun has recently modified it’s licensing agreement for Java it has recently become a lot easier to install a the Sun JRE onto your Debian based installation.  Today I happened to stumble upon the excellent documentation in the Ubuntu wiki detailing how to install the Sun JRE and make it your default:-

https://help.ubuntu.com/community/Java

The command I never knew existed until now was:-

sudo update-alternatives --config java

That saved me a lot of time hacking around manually (I never can get the parameters to create a symlink the correct way round first time…)

Thanks to Ben for passing this on. You can now do a straight forward “apt-get install sun-java5–jre” and have it install on Debian and Ubuntu.  Due to the old licensing restrictions you used to have to package up the installation yourself and was a real pain.  Our Teamprise client needs the Sun JRE because it contains the various encryption bits necessary for NTLM authentication to work – hopefully this will make life easier for our customers running Debian based distributions such as the growingly popular Ubuntu.  See Simon Phipp’s weblog for more details.  Gentoo will have it soon too and any other GNU/Linux or OpenSolaris distributions are welcome to join in the fun.

Correction:  As Shaw points out in the comments, we don’t *need* the Sun JRE, we just need the encryption bits.  The JRE from IBM and JRockit from BEA also contain the relevant bits.  It’s just that GCJ as installed by default on Debian does not have them.

The day that Intel Macs first started shipping I walked into an Apple store, downloaded Teamprise and tried to run it to see if it would work.  It didn’t.  I wasn’t that surprised, but I had kinda been hoping that the magic of Rosetta would just take over and automagically make it work.  But sadly Rosetta (while clever) isn’t that clever.

You see, although on most of the marketing material it says our client is 100% Java, that is not strictly true.  It should say 100% java rounded to the nearest percent – in terms of lines of code we are actually about 99.8% Java with a few small lines of JNI code to call a few (very isolated) native functions.  While we seriously did consider a marketing tagline of “nearly 100% java” or “99.8% Java”, however we felt that the message would just confuse things.

So – what are we doing in native code I hear you ask?  Well, one thing we are not doing is calling into the Microsoft client libraries for Team Foundation Server access – some days I wish we were as it would mean a lot less work getting the client to run on Windows.  However, when it comes to getting the client running everywhere else we would have been scuppered.  Nope, all our Team Foundation Client logic is java talking to the web services running on your Team Foundation Server, meaning that you only need to install our client and you are good to go.

We use native code in a couple of small places:-

1. “Advanced” File handling.  We need to set a read-only file read-write when it gets checked out and we have to work under a 1.4 version of the JRE.  While Java 1.4 it has a nice file.setReadOnly() method, there is not file.setReadOnly(false) or file.setReadWrite() method so we had to write our own.  This is the only real bit of functionality that was must-have for our client that required native code.
2. Terminal handling.  Calculating the number of columns and rows in a console terminal from within the command line client.  Had we not have already developed a JNI library for the read/write issue we probably wouldn’t have added one for this, but it makes the command line client environment a lot nicer.

So you see – including comments and blank lines in the source for our native c code we have less than 300 lines – less than 0.2 % or our code base at the time of writing.

Of course, our Teamprise Explorer Client uses SWT, which has a great deal of native code in it allowing Java applications to write nice looking and performant GUI’s cross-platform.  However, the only code we have written falls into one of the two categories above.

Anyway, there is an interesting article over at Apple Developer Connection discussing how to get your JNI to compile as a universal binary.  While our JNI code in our Mac version of the Eclipse Plugin and Command Line Client is compiled as a universal binary, we currently do not officially support the Mac on Intel platform as of version 1.0 – this is mainly due to the fact that the SWT code at the time we were developing was in the process of being ported to MacIntel. 

Ed, one of my fellow developers here at Teamprise, has a great article on the topic which explains our reasons for not supporting Intel based Macs as of V1.0.  It is something that we are working on and won’t be that way for long (in fact, as Ed mentions, if you contact us then we’ll send you an unsupported MacIntel build right now).  Personally, I’m looking forward to the day when I can take one machine into a demo and show our client running on Mac OS, Windows and Linux – but we’ll have to wait for better virtualization support for the new intel based Mac’s until that can happen.

I’m currently writing a diagnostics tool to perform all the same connectivity diagnostic checks that I do manually when I am having trouble connecting to something.  The following code snippet is how I am checking to see if a web or proxy server is listening on a particular port.  I thought I’d post a similar example here in case it was useful to you.

Note that the OPTIONS http method is very useful as a ping or noop type call on a web server.  Some web server administrators (such as Google) deny the OPTIONS request as it isn’t something that you’ll see a browser doing and they want to minimise their attack surface for the naughty folks out there in internet land.  Even if they do, you will still get some http response back (i.e. a String beginning with “HTTP”) which you can test for to tell if a web server exists on that port.

Problem:
Use ssh tunnelling to access a Subversion repository using SSH tunneling (i.e. with a subversion repository url of svn+ssh://myservername/myrepo) using the Subclipse subversion integration with Eclipse. I tried various things and used each of the three interfaces for configuring Subclipse (Window, Preferences..., Team, SVN).

When I used JavaHL (JNI) I got the following error, "svn: Can't create tunnel: The system cannot find the file specified." SVN Command Line gave me a similar error. Finally the JavaSVN interface (1.0) just did not want to authenticate with my server at all. Did various searches on Google and couldn't find an answer that worked, just lots of people with a similar problem. Anyway, the following works for me...

Solution:
You need to create an environment variable called "SVN_SSH" that points to an executable file that accepts the same command line arguments as ssh on unix. I did this by doing the following:-

1. Set up ssh keys. Not going to cover that here as you can easily Google for that. You need to end up with your public key on the SVN server and your private key loaded into Paegent locally.


2. Download and installed the excellent TortoiseSVN client for Windows.


3. Set the following environment variable (by right-clicking on My Computer, Properties, Advanced, Environment Variables, New):-

   Variable name: SVN_SSH
   Variable value: C:\\Program Files\\TortoiseSVN\\bin\\TortoisePlink.exe

   (The "\\" is very important, otherwise it won't work. Equally, you cannot use the plink.exe that comes with putty as that fires up a command shell window which is really annoying. The TortoisePlink.exe is a windows implementation of plink that doesn't bring up any UI)
   



4. Configure the Subclipse plugin to use JavaHL (JNI)


5. Restart Eclipse


6. Do a little victory jig (optional)

I'm loving the new Generics support in C# 2.0 - may I never use the vanilla System.Collections namespace again. Syntactically, generics in C# and Java are quite smiliar, but there are some important differences under the hood of the VM (or CLR). There is an intersting converstation between Bill Venners and Anders Hejlsberg posted here on the topic of the C# and Java implementations of Generics. Basically, the IL for .NET 2.0 understands generics, but the 1.5 JVM does not.

Update (Jan 2006): If you would like to use some of the features of VSTS from Eclipse then you might want to take a look at my new employer, Teamprise. They provide an eclipse plugin to access Team Foundation Source Control from Eclipse running on multiple platforms including Windows, Linux and Mac OS X.

Original Post: I have just managed to get a quick test java client talking to VSTS and retrieving a list of projects running on my Team Foundation Server. I know this is a small step towards the goals of the VSTSEclpse project, but I'm really happy I've got this working and wanted to tell everyone. Thanks to Davanum Srinivas, Dexter Wong, Evgeny Beskrovny and the rest of the folks over at the axis-user mailing list for all their help in getting NTLM authentication with a Windows Web Service working from a Java application. I've been trying to get NTLM authentication working for something I needed to do at work recently, so this came in doubly handy (another example of working on Open Source projects in your own time directly benefiting your employer).

The test client uses Axis 1.2.1, Jakarta Commons HTTPClient 3.0rc3, Jakarta Commons Codec 1.3 running in Java 1.4.2_08 on Windows XP SP2. The Commons stuff is needed to allow you to talk to the VSTS Web Services because they are protected with NTLM authentication. To get NTLM working from java, you need to do the following:-

Download a copy of the WDSL to a local directory. This is to allow you to run WSDL2Java over it to generate a starting point for your stubs. You can point WSDL2Java to a URL, but not if that is protected by NTLM ;-)

Run WDSL2Java pointing at your local WSDL file. For more information on WSDL2Java see the axis user documentation.

Edit the createCall method of your stub to include the credentials you would like to use in the call. Currently I have this hard-coded like:-

Obviously, this should be loaded from a configuration property somewhere.

Now, you need to configure Axis to use the Commons HTTPClient class for the HTTP transport. Luckily, the Axis folks have made it very configurable, so all you have to do is include a file called "client-config.wsdd" in the classpath. My client config looks as follows:-

Now all you need to do is write a client class to use your stub to talk to VSTS. Below is my first class which returns a list of the projects available in the team foundation server by talking to the Common Structure Service running on Team Foundation in the bisserver application.

Now the real work starts...

Apologies for the lack of posts recently. We are due a new release of my latest project at work in a couple of weeks and in my spare moments I have been investigating my new play project, a VSTS plugin for Eclipse. Anyway, I have just uploaded the website for the VSTSEclipse project to sourceforge.

It is ages since I have done a static HTML website and not been messing around with some server side functionality or other. There are a couple of features I would like to add but didn't want to delve too deeply back into the world of php that I haven't touched for at least 4 years, possibly longer.

This site is not the most inspirational design I have ever done, but it is all div / css based, tested in IE 6 and Firefox 1.0.3 and I hope to post a handheld version of the stylesheet shortly. As ever there is hardly any content at the moment, but there you go - you would expect nothing less from me, it would all be spelt wrong anyway.

Take a look at let me know what you think. The project itself is really interesting and quite challenging. Looking forward to getting stuck in to it (just need to finish off installing Beta 2 of VSTS at home).

In an effort to keep my Java skills up to date while also using some of my new-found dotnet knowledge I've joined the team trying to put together a VSTS SCC plugin for Eclipse that talks to the source control functionality in Visual Studio Team System. It is early days yet but it is an interesting goal and I hope to learn some interesting stuff while putting something together that will be useful for the wider community. If the only thing I accomplish is to get the wonderful Eclipse Diff tool hooked into VSTS then I'll be very happy (the one in VS 2005 is still not as good as the Eclipse one, if a little better than the appalling diff tool that ships with VSS 6).

Interesting news from Javaworld. BEA are to announce that they are to join the Eclipse foundation. Hopefully this signals that Weblogic Workshop will be integrated with Eclipse (just as IBM integrate at the moment for WSAD). This only leave Sun and Microsoft as the major vendors staying out of Eclipse. While SunONE Studio (or whatever it is called nowadays, ex Forte, ex NetBeans) deserves to die for being soo slow, I don't see Microsoft integrating Visual Studio 2005 anytime soon...

While this should be seen as a great development, I hope that the folks at JetBrains are not put out of business. Eclipse used to be my preferred IDE until I became an IntelliJ convert (interestingly it was a BEA employee who converted me).

Update 24 Feb 2005: BEA have issued a press release announcing the Eclipse move. Looks like they are definately going to integrate workshop!!

"With the next version of Workshop, code-named Daybreak, BEA currently plans to move its implementation of the WebLogic Workshop IDE framework to the Eclipse open tools platform."

Been using the Beta version of Intellij 4.0 on my last project. It is now on late release candidate builds and is fantastic. Previously I was an Eclipse fan, however this version has me sold.

Haven't tried out the generics support for Java 1.5 yet, but I've heard so many people talking about it I think I may have to see what the fuss is about.

Brian Coyner seems to agree with me in his review O'Reilly Network: IDEA 4.0 - Is It Worth The Money? [Jan. 23, 2004]