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

[Michael Valenta <Michael_Valenta@xxxxxxxxxx>]

Mik,

The most obvious approach from a Mylar
perspective is to provide interfaces that define what Mylar requires in
terms of Change set support. Then, it would be up to the repository provider
to decide how to implement the interfaces. The bridge from the Mylar interface
to the ActiveChangeSetManager would then just be a wapper that delegate
to the ActiveChangeSetManager. Of course, the wrapper would need to perform
any transformation required to map from the internal Team ChangeSet to
the Mylar version but that should be straight forward. Repositories that
have their own concept of a change set are free to implement the bridge
in the way thatmakes sense for them without requiring them to use any of
the Team classes.

In your last paragraph, you seem to
say that it won't be a problem for repositories that have their own change
set support to integrate with Mylar. Are you saying that they could do
so without using the internal Team classes? If they can do it without using
the internal Team classes, then I may have misunderstood the implications
of what I read on the Wiki. 

In regards to your (and Eugene's)  comment
on providing a homogeneous experience accross repository providers, this
was attempted in Eclipse 1.0 and was a dismal failure. That doesn't mean
that it shouldn't be investigated. What it means is that it can only succeed
if the majority of repository vendors are involved in the specification
of the API (Eugene mentions a few butthis is a small fraction of the vendors).
JSR 147 was one attempt at this but it has not made much headway because
the problem is actually very complex. I think the approach taken by Mylar
is much more likely to succeed (i.e. to define the requirements of the
tooling and allow repository providers to provide bindings to the API).
As Mylar gains momentum, we should see more repository vendors providing
Mylar integration. Also, other tools may start using the API for other
purposes. In both cases, changes to the API may be required to accomodate
new uses.

I think it is important to note here
that none of what I have mentioned requires API in the Team component.
All it requires is that the API be in a place that is accessible to repository
tooling and 3rd party tools. In reality, putting the API in the Team component
could actually be detrimental as it would "freeze" the API prematurely
(i.e. before the majority of repository vendors or 3rd party tools had
a chance to give input). I think Mylar is the logical starting point for
this API. If the API starts to have broader applicability, it could be
moved to another location (perhaps it's own technology project). That's
not to say that all the issues you mentioned fall into this category. I
believe bug 89806 is one that should be solved by the Platform but I think
it needs to be solved the right way as outlined in the bug report.

Michael

"Mik Kersten" <beatmik@xxxxxxx>

12/06/2006 02:56 AM

To	Michael Valenta/Ottawa/IBM@IBMCA
cc	"'Mylar developer discussions'" <mylar-dev@xxxxxxxxxxx>
Subject	RE: [mylar-dev] enhancements in Mylar team API

Michael,
 
I have tried a second time now
to take your suggestion on this, and ran into the same problem.  On
the technical end of things, having Mylar provide its own change set API
is a huge undertaking because it involves a significant amount of implementation
that parallels the existing org.eclipse.team.internal.core.subscribers
implementation.   It’s not just ActiveChangeSetManager, but also
ChangeSet, IChangeSetChangeListener, and then the management facilities
that go along with these.  Once that’s done, we would still need
to provide the bridges that you describe because Subclipse and Subversive
are already implementing org.eclipse.team change set internals, since it
was the easiest way for them to get Change Set integration independent
of Mylar.  Then if we convince them to implement our API instead we
probably need to provide a separate synchronization model, and so on.  Team
has just said that it does not have the resources to make this API even
though all of the implementation is there already.  We clearly do
not have the resources to re-implement this, especially since Mylar is
only intended to be a very thin wrapper automating resource synchronization,
not re-implementing it.  Let me know if I’m missing some way where
we can elegantly wrap over the Team implementation without exposing any
of the internals to implementors, but I feel like currently the easiest
thing to do would be to copy a huge chunk of the Team implementation into
Mylar which is wrong for many reasons.  
 
I appreciate your point about
our API contract problem and we need to do something about that.  I
had assumed that we were clearly indicating to people that to integrate
with this support they would need to use an internal API, and that transitively
this meant that this part of our API was internal, but that may have been
a misleading or simple a wrong assumption.  Options I see:
 
1) Pull this API completely.
 Problem there is that we only support CVS, and Subclispe and Subversion
support are gone, even though they are already implementing ActiveChangeSetManager
and only have tiny bridges to our automation of it. 
 
2) Put this Mylar API into a
..internal.. package to indicate that it depends on an internal platform
API.
 
3) Leave it where it is, say
that on 3.2.x and Mylar 1.0.x it is unlikely to change but keep our internals
use warning, and communicate that on 3.3 and Mylar 2.0 we hope on evolving
this API not use internals if we or other integrators can pool enough resources
and find the cooperation from Team*.  
 
Let me know what you think. 
 
In terms of supporting repositories
that use another kind of change set implementation, I don’t see any problems
there.  This part of the Mylar Team plug-in is all about integrating
with the change sets that come out of the box with the Eclipse SDK.  Having
integrators support other kinds of change sets is trivial since a 3rd
part only needs to create the change set when a task is activated, and
use the set of resources in the context as what shows up in the change
set.  
 
Mik
 
* P.S. I believe that
in terms of user experience the Platform there will be a big cost with
the current approach of forcing each team provider to implement its own
silo of synchronization, change sets support, and the corresponding UI.
 I just don’t buy the current story that the Team user experience
should only work well for developers having one source repository, because
a significant portion of developers check out sources for both their project
and the frameworks that they build on.  Not having change sets be
a part of platform is part of the problem, but symptoms of this show up
on other reports as well:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=146917#c9

- https://bugs.eclipse.org/bugs/show_bug.cgi?id=89806
 
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=138583

I realize that Platform/Team
may not have the resource to do this, but I’m wondering if it should at
least be discussed as an issue in case others in the community are willing
to help improve those key parts of the Team API.

---

From: mylar-dev-bounces@xxxxxxxxxxx
[mailto:mylar-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Valenta
Sent: Tuesday, December 05, 2006 6:50 AM
To: Mylar developer discussions
Subject: Re: [mylar-dev] enhancements in Mylar team API
 

Eugene, 

From this wiki entry, it would appear that Mylar has API that depends on
internal code from the Team component (i.e. ActiveChangeSetManager). Is
this true? If so, this is a big mistake. If the Mylar API has internal
classes in it's API, making these classes API would end up breaking the
Mylar API. 

In this particular case, even if the class in Team were API, it should
be viewed as an implementation detail of the repository provider and not
API that is usable by third party clients. Mylar should define it's own
API for change sets that repository providers can provide custom implementations
of. As a convenience, you could provide a bridge so that users of ActiveChangeSetManager
get Mylar integration for free. However, you should not force repositories
to use ActiveChangeSetManager as they may have their own classes for managing
change sets (as is mentioned in comment 4 of bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=116084).

Michael 

mylar-dev-bounces@xxxxxxxxxxx wrote on 12/05/2006 01:45:20 AM:

> 
>   To anyone who interested in integrating with Mylar's Team API
> (primarily developers of plugins for version control systems), there
was 
> some enhancements been made.
> 
>   I updated correspond section on Mylar wiki at
>   
> http://wiki.eclipse.org/index.
> php/Mylar_Integrator_Reference#Integrating_Team_Providers
> 
>   regards,
>   Eugene
> 
> PS: updated plugin for Mylar integration had been already contributed
to 
> Subclipse project
> 
> 
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev