Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 355999 - ECPWorkspace.setActiveProject should be called in implementations
Summary: ECPWorkspace.setActiveProject should be called in implementations
Status: CLOSED WONTFIX
Alias: None
Product: ECP
Classification: Modeling
Component: Model Workspace (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 0.8.9   Edit
Assignee: Maximilian Koegel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-27 06:08 EDT by Nikolay Kasyanov CLA
Modified: 2012-02-02 05:06 EST (History)
1 user (show)

See Also:

Attachments
patch against latest 0.8x maintenance branch on svn (901 bytes, patch)
2011-09-01 11:49 EDT, Nikolay Kasyanov CLA 		no flags Details | Diff
added some fix (1.26 KB, patch)
2011-09-01 12:10 EDT, Nikolay Kasyanov CLA 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolay Kasyanov CLA 2011-08-27 06:08:44 EDT 
Build Identifier: I20110613-1736

I have not found way to listen changes of ECPWorkspace activeProject field, because EMFECPWorkspace doesn't call super.setActiveProject at all :( So, to detect active project change one should add listener to org.eclipse.emf.emfstore.client.model.Workspace

It's not implementation-agnostic, so I think implementations should call ECPWorkspace.setActiveProject, in methods like EMFECPWorkspace.setActiveModelElement

Reproducible: Always
Comment 1 Jonas Helming CLA 2011-08-30 05:26:22 EDT 
I agree, that is because the EMFECPWorkspace forwards the active project calls. I think it would be sufficient if the EMFECPWorkspace creates the right notifications that the active project has changed.
Comment 2 Nikolay Kasyanov CLA 2011-08-30 11:37:50 EDT 
I've tried to add super.setActiveProject to EMFECPWorkspace.setActiveModelElement and to remove overriden getActiveProject, looks good at first glance.
Comment 3 Jonas Helming CLA 2011-09-01 06:21:14 EDT 
could you provide a patch for that?
Comment 4 Nikolay Kasyanov CLA 2011-09-01 11:49:47 EDT 
Created attachment 202612 [details]
patch against latest 0.8x maintenance branch on svn

here it is
Comment 5 Nikolay Kasyanov CLA 2011-09-01 12:10:20 EDT 
Created attachment 202616 [details]
added some fix
Comment 6 Nikolay Kasyanov CLA 2011-09-01 12:20:07 EDT 
I see one potential issue: If in future another mapping.remove will be added, it should be guarded with check for active project. So, I see two ways:
1. Use HashMap with overridden remove method (which checks active project).
2. Leave all as for now and provide notification about changing activeProject field without actually changing it.
Comment 7 Jonas Helming CLA 2011-10-28 05:56:54 EDT 
You switched to the 0.9.x branch now, right? I would rather apply this in the GIT, if you do not mind.
Comment 8 Nikolay Kasyanov CLA 2011-10-28 08:10:13 EDT 
we haven't decided yet
Comment 9 Nikolay Kasyanov CLA 2012-02-02 03:29:20 EST 
Any news on this?
On current (M920) version it seems that I cannot detect active project change at model level at all, because field Workspace.activeProjectSpace which I used for such detection removed.

The only way is to fix this bug I think. Point me if I'm wrong.
Comment 10 Jonas Helming CLA 2012-02-02 05:06:29 EST 
current selection can be used instead, the concept of active project has been a duplicate.