Re: [platform-team-dev] Internal ChangeSet API and Eclipse 3.2

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

Mark,

Since 3.2 development is essentially
frozen at this point, we cannot even consider reinstating any of the internal
code relating to change sets that was removed between 3.1 and 3.2. Unfortunately,
If you need to have change sets in 3.1, you will either need to use internals
or you will need to rewrite much of the synchronization framework. If you
decide to use internals, there are no gaurantees of compatibility with
future releases of Eclipse so you will need to support multiple feature
versions.

This is regretable but the architecture
of the subscriber based synchronization support in 3.1 was just not in
the right shape to open up the content provider as API. However, in 3.2,
the architecture has been changed to use the Common Navigator framework
to provide model-based content providers. For CVS, the change set support
is just another type of model. This means that you can write Subsclipe
specific change set support in 3.2 in a similar way without using any internals.
Of course, the task may be simpler if you reference internals but, if you
do, you may end up in the same boat as you are now.

Michael

Mark Phippard <markp@xxxxxxxxxxxxxxx>
Sent by: platform-team-dev-bounces@xxxxxxxxxxx

05/16/2006 02:59 PM

Please respond to
Generic team support framework

To	Generic team support framework <platform-team-dev@xxxxxxxxxxx>
cc	Brock Janiczak <brockj@xxxxxxxxxx>
Subject	[platform-team-dev] Internal ChangeSet API and Eclipse 3.2

We are trying to add support for Outgoing ChangeSets
in the Synchronize 
view within Subclipse.  We need to support this feature in Eclipse
3.1+. 
As you are well aware, this is all still internal API, even at 3.2.  Users
do not really care, they want the feature and do not want to wait for some
future version of Eclipse to get the feature.

We were hoping to provide something that worked in 3.1 and 3.2 and then,
assuming there is a public API in the next release, we could jump to that
version.

That being said the API has changed enough between 3.1 and 3.2 that this
currently seems impossible without having different versions of Eclipse
for each version.  Is there any chance of reinstating some of the
3.1 API, 
marking it deprecated, and perhaps having it internally use the new 3.2
API?

In particular, these are the errors I am seeing with our working 3.1 code
when trying to compile in 3.2:

The import 
org.eclipse.team.internal.core.subscribers.SubscriberChangeSetCollector
cannot be resolved
The method add(IResource[]) in the type ActiveChangeSet is not applicable
for the arguments
The method createSet(String, IFile[]) in the type ActiveChangeSetManager
is not applicable for the arguments

Thanks

Mark



_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email Security Management Services powered by MessageLabs. 
_____________________________________________________________________________
_______________________________________________
platform-team-dev mailing list
platform-team-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-team-dev