RE: [platform-vcm-dev] More changes

["Clemm, Geoff" <gclemm@xxxxxxxxxxxx>]

I believe that there are several aspects of the TeamAction superclass
that need to be significantly modified before it is suitable for use
as a basic set of reusable functionality.  Our plugin will not be
supporting the TeamAction superclass, and will therefore not interoperate
with any plugin that depends on it.  Because of this, I strongly
support the decision to mark these classes as provisional.

On the other hand, Team currently provides a comprehensive basis
for concurrent interoperation with multiple Team providers through
the project "nature" mechanism, the GUI extensibility mechanisms
(including the Team menu), and the Team extension points
(ValidateEdit, ValidateSave, Move).

Perhaps you could identify the functionality that you require that
cannot be provided through the Team extensibility mechanisms?
This would be very useful in helping guide the development of a
standard TeamAction API.

Cheers,
Geoff


-----Original Message-----
From: Bryan Stephenson [mailto:Bryan.Stephenson@xxxxxxxxxx]
Sent: Tuesday, May 07, 2002 12:54 PM
To: platform-vcm-dev@xxxxxxxxxxx
Subject: Re: [platform-vcm-dev] More changes


The decision to move all of these classes to the internal package means that
provider implementers
cannot rely on their continued presence and using "internal" classes is
frowned on from the stand point
of the "Ready for WebSphere Studio" program.

<from Ready for WebSphere Studio >
The use of internal interfaces is discouraged as they are subject to change
without notice. Changes to an internal interface may disrupt or disable your
plug-in which would trigger support and rework costs for your development
team. Approval will be given based on the pre-test report submitted with
your Ready for WebSphere Studio application. Vendors wishing prior approval
should contact (name and e-mail).

While their functionality is not essential to any provider's implementation,
they do serve as a reasonable starting point.

I feel that the generic TeamAction  super class should remain in the public
API as it provides a good basic set of reusable functionality.  Both the CVS
and examples use TeamAction (and other components).   The implication of
this change is that the examples and the Eclipse CVS provider are
"discouraged" in terms of the    Ready for WebSphere Studio criteria.



Bryan Stephenson

----- Original Message -----
From: <James_Moody@xxxxxxx>
To: <platform-vcm-dev@xxxxxxxxxxx>
Sent: Tuesday, May 07, 2002 4:32 PM
Subject: [platform-vcm-dev] More changes


> The classes in org.eclipse.team.ui.actions have been moved to
> org.eclipse.team.internal.ui.actions effective tomorrow's integration
> build.
>
> These classes were marked as provisional API, and our rationale for
> making
> them internal is the same as for the sync view.
>
> We may change them upon feedback & review, so having them as internal
> gives
> us greater flexibility to do so.
>
> james
>
>
> _______________________________________________
> 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