A Short History of the GAT Project
I though you might be interested in how it happened that PAG developed a VS extensibility mechanism. So here is a short, unedited, history of the project.
The history starts before I joined PAG two years ago. When I came onboard Scott Densmore (yes, the EntLib Scott) was experimenting with using the VS Enterprise Templates to make the PAG code-based guidance appear in VS. It was sometimes painful to see Scott trying to put a square peg into a round hole, so to speak. The main problem was that Enterprise Templates were designed to constrain what you can do, not to help you do things in the context of what you have already done. Scott's project was called Daedalus, and it was part of what we called IPE, which stood for In Product Experience.
We concluded that Enterprise Templates did not have what we needed, but we were neither ready to embark on building something else or new what that would be (yet). But here came Shadowfax, and Ed Jezierski (yes, the EntLib and CAB Ed) and I realized, that the architecture of the framework would have been simpler and easier to use, have we had a VS extensibility mechanism that would allow us to manipulate VS solution artifacts at the design time. We had a few initial ides of what that mechanism would look like, and we asked Daniel Cazzulino to build a prototype. This was bit over a year ago. The prototype came out quite interesting and promising, so we decided it was time to give IPE the second chance.
Our initial design objectives where quite lofty (aren’t they always?), and we asked the Whitehorse team to help us investigate if we should use the MDF (Meta Data Framework). This is how Stuart Kent ended up working with us for a couple of months and greatly contributed to the articulation of the key GAT concept; the recipe. It was about May last year when we prototyped enough of the design to start a development project. In PAG-speak it means that you assemble a project team and you push the project acceleration pedal all the way to the floor. The project was named IPG, which stands for In Product Guidance, and the team members were Tom Hollander (product management), Bill Loeffler (program management), Daniel Cazzulino and Oscar Calvo (development) , Ashish Babbar (testing) and your truly (architecture). The rest is, as they say, history, but this history has a few interesting twists and turns worth mentioning.
Once we realized that we were building a VS extensibility machines, we was time to go to VS team and "confessed". Our VS brethren didn't like a number of the details (parts of user experience in particular), but they did liked our ideas in general, so they assigned a, Stephanie Saad (VS core program management), to be our "guardian angel". Although not an important project milestone, this was to me a very important moment. It was the first real indication that we were up to something interesting. Over the course of next few months Stephanie helped us tremendously. In particular, when we were integrating recipes with new VS templates and we needed a few changes in VS core (aka DCRs).
Another interesting twist was deciding what GAT really was. Was it a piece of guidance, was it a product, or was it something in-between? This is where the Whitehorse team helped again. Julia Liuson, the Whitehorse team Product Unit Manger, and Jack Greenfield (yes, the Software Factories Jack), offered a home fo GAT under the emerging tools initiative. This is why you can find GAT on the VS workbenches site, next to DSL SDK.
Coming up with the "official" name was surprisingly hard. Until late in the project we were working on what we called "Recipe Framework" and what is now called guidance packages, we called recipe clusters. When confronted with the unavoidable need to give "it" a proper name, we proposed VS-IGT, that stood for VS Integrated Guidance Toolkit. I liked the name quite a bit, but techies have little to say when it comes to selecting names of things we release to communities. The marketing folks have a lot to say, and then did not like VS-IGT. After running around a number of circles, Tom finally worked out a compromise, and GAT got its name.
The last interesting tidbit (one day I will ask Stuart to write his side of the story) is that about mid way through the project (it was fall by then) the DSL SDK team and us realized, that independently we crated very similar text templating engines. Daniel wrote the GAT's T3 (stands for Text Template Transformations) and Gareth Jones form the DLS team wrote their nameless engine. The two engines were remarkably similar, so we decided to merge them. The review (Beta2) version of GAT still has T3 inside, but the Whidbey version will have the shared T4 engine (Stuart added one more T to out three Ts, so unless you know this bit of the project history, the name makes little sense).
Well, this is my recollection of what was worth sharing about the project. If I missed anything or anybody, my team member will certainly catch the omissions and blog about it.
-- Wojtek
