Re: [platform-vcm-dev] Recommended way of using *internal* packages such

["Michael Valenta" <Michael_Valenta@xxxxxxxxxx>]

Vladimir,

We are currently still in the planning stages and are uncertain what, if any, API changes will be made in Team. If API changes do occur, we will make every effort to remain backwards compatible. However, if the right soluton to a problem involves breaking the the current API in a non-backwards compatible fashion, then we will likely make the change. It is worth noting that by "right solution", I mean a solution to a problem that is preventing repository providers from integrating well into Eclipse so any API changes will be to benefit repository providers. Also, if API changes do occur, it is our plan to provide documentation describing that changes and how to migrate from the old API to the new one.

Also in the works for 3.0 is addition Team API that will be optional for repository providers. Our desire is to provide several tools that repository providers can choose to use by implementing the new API (e.g. synchronize view). However, if they can choose not to implement the API if they do not want to use the tools.

As for the specific plan item you mentioned, the current plan is not to map a repository providers to any resource. It is to allow more than just the mapping repository providers at the project level. There are currently issues involving linked resources that are linked to projects that are shared with a repository provider (see bug 36685). It may end up that the only addition flexibility may be to map repository providers to folders that are direct children of a project so that the mapping matches that of linked resources. 

Information on the above items will be updated on the website and posted to this mailing list as work in these areas proceeds.

Michael

"Vladimir Grishchenko" <vladgri@xxxxxxxxxxx> Sent by: platform-vcm-dev-admin@xxxxxxxxxxx 22/05/2003 12:34 AM Please respond to platform-vcm-dev

To:        <platform-vcm-dev@xxxxxxxxxxx>         cc:                 Subject:        Re: [platform-vcm-dev] Recommended way of using *internal* packages such as SyncView?

One question I have after reading this document is how big of a change
should we expect in Team API after the new proposed resource control
architecture is implemented? Do you plan to make it transparent/almost
transparent for repository providers? I'm also not sure what would be the
benefit of being able to map a team provider to any resource, which kind of
implies that you can have a project whose memberts are in different
repositories. Sounds complicated...

Vladimir.


----- Original Message -----
From: Michael Valenta
To: platform-vcm-dev@xxxxxxxxxxx
Sent: Wednesday, May 21, 2003 5:46 AM
Subject: Re: [platform-vcm-dev] Recommended way of using *internal* packages
such as SyncView?



Greg,

We do not anticipate changing any of these classes in any future 2.X
releases. We are currently working on an improved syncing story for 3.0 that
will make it easier for team providers (and users) to use. This work is
being done in separate packages and will not effect the current sync view
implementation. For more details, please see the VCM Component 3.0 plan:

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home/do
cs/online/team3.0/milestone-plan.html

Michael



Greg Kim <gkim@xxxxxxxxxxxxxx>
Sent by: platform-vcm-dev-admin@xxxxxxxxxxx
20/05/2003 10:31 PM
Please respond to platform-vcm-dev

        To:        "'platform-vcm-dev@xxxxxxxxxxx'"
<platform-vcm-dev@xxxxxxxxxxx>
        cc:
        Subject:        [platform-vcm-dev] Recommended way of using
*internal* packages such as SyncView?





I created a Team Repository plugin to work with Eclipse 2.0x sometime
last year and haven't touched it until now. I've verified that my plugin
still works w/ 2.02, but I'm running into a compatibility problem on
2.1.

The problem is the following:
 org.eclipse.team.internal.ui.sync.SyncView

The method signature of findInActivePerspective(void) appears to
have been changed to findViewInActivePage(IWorkbenchPage). Yes,
this is one of those 'internal' classes, so it was just a matter
of time I guess...

I'm reusing lots of stuff in the org.eclipse.team.internal.ui.sync
package which is experimental and likely to change in the not
so far future.  In order to protect myself from compatibility
issues moving forward, I'm thinking about basically copying all
the ui.sync classes into my plugin.   And switch back once this
package becomes stable...

Anyone (especially Team Repository plugin builders, since there
appears to be more need for 'internal' classes) experiencing compatibility
grief such as these?

I ideally want to ship one plugin package that works on 2.x
(i.e. 2.02, 2.1, 2....).
Is there a better way of doing this?

I'm also extending from TeamAction (another *internal* class) to
handle all my Team actions.  Is there going to be a change to
this interface before 3.0?

Appreciate all the help,
thanks!
Greg

_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev