Bug 142275

Comment 1 Michael Valenta 2006-05-18 11:14:24 EDT

The new model-based synchronizations will never be able to support objectContributions like the old sync did. The old sync had custom elements in the tree (i.e. ISynchronizeModelElement) whereas the model-based sync just has model element (i.e. IResouce, IJavaElement, etc). Object contributions cannot be used because they would not have access to the additional context.

However, it is still possible to contribute actions to the viewer. There are two classes of contributors: models and third parties. Third party contributions are currently not supported (see bug 124882). However, Mylar strikes me more as a model than a third party (i.e. you are providing model elements that appear in the view). Your case is a bit tricky since you are really extending existing models and don't have your own elements but it should still be possible to create a Mylar model provider and associated UI pieces in order to get your action on the appropriate elements. 

There is a Model Provider roadmap in the ISV Doc of Eclipse RC4 that outlines how to create a model provider. I am currently working on a related example which should be done soon. The Mylar case is a bit differnet since you wouldn't actually want to provide content but would only want to associate actions with particular object types. Once I'm done the doc, I try and describe in a bit more detail how you could potentially address this issue.

Comment 2 Mik Kersten 2006-05-18 12:03:28 EDT

I wouldn't mind losing the object contributions for the model elements themselves, but there are custom elements in the tree: the change set nodes.  Should they not support object contributions?  

I don't see Mylar as a model, since it does not provide any model elements--it simply corresponds sets of changes to a task and context.  To do that with CVS it needs to create Chage Sets and to say which changes are part of which set.  To do that with some fancier provider it might not even need to do that.  

I guess that Mylar could try to create a model contributor that wraps to other contributors, but would this not be a poor integration strategy?  I.e. it would have to be re-done for every contributor, seperately for subclipse, etc.  All we're trying to do is provide a UI layer that drives the models.

Sigh, I really wish I had noticed these change sooner.  I just had no idea that changing the preference would not update my old synchronization (and I'm sure others won't either).  Btw, for Eclipse 3.2 users what do you see the effects of not properly supporting model-based synch?  I see it's the default now.  Is anyone other than Jazz (which I assume is a driver) extending it, e.g. other Callisto projects?  

Comment 3 Michael Valenta 2006-05-18 13:56:42 EDT

Re: objectContributions; objectContributions are all or nothing (i.e. you can't enable them for some elements and disable them for others).

Re: model based synchronizations: I think that Mylar is a model. You have a Mylar specific Change Set. You could argue that you are just creating another element of an existing model. However, my counter argument would be that the change set model itself is not even API so support for extension by others is also not API. I also just realized that what I suggested before won't quite work since your actions would not appear in the Change Set model (i.e. that mode is restricted to the contributions from a single model.

So, I can see the following options:

1) You can wait until active change set support becomes API and bug 124882 is addressed. This will most likely happen in 3.3 but it is not guaranteed. 

2) You can investigate creating a Mylar model that has it's own notion of a change set. The logical model support could then be used to gaurantee that team operations included all the changes in a set and also include yor change sets and actions in the All Models mode of the sync view.

3) Inform your clients to disable the "Allow models to participate" option. This is the easiest option but may be a concerne for clients who want to use the model-based synchronizations.

I would recommend that you pursue point 2. It may even be the case that you can still let the ActiveChangeSetManager manage the set and you just have a model content provider that makes the set appear when it should. Of course, if you did use internals, you would still be vulnerable to future changes.

Comment 4 Michael Valenta 2006-05-24 14:14:47 EDT

*** This bug has been marked as a duplicate of 124882 ***

Comment 5 Mik Kersten 2006-06-13 23:20:16 EDT

Michael, I'm considering investigating (2) on your recommendation.  However,
the only added benefit that this would provide to Mylar users is that the "Open
Corresponding Task" action would show up on the menu.  So I'm concerned that
the extra burden of users for users seeing yet another orthogonal model would
be very confusing.  I'm already noticing confusion with the fact that Workspace
and Java Workspace are seperate, and that All Models doesn't show Change Sets. 
Regarding that, how could a custom Mylar model ensure it is shown in All Models
as you suggest if Change Sets are not shown in All Models?

Comment 6 Michael Valenta 2006-06-14 09:01:42 EDT

We purposely designed the Change Set model to be a separate model that did not appear in All Models mode. We could have just as easily made the change sets appear as root elements in the All Models mode. We didn't do so for several reasons but he main reason is that the CVS change set support still has a lot of shortcomings and we don't really have the manpower to address them. For this reason, we didn't want to Change Sets part of the main CVS Syncing workflow.

Mylar change sets could appear at the root of All Models mode and, if they did, the only complication would be that changes in the Change Sets would also appear in their corresponding Java projects. I think this would be acceptable to users.

Comment 7 Mik Kersten 2006-06-14 14:28:53 EDT

Thank you for all the feedback Michael.  Yes, it would be acceptable since users could easily switch to only seeing the custom change sets.  I created Mylar bug 147099 to explore this approach.