Is there anyone maintaining Tree Surgeon?

May 14, 2012 at 8:32 AM

Is anyone maintaining Tree Surgeon?

 

Assuming no, does anyone have any idea on how to get commit status, or do we just have to fork the code?

 

maLcoLm.b.anderson@PragmaticAgility.com

Coordinator
May 14, 2012 at 1:04 PM

I'm still the maintainer but nothing is being done to it right now.

May 14, 2012 at 5:10 PM

Hi Bill


Text is a horrible medium for communicating passions. 

The words used to express one person's commitment to pushing forward the potential of a project can easily be misunderstood as hateful complaining.

I'm hoping that my words to not come across as hateful complaining.

 

So what can be done about the lack of activity on the Tree Surgeon project? 

I submitted a patch 15 months ago that is apparently still being evaluated.

As of this morning, tree surgeon will not build out of the box (on a win7x64 box with VS 2010 running go.bat crashes),

nCover is no longer a free product (and should probably be removed from the product),

there was talk last year of changing things up and creating a modular architecture allowing developers to write plugins.  There were 3-7 people who were interested in that thread, but no committers responded to user requests for guidance.

 

Is there a plug into to Visual Studio that makes tree surgeon redundant?  Is there another app that does tree surgeon better than tree surgeon.

If the answer to either of these is yes, then maybe we should shut the project down and update the docs with a link to that other product.

 

If the answer is no to both questions, then what can we do to breath life into this product?
What would it take to find a committer that can devote the time to make this active again?

 

I've got the desire, and would be happy to take it on, but I'll be honest, I don't know the full extent of what all is involved in becoming a committer.  I've worked around open source projects, and understand some of the issues that circle it, but I've never been in the circle.  Tree Surgeon is the only open source project that I've ever cared enough about to want to submit a patch to it. 

 

What can be done to make this project active?

May 31, 2012 at 9:59 AM

Hi,

@Bill this is a great app. I have used it for a few years now and really love it. 

@Malcolm I required some dramatic change to the templates that could not be done with the existing tree surgeon code (or could be done but with loads of work). So I wrote a script that basically clones a folder, renames folder and files and does a search and replace on non binary files. This provides me with enough functionality to create new projects in the format that I prefer.

If you are interested you can check out the script and how to use it on http://lazycowprojects.tumblr.com/post/24120400613/project-templating

 

Coordinator
May 31, 2012 at 1:19 PM

Malcolm,

First off let me apologize for the patch. I totally dropped the ball on it. Not sure if I even looked at it. I know the patch system here doesn't alert people to submitted patches (or didn't in the past) but if I said I was going to look at it, I didn't.

A lot of things have happened in the past year or two and it might make things redundant here. This might be paritally why I sat on the patch (besides being lazy or not reacting to it). There are a few competiting technologies that might make Tree Surgeon obsolelte. So let's go over where things are in Visual Studio right now and what we might do about it from a TS perspective.

First off there's the T4 templating system that's now baked into Visual Studio. Scott Hanselman has a great post on it here: http://www.hanselman.com/blog/T4TextTemplateTransformationToolkitCodeGenerationBestKeptVisualStudioSecret.aspx which has links to some tutorials.

From first glance at T4 (and to be honest I haven't done anything except tinker with it) it looks like Tree Surgeon. The templates look pretty much like what we use, except we're using code to search and replace tokens. With T4 it's built in.

Now having said that you still need to do some magic with T4 templates to make them work as they can't tell if you wanted this type of project or that type.

If TS was written today, it would probably use T4 as the templating engine instead of the one it uses now. That would eliminate a lot of the heavy lifting and probably make the system a little more robust, dynamic, etc.

So there's that.

Then there's the elephant in the room, NuGet.

I personally worked on NuGet with Microsoft and have a lot of passion for it. With NuGet you can just type something like "Install-Package ScaffoldApp" and have a complete application built out for you. Scaffolding is something that was introduced with ASPMVC but it's a fairly generic concept and basically what Tree Surgeon does. With NuGet, scaffolding is easy and you just have some scripts and whatnot combined with files (potentially T4 templates) and the system will build out for you.

Early on in NuGet I considered that TreeSurgeon could just become a NuGet package. However at the time it was still difficult to get something going (NuGet requires a project to start with so that was a bit of a show stopper). However some other scaffolding systems seem to work well (the MVC ones come to mind) so there might be an opportunity there.

The other option is a Visual Studio plug-in as there are a few that will create new projects for you (the HTML5 one comes to mind) complete with all the fixings.

In any case, if a new project was created in Tree Surgeon, I'm almost certain it should use NuGet to fetch the third party references.

Herein lies a bit of a dilemma with TS. For example when I start a new project I just go through the File > New Project and pick some appropriate starter (say a Windows Phone 7 application). Depending on the app platform (WP7, Web, WinForms, WPF) there are a set of packages that I'll just go and install (like Ninject or MVVM Light or something, along with some platform specific ones). It takes me 5 minutes but then I've got a scaffolded project that's ready to go (ala Tree Surgeon).

However two things come to mind. First off, these are installed with NuGet and some people still haven't jumped onto that band wagon. So I think there should be a decision here. Tree Surgeon requires NuGet. That way, the dependencies and whatnot for getting these packages works. That's one of the issues with the current codebase (and why talk of a plugin system was going on). The third party components come and go. We need a system to manage them without having to get a new version of Tree Surgeon every time a new build tool comes out. That plugin system was NuGet (except Nuget does it much better).

Okay, getting past that hurdle then the issue of how to serve up the tool so that a) its easy to get/use/access and b) it supports all the configurations that are out there. There are a *lot* more platforms than when Tree Surgeon started. TS was meant to be a solution starter so it would create your app along with unit test project and a client. The only problem is things like ASPNET MVC came along and already has the unit test framework generator built into the project creator. That sitll leaves WinForms and WebForms projects in the dust though and future of some of these (how many people start WebForms projects these days and where is WinForms going to be in a year when we have Win8 that doesn't support creating them in VS2012).

Pile on top of that the multitude of platforms available now. WPF, Silverlight, MVC, WebForms, WinForms, WP7. How many and how to support/include any or all of these in Tree Surgeon.

Maybe I'm making a mountain out of a molehill but the landscape has changed and I think Tree Surgeon needs to change with it. The question is in what direction?

Coordinator
May 31, 2012 at 2:54 PM

Posted this in a blog entry today here: http://weblogs.asp.net/bsimser/archive/2012/05/31/tree-surgeon-alive-and-kicking-or-dead-and-buried.aspx

Let's see if we can get some more traction on this.

Jun 21, 2012 at 8:05 AM
Hi Bill

It looks like a heck of an interesting project and I'm interested in doing it.

I've seen so many projects that couldn't put unit testing and CI together to save their lives.

Tree surgeon used to be my goto tool to show people how to structure their projects and the bonus was that the nant script provide pretty much everything needed to make a single task entry in ccNet and have them up and running.

My coding skills are rusty, as I've been doing Scrum coaching for the last handful of years but I've always been a heck of a maintenance programmer, so count me in on a T4 implementation.

Thanks

Malcolm Anderson




On Thu, May 31, 2012 at 5:19 AM, bsimser <notifications@codeplex.com> wrote:

From: bsimser

Malcolm,

First off let me apologize for the patch. I totally dropped the ball on it. Not sure if I even looked at it. I know the patch system here doesn't alert people to submitted patches (or didn't in the past) but if I said I was going to look at it, I didn't.

A lot of things have happened in the past year or two and it might make things redundant here. This might be paritally why I sat on the patch (besides being lazy or not reacting to it). There are a few competiting technologies that might make Tree Surgeon obsolelte. So let's go over where things are in Visual Studio right now and what we might do about it from a TS perspective.

First off there's the T4 templating system that's now baked into Visual Studio. Scott Hanselman has a great post on it here: http://www.hanselman.com/blog/T4TextTemplateTransformationToolkitCodeGenerationBestKeptVisualStudioSecret.aspx which has links to some tutorials.

From first glance at T4 (and to be honest I haven't done anything except tinker with it) it looks like Tree Surgeon. The templates look pretty much like what we use, except we're using code to search and replace tokens. With T4 it's built in.

Now having said that you still need to do some magic with T4 templates to make them work as they can't tell if you wanted this type of project or that type.

If TS was written today, it would probably use T4 as the templating engine instead of the one it uses now. That would eliminate a lot of the heavy lifting and probably make the system a little more robust, dynamic, etc.

So there's that.

Then there's the elephant in the room, NuGet.

I personally worked on NuGet with Microsoft and have a lot of passion for it. With NuGet you can just type something like "Install-Package ScaffoldApp" and have a complete application built out for you. Scaffolding is something that was introduced with ASPMVC but it's a fairly generic concept and basically what Tree Surgeon does. With NuGet, scaffolding is easy and you just have some scripts and whatnot combined with files (potentially T4 templates) and the system will build out for you.

Early on in NuGet I considered that TreeSurgeon could just become a NuGet package. However at the time it was still difficult to get something going (NuGet requires a project to start with so that was a bit of a show stopper). However some other scaffolding systems seem to work well (the MVC ones come to mind) so there might be an opportunity there.

The other option is a Visual Studio plug-in as there are a few that will create new projects for you (the HTML5 one comes to mind) complete with all the fixings.

In any case, if a new project was created in Tree Surgeon, I'm almost certain it should use NuGet to fetch the third party references.

Herein lies a bit of a dilemma with TS. For example when I start a new project I just go through the File > New Project and pick some appropriate starter (say a Windows Phone 7 application). Depending on the app platform (WP7, Web, WinForms, WPF) there are a set of packages that I'll just go and install (like Ninject or MVVM Light or something, along with some platform specific ones). It takes me 5 minutes but then I've got a scaffolded project that's ready to go (ala Tree Surgeon).

However two things come to mind. First off, these are installed with NuGet and some people still haven't jumped onto that band wagon. So I think there should be a decision here. Tree Surgeon requires NuGet. That way, the dependencies and whatnot for getting these packages works. That's one of the issues with the current codebase (and why talk of a plugin system was going on). The third party components come and go. We need a system to manage them without having to get a new version of Tree Surgeon every time a new build tool comes out. That plugin system was NuGet (except Nuget does it much better).

Okay, getting past that hurdle then the issue of how to serve up the tool so that a) its easy to get/use/access and b) it supports all the configurations that are out there. There are a *lot* more platforms than when Tree Surgeon started. TS was meant to be a solution starter so it would create your app along with unit test project and a client. The only problem is things like ASPNET MVC came along and already has the unit test framework generator built into the project creator. That sitll leaves WinForms and WebForms projects in the dust though and future of some of these (how many people start WebForms projects these days and where is WinForms going to be in a year when we have Win8 that doesn't support creating them in VS2012).

Pile on top of that the multitude of platforms available now. WPF, Silverlight, MVC, WebForms, WinForms, WP7. How many and how to support/include any or all of these in Tree Surgeon.

Maybe I'm making a mountain out of a molehill but the landscape has changed and I think Tree Surgeon needs to change with it. The question is in what direction?

Read the full discussion online.

To add a post to this discussion, reply to this email (treesurgeon@discussions.codeplex.com)

To start a new discussion for this project, email treesurgeon@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Jul 9, 2012 at 11:25 AM

Just a quick note here to say that Tree Surgeon was one of the first ways I learnt about CI, good project structure, source control practices and so on. I think it's an excellent learning resource if nothing else and if it can be updated to reflect today's 'best practices' - whatever the consensus is that they are - then it's worth doing. I'd be happy to help out if an extra pair of hands is needed.