Saturday, May 24, 2008

Visual Studio Add-in suckage - part deux

As you can see, I have managed to slap together some rudimentary integration of JIRA with Visual Studio. You can log in to JIRA, download saved filters, run them and display filtered issues. Adding other functionality exposed by JIRA SOAP and RSS interfaces should not be a problem.

But there is another problem: integration as it looks right now is pretty useless. And it seems that due to Visual Studio's automation interfaces being somewhat limited in functionality there is not much I can do about it.

See, the whole point of integrating JIRA (or whatever other external tool) with IDE is automation of workflow. For JIRA, that would be mostly task flow automation. You would want to:
  1. select a task from some list of tasks
  2. work on it for some time, potentially finishing the task
  3. commit files you have modified during your work
  4. report time spent on a task (if you are one of these old-school project management enthusiast and don't believe in agile ways, for which individual effort tracking is sort of pointless)
We already support this in our IDEA plugin, mostly by means of:
  • standard and very potent VCS interface
  • built-in support for change sets (sets of files modified after being checked out of the repository), into which we could plug in
We are still far away from the completeness and automation of Mylyn's task support, but even today you can:
  1. list issues based on some filter
  2. assign an issue to yourself
  3. create a change set based on an issue key and make it active
  4. modify a bunch of files, which will land in this change set
  5. commit the whole change set in one go, automagically using the issue key as a part of commit message, so that information about committed files lands in JIRA
Now, with Visual Studio, the last three steps seem to be absolutely impossible to implement using its extensibility interface. The crucial window - Solution Explorer, does not expose any automation interfaces, and does not support filtered views. The only way to "filter" files is to exclude them from the project. Which is an absolutely dumb thing to do, because then they will not be a part of the build! Moreover, Visual Studio's VCS interface (MSSCCI) is not used by two of the most popular Windows Subversion clients - TortoiseSVN and AnkhSVN! I could theoretically (although it would be as pleasant as pulling teeth) use a command line SVN client. But without some way to show sets of modified files (like in IDEA's changesets), I don't think I can do anything.

It would really really (and I do mean realy) suck if I had to create my own source file tree views, detect file modifications (especially because of non-standard SVN client APIs) and synchronize these views with main "solution explorer" view somehow.

On the positive side, C# continues to be quite decent. Also, the whole System library has been quite nice to use so far. My only nitpick is that I would make public member variables first-class properties. It is dumb to have to write a getter and setter for a read/write int-type property (not that Java is any better in this respect mind you).

Oh, by the way, you can grab sources of the visual studio plugin here


  1. Told ya :)

    BTW. What if the language is quite decent and has good library if you can't do anything useful with it?

    Welcome to the MS world!

    PS. Ask Marek how we implemented "REFRESH" feature in the calendar directory in Outlook - ROTFL

  2. Maciek Gorywoda30 May, 2008 12:40

    It seems that I cover much of the procedure you described - with the use of a Python script, programming a completely new e-mail handler for JIRA (Essentially, every cvs commit triggers an e-mail to JIRA) and my own JIRA plugin form work time tracking.
    Connecting JIRA with an IDE... no, I think I would prefer to keep them separate.

  3. @maciek - well, think again. Just take a look at Mylyn and how it integrates JIRA (and a bunch of other bugtrackers) into Eclipse. The productivity increase from having task-based IDE view is quite significant

  4. Maciek Gorywoda10 June, 2008 14:14


    But as you noticed, sometimes certain problems are just too hard to overcome. Yes, if there was an ideal IDE with all this integration implemented, I would be happy to tell other developers in my company about it. But since we code under Linux, we can't even use that Visual Studio. Most of us use SlickEdit and I don't think there's any possibility to smoothly integrate it with JIRA.