Brock Janiczak <brockj_eclipse@ihug.com.au> wrote on 11/16/2004 05:04:38
AM:
> Hi Mark,
> Thanks for loking over my changes.
>
> Mark Phippard wrote:
>
> >That sounds like the right way to accomplish this, if it is a goal. My
> >only question would be that this only makes sense to do if we know
there
> >are some other plugins out there that want to consume this extension
> >point. Otherwise, it is a lot of work for something that could just be
> >hard-coded. So, do we know that?
> >
> We don't know who will use the extesion point (if anyone). The only use
> cases i could think of were a bug tracking system (ie a bugzilla or jira
> issue number) and perhaps company defined meta data (perhaps for
> documents). I am not really sure if we should even consider adding bug
> tracking support directly into the core plugins. It would make more
> sense to have them as optional components.
Please read the spec again:
http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
The goal is to make a common system that all svn "GUI's" could support so
that there was some consistency across clients. Also, you seem to be
operating under the misconception that the integration is based on
properties. It does use properties, but only as a way of communicating
configuration to the GUI. In other words, the properties exist to "turn
on" the integration in the GUI. Without the properties, the GUI would
behave the same as it did before it added the integration.
There are two main UI elements to the integration when it is turned on:
1) The commit dialog adds a field to collect Bug ID's associated with the
commit. It then automatically adds this info into the commit message so
that it is formatted consistently without requiring the user to type the
info.
2) The "svn log" UI in the GUI should parse the task ID's back out of the
log messages and provide a UI for executing a URL to view the task ID.
Tortoise does this by just turning the bug ID text into a hyperlink, but
it could be done in any way that was appropriate for the UI.
I do not see how either of these items could realistically be done by the
bug ID vendor. It pretty much has to be part of the base GUI. That is
why we defined the use of properties as a way of communicating the
configuration to the GUI.
> The main reason for using an extension point is to allow us to add
> properties without requiring code changes (i really hate mixing data and
> code).
If you do not mind doing it, it is a good idea. However, at some point
the list still has to be coded somewhere. You are just doing it more
abstract. Personally, I would hard-code the known list of properties, and
if we wanted to let a user define their own, there are a number of ways we
could do it:
1) In Preferences, provide a page where the user could define property
names. The negative here is that it would be machine specific, although
preferences can be exported.
2) We could do something similar to what we did in the bug tracking spec.
Define a property name like "properties" whose value is a comma-delimited
list of custom property names. The GUI would then "discover" this
property in the WC and use it to populate the drop down. The advantage
here is that since this is stored in the repository it gets pushed to the
client when they checkout their WC.
> >PS - Your extension point Schema currently shows an error in the
Problems
> >view.
> >
> >
> Could you send me the text of that error please? It doesn't show up for
> me. The only thing i noticed is that the plugin.xml had some unicode
> characters (i have removed them).
I am using Eclipse 3.0.1, if it matters. The error is on line 61 of
svnPropertyTypes.exsd. The text is: "Element "svnPropertyTypes",
attribute "type": when "use" is "default", "value" must be set"
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Wed Nov 17 01:10:43 2004