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

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

mylar-dev-bounces@xxxxxxxxxxx wrote on 12/06/2006
03:24:55 PM:

> 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? 

The issue is that you cannot guarantee backwards compatibility
if you expose internal classes in an API. If you do not require backwards
compatibility, then either approach you suggestwould work. However, if
you want future versions of Mylar to be backwards compatible the current
version you would need to make any classes that references internals internal
as well.

> 
> 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
> 
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev