Thanks, I’ve already reviewed that doc
set.
-----Original Message-----
From: Michael Valenta
[mailto:Michael_Valenta@xxxxxxxxxx]
Sent: Monday, February 23, 2004
7:53 AM
To: platform-team-dev@xxxxxxxxxxx
Subject: RE: [platform-team-dev]
Fw: Team API Usage Question
The best place to get a summary of what Team provides
is the ISV doc which ships with Eclipse. It is available in the help doc in the
Platform Plug-in Developers Guide/Programmers Guide/Team support section.
Michael
"Paul Wuethrich"
<paul.wuethrich@xxxxxxxxxxx>
Sent
by: platform-team-dev-admin@xxxxxxxxxxx
20/02/2004 04:55 PM
Please
respond to
platform-team-dev
|
|
To
|
<platform-team-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [platform-team-dev] Fw: Team API Usage
Question
|
|
Btw, thanks for the replies…
Anyway, synchronization is something that is a requirement in
that a client will need to be aware of new versions of resources available in
the repository (i.e. that could have been made by other clients). Beyond
that, is there any core functionality that the Team infrastructure provides
that is best leveraged?
-----Original
Message-----
From: Michael Valenta [mailto:Michael_Valenta@xxxxxxxxxx]
Sent: Friday, February 20, 2004 2:45 PM
To: platform-team-dev@xxxxxxxxxxx
Subject: Re: [platform-team-dev] Fw: Team API Usage Question
It really boils down to whether there is value-add from using the Eclipse Team
infrastructure and whether it fits into your application. A new synchronization
API will be released shortly that provides a framework for managing the
sychronization state between the local workspace and a remote location. If this
is something your application requires, then it may be worth investigating it.
However, if all you need is simple puch/pull capabilities, you're probably
better off providing a small client that provides specifically what you need.
"Paul Wuethrich"
<paul.wuethrich@xxxxxxxxxxx>
Sent by: platform-team-dev-admin@xxxxxxxxxxx
20/02/2004 04:34 PM
Please
respond to
platform-team-dev
|
|
To
|
<platform-team-dev@xxxxxxxxxxx>
|
cc
|
<Michael_Valenta@xxxxxxx>
|
Subject
|
[platform-team-dev] Fw: Team API Usage
Question
|
|
Per Michael's suggestion below, I'm continuing the discussion.
The 3rd party requirements are virtually non-existent in this case and
the repository provider will be our own customized interface to an
rdbms. I'm guessing this doesn't change the suggested approach of
building it from scratch?
"Michael Valenta" <Michael_Valenta@xxxxxxx> wrote in message
news:<40367918.3080005@xxxxxxx>...
> Paul,
>
> The Team plugin (org.eclipse.team.core) is dependant on the resources
> plugin (org.eclipse.core.resources) so any RCP app that used team
would
> need to be IResource based at least for the resources under version
> control. Including the UI portion has further dependencies (i.e. you'd
> end up with most of the platform SDK plugins).
>
> Also, there is no Team API that allows third party tools to invoke
> repository funtionality. The API is really there to provide
integration
> points for repository providers. If you plan on using a particular
> repository type (e.g. CVS) you may want to investigate developing a
> small client that does only what you need.
>
> If you want to discuss this further, the platform-team-dev mailing
> list
> may be a better place.
>
> Michael
>
> Paul Wuethrich wrote:
>
> > The requirements are to provide team-like functionality to an RCP
> > application for version control over a small set of domain specific
> > files. The end-users will be "business" users and so a full
blown
> > CVS implementation is not required.
> >
> > The current plan is to extend the Team api. Is there any reason
NOT
> > to use the Team plugins and build the versioning functionality from
> > the ground up? I'm guessing not but I have limited experience in
> > this area and have used the CVS client and experimented with the
> > file system example.
> >
> >
> >
>
_______________________________________________
platform-team-dev mailing list
platform-team-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-team-dev