[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vcm-dev] Breaking changes in org.eclipse.team.core
|
>>- The API defined in the StandardOperations class has not been decided on
yet. It will be changing soon.
More specifically, it won't be part of the central provider story. Rather,
it will serve two purposes:
1. support the "quick generic" provider implementation where they get the
checkin/checkout/etc. actions for free by implementing this API
2. act as a provisional/experimental API so that we can investigate third
party repository neutral opportunities. The "provisional" point is
important here: we fully expect that there may be better APIs to be written
in the future and don't want to preclude their existance or hinder their
adoption. For the moment, its simply useful to have a small interface we
can at least experiment with. Implementing the API is optional, and both
callers and implementors should expect that it could disappear in future
versions of Team.
The final step here is for us to figure out how to arrange the packages and
projects such that the delineation of "GenericOperations" from the central
architecture is clear. In addition, we intend to rename it to something
more specific.
We still have some details to polish in the API. We wanted to get it out
now for M4 so that we can start the process of helping people move to it.
Kevin McGuire
Jean-Michel_Lemieux@oti
.com To: platform-vcm-dev@xxxxxxxxxxx
Sent by: cc:
platform-vcm-dev-admin@ Subject: [platform-vcm-dev] Breaking changes in org.eclipse.team.core
eclipse.org
15/03/02 09:28 AM
Please respond to
platform-vcm-dev
As we head in to the M4 milestone, we have started implementing the changes
required to evolve the team API. These changes reflect the post made in
this newsgoup a month ago by Kevin McGuire.
These changes will BREAK all team provider plugins. Here is a summary of
the changes that have been made:
- The ITeamManager::setProvider/removeProvider method have been removed.
Instead, simply add/remove a team nature to the project instead.
- A provider (e.g. RepositoryProvider class) has a smaller minimum API to
implement and can opt out of implementing the standard operations such as
(get/checkout...) or the file modification validation.
- Using abstract classes instead of interfaces. This way we can provider
safe default implementations for certain methods and it allows the API to
evolve in the future.
- There is a new method for querying for the type of a provider. The
following pattern can be used:
RepositoryProvider provider = RepositoryProviderType.getProvider(project);
if(provider.isOfType(id)) {
}
- Events have been removed from team.core. The mechanism was too generic to
be useful and we couldn't think of how it was being used by many. We would
need some feedback on how others were using this mechanism generically.
- Move/rename/delete hooks are being added to the API.
- The API defined in the StandardOperations class has not been decided on
yet. It will be changing soon.
The API will continue to change in the next few weeks but should stabilize
soon. We will post any big changes to the mailing list.
Jean-Michel
