| RE: [mylar-dev] enhancements in Mylar team API |
|
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
|