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