Re: [platform-team-dev] Re: Team API

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

I haven't been following this discussion so maybe this has already been stated elsewhere:

What are the kinds of operations a third party can expect to be supported via the TeamSubscriber/whoever API's?

e.g.
- commit changes in workspace
- update workspace to reflect 'latest' or 'current' state of the repository/remote
- is in sync with remote?
- version # or something else displayable/comparable
- etc.

It would be helpful to know from a third party caller's point of view what kind of generic capabilities he can expect.  For example, a somewhat common usage case is a kind of workflow management where the workspace changes must be committed before say the work is deployed to a production server.  An extension of that is being able to keep a deployment record so that you know which versions are deployed to your WebSphere App server etc.

Regards,
Kevin

Jean-Michel Lemieux/Ottawa/IBM@IBMCA Sent by: platform-team-dev-admin@xxxxxxxxxxx 12/03/2003 05:11 PM Please respond to platform-team-dev

To:        platform-team-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-team-dev] Re: Team API

Hi!

Re: plan item Improve Team API (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37705)

We have finished our priliminary evaluation of JSR 147 (WVCM).  We have 
always been interested in WVCM because it has industry backing and is a 
very comprehensive abstraction for modern versioning system capabilities. 
Although it would be a good candidate for a Repository Provider API in 
Eclipse Team, at this time the JSR is still under public review with a 
deadline of mid winter 2004 and a reference implementation is not yet 
available. This, combined with the lack of documentation and examples, has 
lead us to the conclusion that we cannot release an Eclipse Team API in 
3.0 based on a JSR that is still under review and not yet final. Instead, 
we plan on extending and modifying our current Team APIs and postpone WVCM 
to a later release of Eclipse.

Although we won't be including WVCM in Eclipse 3.0, we plan on extending 
the current Team API in the following areas:

- Refactoring of the internal Target Management classes (e.g. target 
supports non-versioning providers) into a public DeploymentProvider API. 
The Team API would then consist of DeploymentProviders (mapped to any 
folder, non-versioning, and light weight) and RepositoryProviders (mapped 
to projects, are versioning, and have control of workspace resources via 
move delete hooks and validateEdit/Save).
- Extending the TeamSubscriber API to support simple programmatic access 
to both Deployment and Repository providers. We will investigate how to 
make API both headless but allow UI to be shown when run in with a UI 
context. This API could someday be implemented by a WVCM provider.
- Extending the project set support for headless use and fixing some of 
the existing bugs.
- TeamSubscriber based QuickDiff provider.
- Synchronize View UI API based on TeamSubscribers.

Most of this work will be complete for M7.

Cheers,
Jean-Michel and Michael
_______________________________________________
platform-team-dev mailing list
platform-team-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-team-dev