Community
Participate
Working Groups
Currently the Tigerstripe Explorer is based on an extension of the JDT Package Explorer, which means an unnecessary dependency on the JDT. This should instead be implemented with the CNF. The result should ensure parity of feature with the current Tigerstripe Explorer: - visualization of artifact types, diagrams (Class and INstance) - DnD of artifacts onto diagrams (class and instance) - DnD of artifacts within projects and across projects. - Refactor operations hoooked up to the Model Refactor actions - Referenced model nodes - flat structure vs. hierarchical structure of packages. In addition, it would good to add: - support for working sets. - support for filtering.
The following is a list of desirable features in TS Explorer: * User should be able to create any Tigerstripe-specific project by right clicking in the explorer and selecting New * A collapse-all button in the view's toolbar would be helpful * A link with editor button would also be helpful. When user double clicks on an issue in Problems view, it opens up the file in editor, the link with editor button would allow them to find the file's location in the explorer * Currently, the flat package presentation is not properly displayed in the Explorer (See bugzilla 319499) * Right clicking on a Session Facade artifact should allow you to add methods. Similarly, right clicking on an entity should allow you to create methods/attributes, etc...
Note that transitioning TS Explorer from JDT's Package Explorer to a CNF-based Explorer will not remove all JDT dependencies from Tigerstripe. Tigerstripe projects are essentially Java projects. As a result there is A LOT of JDT references. Is there a separate defect being tracked for cleaning this up or is this defect the general place-holder for removing all JDT dependencies?
(In reply to comment #2) > Note that transitioning TS Explorer from JDT's Package Explorer to a CNF-based > Explorer will not remove all JDT dependencies from Tigerstripe. > > Tigerstripe projects are essentially Java projects. As a result there is A LOT > of JDT references. Is there a separate defect being tracked for cleaning this > up or is this defect the general place-holder for removing all JDT > dependencies? Yes. There are quite a few more dependencies on JDT. Richard had a look at that a while back. Modules is the next big thing to un-JDT-ize I believe, then the Java nature of the project should be able to go. Finally we'll have to review the model audits that are missing as the JDT builders won't be running anymore... and we should be done ? Richard? I'm sure i missing something.
Firstly, YES - this was only meant to be the first step on the road to remval of Java dependency.... There is some Java logic in the diagram adaptation that I was surprised by. The explorer will be a significnat step forward...
Possible regressions as a result of the latest changes to this bug: Bug#321130 - Decorators don't work properly in TS Explorer Bug#321140 - NPE when closing TS Explorer Bug#322414 - [TS Explorer] Explorer is not properly updated when a facet is activated
*** Bug 317736 has been marked as a duplicate of this bug. ***
Another regression of this defect: Bug#322909
Hi Yuri, I see that NewTigerstripeExplorerContentProvider still sub-classes JavaNavigatorContentProvider. I suspect this will go away once this enhancement is completed, correct?
Hi Navid, I think we need to check which features we used from the JavaNavigatorContentProvider. I'm not sure because as you mentioned Tigerstripe projects are essentially Java projects, so it might not work properly after removing dependencies to java label/content providers. We'll check it.
Historically Tigerstripe Explorer based on the java model (org.eclipse.jdt.core.IJavaModel) and from the explorer perspective Tigerstripe just a customization of java model: customize icons/labels filter unnecessary elements (.package, java libraries, etc.) override standard actions (refactoring, open and view actions, etc.) To reduce dependecies from the JDT we need to base common navigator on other model. It can be: 1. Resource model 2. Pure Tigerstripe model (org.eclipse.tigerstripe.workbench.model.deprecated...) 3. Custom navigator model Unlike java model resource model doesn't fit Tigerstripe well. We haven't attributes and methods, libraries and library containers, etc. Custom model also doesn't look good while we need to keep Tigerstripe and our custom model in sync. So the best choose is to use pure Tigerstripe model. We have tried to create navigator based on the Tigertripe model and found that it's more difficult than seemed at the first glance. Tigerstripe model doesn't contain all elements which should be displayed in the explorer: diagrams, facets and other resources. For example in java model we have getNonJavaResources() classpath containers and classpath entries which is used to display installed modules and dependencies. ALL actions and filters which contributed for resource or java elements should be contributed for tigerstripe elements (team support, properties, run/debug, refresh, import/export, etc.). Note that we needn't to rewrite all actions but we need to add some wrappers/adapters because all these actions initially designed for resource/java. Integration with resource markers to display errors and warnings. Provide lot of small features which gave us JDT like flat layot. Tigerstripe refactoring delegates to java refactoring. So if we're going to remove dependencies to JDT we need to make all refactoring based on pure tigerstripe model. There're issues which we found while trying to create explorer based on Tigerstripe model and I guess there might be other issues. Probably this issue will take a lot of time and I'm not sure we should start it now. What do you guys think about it?
Valentin, this enhancement hasn't been scheduled for I25 so we shouldn't be spending any time on it. I'm completely against reinventing the wheel. If JDT's model does the job for us, let's stick with it for the time being. I don't see a good enough reason to deviate away from this (at least not yet).
