I spent this morning working with a client who will be using Eclipse and Teamprise client to support their ongoing Java break/fix work while they migrate their application to .NET. Both teams want to use (the same) Team Foundation Server so that work items, version control, and automated builds are shared between all.
These are some questions that came up during a simulation that we ran through this morning, as well as some answers back from Martin Woodward of Teamprise. I wanted to share with anyone else who might have similar questions.
Q. Is the Annotate command available from within Eclipse?
Not yet. We have this in Teamprise 4.0 which we will be releasing to sym-ship with TFS 2010 RTM. We’ll be having previews available of Teamprise 4.0 during the 2010 Beta 2 period as well as having a Teamprise 3.3 version which will work against TFS 2010 but not have the TFS 2010 features (follow history on merge, branches as first class citizens, hierarchical WIT etc).
Q. Get Latest on Check-out, if configured at TFS does Eclipse play nice with that option or does it ignore it?
The Teamprise clients have a preference for this feature. Currently we do not look for the server side setting in TFS 2008 as our support of Get Latest on Check-out predated when Microsoft added it to TFS.
Q. Are the Eclipse check-in policies completely different than Visual Studios? In other words when I enable the Work Items policy in Eclipse do I have to also enable it in Visual Studios?
Yes. Java and .NET check-in policies are completely independent. This is because of the programming model behind them (i.e. .NET ones implemented in .NET, Java ones implemented in Java). For more information on implementing custom Java check-in policies if you need to see the Teamprise Check-in Policy SDK. However we ship with additional policies to the Visual Studio client so hopefully you won’t have to.
Q. Do you have any guidance (such as “don’t do it”) for having both Eclipse and VS use the same workspace and possibly edit some Java project files in Eclipse and others in VS?
You can do it – and it will work fine. The only problem is that the pending changes manage in each would need a refresh (press the refresh button) if you are editing in one application then switch to the other so that it knows about pending changes created in the other application. That said, we’ve found people find it easier to understand if they keep to the rule of 1 Eclipse workspace == 1 TFS workspace, therefore creating a new workspace to work in for the Eclipse development is probably easiest but not necessary.
Q. Does your Remote Accelerator product work fine for both Eclipse and VS on the same desktop?
Yes, works for any TFS client on the same machine that talk the correct TFS protocol. The only restriction is that it is single user – i.e. the person running the accelerator process must be using the same credentials to talk to TFS as the client application is using to talk to TFS. This is enforced by the Accelerator.
Q. If you want to call a specific target within the Ant build.xml file, can you specify this in the MSBuild command-line arguments textbox when queuing a build, will it’ll trickle down to Ant?
If you want to call the same target every time, then you can edit the <targets></targets> attribute in the AntBuildFile itemgroup as defined in the TFSBuild.proj file. If you want to be able to optionally pass one through as MSBuild arguments in the Queue Build dialog then you would but the variable that you wanted to use in the targets attribute (i.e. <targets>$(AntTarget)</targets>) and then optionally specify the property in the dialog ( -P:AntTarget=myTarget)
Q. The .trx file generated by JUnit – is that Teamprise that generated it and I’m guessing it’s pushed to the data warehouse automatically?
Yes. JUnit targets need to output results using the xmlformatter (as standard). The Teamprise Build Extensions then look for the JUnit result files and transform them into the trx file format. They then call MSTest.exe with the /publish parameter to publish the JUnit results to TFS which in turns gets automatically pushed to the warehouse. Note that as we are using MSTest the build server needs a “team” version of visual studio installed on it (Team Dev, Team Test or Team Suite) for the publish functionality to be enabled. You can get the Teamprise Build Extensions and look at the source code (under the MS-PL) if you want to understand better how it works.
Q. Is there any support for JUnit code coverage?
For code coverage you can still produce the usual Java reports and have them included in the build drop location, however there is currently no way to publish code coverage data to TFS for Java applications. This is due to the way that the code coverage results format is tightly bound to the PE (windows portable executable) file format. We’ve been working closely with the team on this one and currently hope to have a solution in place after TFS 2010 RTM.
Note: These questions were based on Eclipse version 3.4.1 and Teamprise version 3.2.1.