Community
Participate
Working Groups
With the Progress View visible, double clicking a *.target file with a non-trivial repo such as <repository location="https://ci.eclipse.org/ocl/job/ocl-branch-tests/lastSuccessfulBuild/artifact/targetPlatform/"/> shows massive activity downloading files lasting many minutes. This is an editor, it should be fast. Surely no downloads should be triggered until some menu action requests them?
(In reply to Ed Willink from comment #0) > shows massive activity downloading files lasting many minutes. Is this activity blocking other operation? > This is an editor, it should be fast. Surely no downloads should be > triggered until some menu action requests them? Being fast doesn't necessary imly being more productive and voce-versa. The editor also has validation and code assistance features tjat allow to produce error-free .target files faster and more easily (while a just being fast result in more risk of errors and more time wasted trouble shooting them. If you xant faster editor with less assistance, you can use the plain wtp,xml editor to edit those .target filzs.
@Ed , I agree with Mickael here. The editor needs to validate its content. We are not blaming Java editor for calling compiler in background, right? And may be this compilation process will require to download a half of Internet via Maven dependencies of the enclosing Java project, who knows. May be the process of .target resolution is not optimal - that may be a case.
I think the underlying problem/issue/misunderstanding here is that the editor does not actually need to verify the artifacts at all. In principle, it only needs the content metadata to understand/know which installable units are available and may validly be specified in the <unit/>s. The artifacts themselves aren't needed until one actually wants to *activate* the target platform, which is completely separate from editing/viewing the *.target file. The underlying p2 framework is perfectly capable of doing a resolution without downloading artifacts. That's what it does when one does Check for Updates or Install New Software: it resolves first, to figure out what's available and what needs to be updated/installed, and then the user can proceed to download the artifacts. As such, the eager downloading of artifacts by the editor is horrible and unnecessary in my opinion. It isn't even just a question of "is the activity blocking other operations", the activity is busying filling up my disk drive with artifacts that I might never use (and that the editor doesn't actually need). Often people maintain multiple *.target files and just opening the editor will start a process that is unnecessary purely for the purpose of viewing/editing the *.target. For Oomph development, for example, we generate the *.target file, but we don't actually ever use it to populate an active target platform in the IDE. So I always cringe when I accidentally double click the *.target and the PDE editor opens. I must avoid this editor like the plague. None of that would be a problem if the editor just edited rather than starting to download eagerly hundreds of megabytes of stuff. To me this all seems like a major design flaw. Even the artifact content can be determined/known from the artifact metadata without actually downloading the artifacts.
Thanks for the great comment, Ed Merks! This is exactly what needed for the PDE to start adressing the issue: 1) a "core" service that will be able to "resolve" without "downloading", and then 2) the .target editor can utilize this service for validation to improve user experience.
(In reply to Ed Merks from comment #3) > [...] So I always cringe when I > accidentally double click the *.target and the PDE editor opens. I must > avoid this editor like the plague. With the following Oomph Task in your user.setup you can avoid opening the Target editor by default: <?xml version="1.0" encoding="UTF-8"?> <workbench:FileMapping xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:workbench="http://www.eclipse.org/oomph/setup/workbench/1.0" xsi:schemaLocation="http://www.eclipse.org/oomph/setup/workbench/1.0 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/models/Workbench.ecore" filePattern="*.target" defaultEditorID="org.eclipse.wst.xml.ui.internal.tabletree.XMLMultiPageEditorPart"> <editor id="org.eclipse.pde.ui.targetEditor"/> </workbench:FileMapping>
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
