Plugin option

Sep 19, 2013 at 12:34 PM
Hi,
do you have planned a plugin option for this application?
If not, would you welcome an Implementation for plugin option in this application with MEF (Managed Extensibility Framework )?

Best regards
Mani
Coordinator
Sep 19, 2013 at 12:36 PM
Hi Mani

I'm not following. Do you mean the TFS Build Manager? We ship it as an extension on the gallery.

Mike
Sep 19, 2013 at 12:50 PM
mikeFourie wrote:
Hi Mani

I'm not following. Do you mean the TFS Build Manager? We ship it as an extension on the gallery.

Mike
Hi Mike,
Yes, i do mean the TFS Build Manager.
Since we do want to make some changes to the application to make it fit our requirements,
we wanna make sure, our changes would not be overwritten with a new version.
The idea is to implement our code in a plugin, so it will be safe when you release new versions.

Mani
Coordinator
Sep 19, 2013 at 1:03 PM
ok. you could submit a patch if you like and if it benefits everyone we could include it directly in the code base. alternatively you could provide a patch that gives you the extension points you need and we could implement that into the code. I'm still a little hazy on the extension points, but I'll let you clarify with the patch. It may be best to just raise an issue and attach full code there.

Cheers

Mike
Developer
Sep 19, 2013 at 1:11 PM
What kind of extensibility points do you had in mind?

Simple extensibility points, like for example adding context menu options?

Or something more complex?

Can you give us some examples of the scenarios and use cases that you had in mind?

As you can imagine adding extensibility is probably a non insignificant effort. The number of users who would benefit from that would probably be very reduced.

But before saying it is so, I would like to understand what kind of mechanisms you had in mind.

If your changes are generic enough, perhaps you might consider submitting a patch so that it can be useful to other users as well?
Sep 19, 2013 at 1:42 PM
At this time, we just need some changes in the clonebuild methode:
  • change some of our own variables in the build process parameters
  • generate a default build name with our rule
  • change the working folders (Build Agent Folder) depending on the branch name
I'm still working on our code for those changes,
so i'm thankful, if you could give me some ideas to do the changes in an generic way,
so you could include the code them for those, who need to do the same changes too.

Thanks a lot

Mani
Developer
Sep 19, 2013 at 5:06 PM
manatwork wrote:

It seems you want more than just adding context menus.
At this time, we just need some changes in the clonebuild methode:
  • change some of our own variables in the build process parameters
That might be hard to do generally depending on the rules of the change. For simple stuff would be doable.
  • generate a default build name with our rule
This could be implemented with a user configurable cloned build expression (using simple macros for example) but I bet macros would be limited and probably cover only the simplest scenarios.
  • change the working folders (Build Agent Folder) depending on the branch name
I'm curious what kind of changes you are doing here. Can you give some example? What need is driving this?
I'm still working on our code for those changes,
so i'm thankful, if you could give me some ideas to do the changes in an generic way,
so you could include the code them for those, who need to do the same changes too.
I guess this is doable in a generic way, if we introduce the concept of hookable events. People could add code to hook to these events.

For example in your particular case we could either add events like BeforeClone or BeforeCloneSave or AfterCloneSave (just giving some examples, these are badly named and should be better evaluated) that would allow execution of extensible code.

While in terms of coding such a solution wouldn't be very hard. It would need to be well thought, since an initial bad model could hinder future developments (unless we decided break backwards compatibility to move forward).

It would also imply some re factoring to externalize that is public and what is not.

I'm being totally honest here. We have limited resources (heck we don't have any) and at this time (my personal opinion only) we still have features that can be included in the out of the box experience before spending resources on a feature that would only be usable by a very small set of users.

But this is a community driven project, you can enter a feature request on the issues section for which people can vote or even better submit a patch which we will evaluate for future inclusion.

Thanks for your ideas