RE: [mylar-dev] enhancements in Mylar team API

["Mik Kersten" <beatmik@xxxxxxx>]

What Michael has made me realize is that while that there may be a
reasonable middle ground to walk here:

1) We pull out an abstract class for the layer that sits between the context
model and the ActiveChangeSet manager stuff.  That's what I was referring to
being easy to implement already via change set listeners, but by making it
an API we encourage non-ActiveChangeSet based providers to interoperate.

2) We make it very clear that the ActiveChangeSet-based facilities require
use of internal API, and continue to sure they're optional to implement.  I
might need to rename AbstractTeamRepositoryProvider to
AbstractActiveChangeSetProvider or something of that sort.

Michael: in terms of conventions, do you know if we have to mark our API
class that uses ActiveChangeSetManager as internal, or is it enough that the
class exposes internals? 

I'm working on this via bug:
166920: [api] address internal API usage of change set management
https://bugs.eclipse.org/bugs/show_bug.cgi?id=166920

We won't get (1) quite right for 1.0, because we don't have a
non-ActiveChangeSet based client for the API, so we may need to keep that
internal.  But hopefully it will be good enough to provide input for how it
should work in the Mylar 2.0 / Europa stream.

Mik

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Eugene Kuleshov
> Sent: Wednesday, December 06, 2006 12:08 PM
> To: Mylar developer discussions
> Subject: Re: [mylar-dev] enhancements in Mylar team API
> 
> Michael Valenta wrote:
> > I don't really view these as three different cases. CVS and Subversion
> > are very similar capability wise in this respect (i.e. neither have
> > the concept of a change set built in). I can see the argument that the
> > classes be made API so they can be used by other repository providers
> > that do not have the concept. However, there are repositories out
> > there that do have the concept and would therefore already have their
> > own implementations. You motivation fore maming the classes API seems
> > to be so that 3d party tooling like Mylar can use it. As I have said
> > before, this is a mistake. Mylar should have API that defines what it
> > requries from change sets but leave the implementation up to the
> > repository provider.
>   Right, but that team provider could of as well used that API to
> represent their change set model, or as you suggested to Mylar provide a
> bridge to that API.
> 
>   I a also agree with Mik that bridge is not too easy to implement
> because structures are relatively deep. We will have to do that in Mylar
> first, and then and then repository providers will have to do that again.
> > > Also, you said that team working on Platform/Team does not have man
> > > power for this. On the other hand there is at least 3 commercial
> > vendors
> > > are currently building team providers (p4, Subversive and
> > > Rational/Jazz). Would it be possible to request some man power for
> this
> > > task from those teams? In a result everybody will benefit from this.
> >
> > I find that the repository vendors are usually pretty resource
> > strapped as well (it seems to be a common affliction). However, if you
> > feel strongly about this, then I would suggest that you contact these
> > and other repository vendors to see if they are willing to participate.
>   I sort of hoped that you may already have some contacts. :-)
> 
>   regards,
>   Eugene
> 
> 
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev