But it works on my PC!

The random thoughts of Richard Fennell on technology and software development

Setting a build version in a JAR file from TFS build

Whilst helping a Java based team (part of larger organisation that used many sets of both Microsoft and non-Microsoft tools) to migrate from Subversion to TFS I had to tackle their Jenkins/Ant based builds.

They could have stayed on Jenkins and switched to the TFS source provider, but they wanted to at least look at how TFS build would better allow them to  trace their builds against TFS work items.

All went well, we setup a build controller and agent specifically for their team and installed Java onto it as well the TFS build extensions. We were very quickly able to get our test Java project building on the new build system.

One feature that their old Ant scripts used was to store the build name/number into the Manifest of any JAR files created, a good plan as it is always good to know where something came from.

When asked as how to do this with TFS build I thought ‘no problem I will just use TFS build environment variable’ and add something like the following

<property environment="env"/>

<target name="jar">
        <jar destfile="${basedir}/javasample.jar" basedir="${basedir}/bin">
            <manifest>
                <attribute name="Implementation-Version" value="${env.TF_BUILD_BUILDNUMBER}" />
            </manifest>   
        </jar>
</target>

But this did not work, I just saw the text ${env.TF_BUILD_BUILDNUMBER}" in my manifest, basically the environment variable could not be resolved.

After a bit more of think I realised the problem is that the Ant/Maven build extensions for TFS are based on TFS 2008 style builds, the build environment variables are a TFS 2012 and later feature, so of course they are not set.

A quick look in the automatically generated TFSBuild.proj file generated for the build showed that the MSBuild $(BuildNumber) was passed into the Ant script as a property, so it could be referenced in the Ant Jar target (note the brackets change from () to {})

<target name="jar">
        <jar destfile="${basedir}/javasmaple.jar" basedir="${basedir}/bin">
            <manifest>
                <attribute name="Implementation-Version" value="${BuildNumber}" />
            </manifest>   
        </jar>
</target>

 

Once this change was made I then got the manifest I expected including the build number

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.9.4
Created-By: 1.8.0_25-b18 (Oracle Corporation)
Implementation-Version: JavaSample.Ant.Manual_20141216.7

Getting going with the TFS Java API

If you are using the TFS 2012 Java API it is important you read the release notes. It is not enough to just reference the com.microsoft.tfs.sdk-11.0.0.jar file in your classpath as you might expect. You also have to pass a Java system property that associates com.microsoft.tfs.jni.native.base-directory with the location of the native library files that provide platform specific implementation for method calls.  The command line for this is done in the form

java.exe -D"com.microsoft.tfs.jni.native.base-directory=C:\Users\Username\YourApplication\native"

If you don’t set this property you get an exception similar to

Exception in thread "main" java.lang.UnsatisfiedLinkError: com.microsoft.tfs.jni.internal.platformmisc.NativePlatformMisc.nativeGetEnvironmentVariable(Ljava/lang/String;)Ljava/lang/String;

Now setting this property on the command line is all well and good, but how do you do this if you are working in Eclipse?

The answer is you set the argument via the Run > Run Configuration. Select your configuration and enter the VM argument as shown below.

image

Once this is set you can run and debug you application inside Eclipse

Dropping build output to source control in TFS11

One of the nice new feature of TFS11 is that you get a third option for what to do with your build output

  • Don’t copy output anywhere – good for CI builds that nobody will ever consume, just used to run tests
  • Drop to a UNC share e.g. \\server1\drops – the default and used 9 times out 10
  • The new one - drop to source control e.g. $/myproject/drops.

The advantage of this new third option is your build agents can place the files they create in a location that can be accessed by any TFS client i.e. in the source control repository. A user no longer needs to be on a VPN or corporate LAN to be able to see a UNC share.

But remember, just because the builds are in source control does not mean that the build don’t still follow the normal build retention policies, so they will not accumulate forever, unless you want them to.

Now some teams will have good reasons as to why the don’t want builds going into source control. Deployments to a NuGet server and the like will be a far better system for them. This is still all possible, it is just down to build process template customisation. You have not lost any options, just gained another one out the box

But what about building Java via Ant or Maven within TFS using the Build Extensions? Well at this time the process template used to create this type of build from within Eclipse has not caught up with this new feature. However if you really want it you can do the following

  1. Create a TFS build in Eclipse that drops to a UNC share
  2. Open the build definition in VS11
  3. Edit the drops location to point to a location in source control and save the build

    image
  4. When you trigger a new build and you should get you drops in source control. Note in the confirmation dialog you can see the source control based path but you can’t edit it (if you try you get an invalid path error)

    image

Team Explorer Everywhere is now free

It was announced overnight that TEE is now free. What does this mean?

It means if you do not have to buy TEE as some extra software if you already have a TFS CAL. This removed a barrier to adoption for developers who work in heterogeneous systems, there is no extra cost to integrate Eclipse as well a Visual Studio with TFS .

If you want to find out more about TEE why not come Black Marble’s free webinar I am delivering on the 19th?

Installing the TEE11 Beta as an upgrade to the plug-in in Eclipse

The big news today is is that Microsoft released the VS11 Beta, part of which is Team Explorer Everywhere (TEE). (Oh they also release something called Windows 8 too – whatever that is)

Whilst upgrading my TEE instance in Eclipse (Indigo) I hit the same gotcha as I had when I originally installed TEE (in Eclipse is in your ‘c:\programs files’). On Windows, if UAC is enabled you have to run Eclipse as administrator to do the plug-in else you get the error message.

image

As soon as you start Eclipse as administrator the upgrade works perfectly, you can then restart Eclipse as normal and all is OK

Thanks to everyone who came to my session at NEBytes last night

Thanks to everyone who attended my session at NEBytes last night, sorry I had to rush away. As my session was demo based I don’t have much in the way of slides to upload, but if you want to find out more have a look at my guest blog post on the UK Visual Studio blog on ‘TFS for Everyone’.

Also keep an eye on the Black Marble site for upcoming free webinar sessions on the same subject

Speaking on the 15th Feb at the NE Bytes user group on “TFS for Everyone”

I will be speaking at the NE Bytes user group next Wednesday (the 15th of Feb) on ‘TFS for Everyone’.

This a session based on the guest blog post on the UK Visual Studio blog  I did on how TFS is not just for .NET developers. It can be used from a whole range of development platforms and operating systems. I will be including demos using Eclipse and Ubuntu.

Hope to see you there.

Updated 9 Feb 2012 – here is the registration link http://nebytesfeb2012.eventbrite.co.uk