Bugzilla – Full Text Bug Listing
| Summary: | Allow to use a remote target platform file via https:// | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Lars Vogel <Lars.Vogel> |
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | laeubi, Lars.Vogel, wellmann.hannes1, wim.jongman |
| Version: | 4.22 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 10 | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=577184 | ||
| Whiteboard: | |||
|
Description
Lars Vogel
Tychoo plans to support remote target definition files, see https://github.com/eclipse/tycho/pull/356 Theoretically it should be possible to use the EclipseFileSystem[1] for this. [1] https://wiki.eclipse.org/EFS#Remote_System_Explorer_.28SSH.2C_FTP.2C_dstore.29 There is already a ExternalFileTargetHandle class in PDE, that represents "A handle to a target stored in a remote file (outside workspace) and accessed using its URI." But I have to admit that I'm not sure how to use it from the UI respectively I have never used it knowingly. Furthermore it only supports file URIs. Nevertheless it should be trivial to either create a separate class named 'ExternalTargetHandle' or URL- respectively 'URITargetHandle' that handles arbitrary URI/URLs. In TargetPlatformService.getTarget() that class could then be used in the default case to handle any kind of URI that can be converted to a URL for which a InputStream can be opened. Then the question would be, how this should be presented in the UI? I think it could be another radio-option in the Add-Dialog of the Target Platform preference page that has a field for the URI. The Edit-Button should then consider that those external targets cannot be modified. Another question is if entered URI-targets should be persisted similar to local targets (that are created in the preferences and are not read from a .target-file). (In reply to Hannes Wellmann from comment #3) > There is already a ExternalFileTargetHandle class in PDE, that represents > "A handle to a target stored in a remote file (outside workspace) and > accessed using its URI." Eclipse distinguishes between 'IFiles' that are relative to a project and resources "somewhere else in the local file system" here. > But I have to admit that I'm not sure how to use it from the UI respectively > I have never used it knowingly. I could think of DND a file from your local hard-disc into the editor-area might trigger this. > Then the question would be, how this should be presented in the UI? The most convenient way would be to have something like the "Link File" feature, that creates a resource that is just a reference to another file. So something like Project>Add>Remote Target File that creates a simple text-file that contains the URL. Then it would even be possible to check in the file instead of have to add it for each user. Another way would be (that's something that would be more generic) to simply have a new target-location type "target" that allows to specify an URI (including the variables as in the Directory target) and one can then add this "target-uri" to a regular target file. This would even allow to emulate a feature in Tycho that allows to specify more than one target-file per build. Also this would help people in defining some kind of base-target and simply enhance this base target with some additional items. This kind of feature is also on my TODO list but I'm not sure if I will be able to contribute this for the current release-train. (In reply to Hannes Wellmann from comment #3) > Then the question would be, how this should be presented in the UI? I think > it could be another radio-option in the Add-Dialog of the Target Platform > preference page that has a field for the URI. The Edit-Button should then > consider that those external targets cannot be modified. *1, sounds like a good approach for me. This seems like the easiest solution. I think don't we need an editor for such references. > Another question is if entered URI-targets should be persisted similar to > local targets (that are created in the preferences and are not read from a > .target-file). I think the content should be persisted. And if the user selects refresh, it should be reloaded. And if we implement Bug 576844 the target platform should be re-read if the new preference is set. (In reply to Christoph Laeubrich from comment #4) > (In reply to Hannes Wellmann from comment #3) > > There is already a ExternalFileTargetHandle class in PDE, that represents > > "A handle to a target stored in a remote file (outside workspace) and > > accessed using its URI." > > Eclipse distinguishes between 'IFiles' that are relative to a project and > resources "somewhere else in the local file system" here. > > > But I have to admit that I'm not sure how to use it from the UI respectively > > I have never used it knowingly. > > I could think of DND a file from your local hard-disc into the editor-area > might trigger this. That could be the case, I'll try it. > > > Then the question would be, how this should be presented in the UI? > > The most convenient way would be to have something like the "Link File" > feature, that creates a resource that is just a reference to another file. > > So something like Project>Add>Remote Target File that creates a simple > text-file that contains the URL. Then it would even be possible to check in > the file instead of have to add it for each user. Creating such Link-file seems to be too much IMHO and I would ask why one does not simply put the referenced target file under version control and use it directly. Therefore would vote for the 'anonymous/virtual' solution. > > Another way would be (that's something that would be more generic) to simply > have a new target-location type "target" that allows to specify an URI > (including the variables as in the Directory target) and one can then add > this "target-uri" to a regular target file. This would even allow to emulate > a feature in Tycho that allows to specify more than one target-file per > build. Also this would help people in defining some kind of base-target and > simply enhance this base target with some additional items. +10 Being able to reference other targets to form a tree of targets is something I would also find very useful for PDE and I also had plans to work on this. So we could join our efforts on this. Is there already a bug for this? Because I have some points I want to mention and think should be considered. I can also offer to work on that. With that feature it would also possible to mimic the behavior of your suggested Link-File that can be put under version control. > > This kind of feature is also on my TODO list but I'm not sure if I will be > able to contribute this for the current release-train. I think the train for new features for the up-comming release has left the station on Monday, hasn't it? (In reply to Lars Vogel from comment #5) > (In reply to Hannes Wellmann from comment #3) > > Then the question would be, how this should be presented in the UI? I think > > it could be another radio-option in the Add-Dialog of the Target Platform > > preference page that has a field for the URI. The Edit-Button should then > > consider that those external targets cannot be modified. > > *1, sounds like a good approach for me. This seems like the easiest > solution. I think don't we need an editor for such references. @Lars do you think this feature is still necessary when Christoph's suggestion is implemented? For your use-case it would be a little short-cut in the UI but in the end a single 'target'-target would do the same job. In order to not have redundant features in PDE I suggest to solve this by implementing a 'target'-target. But if you prefer to keep this, I can offer to provide a Gerrit for this change, once I have completed my work on the launching facilities. (In reply to Hannes Wellmann from comment #6) > (In reply to Lars Vogel from comment #5) > > (In reply to Hannes Wellmann from comment #3) > > > Then the question would be, how this should be presented in the UI? I think > > > it could be another radio-option in the Add-Dialog of the Target Platform > > > preference page that has a field for the URI. The Edit-Button should then > > > consider that those external targets cannot be modified. > > > > *1, sounds like a good approach for me. This seems like the easiest > > solution. I think don't we need an editor for such references. > > @Lars do you think this feature is still necessary when Christoph's > suggestion is implemented? For your use-case it would be a little short-cut > in the UI but in the end a single 'target'-target would do the same job. In > order to not have redundant features in PDE I suggest to solve this by > implementing a 'target'-target. > But if you prefer to keep this, I can offer to provide a Gerrit for this > change, once I have completed my work on the launching facilities. So the suggestion is support reference to other (potentially remote) target platform definitions inside a local target platform definition via Bug 577184? Yes that sounds like a solid solution of the request to re-use target platform definitions. I suggest to mark this bug as duplicate of Bug 577184. Thanks, Hannes and Christophfor the follow-up. (In reply to Hannes Wellmann from comment #6) > Creating such Link-file seems to be too much IMHO and I would ask why one > does not simply put the referenced target file under version control and use > it directly. Therefore would vote for the 'anonymous/virtual' solution. I think the idea is (as with every link, like hyperlinks, symbolic or hard links) to be able to have a reference that always points to the latest version. I also have never tried to use ECF to create a standard eclipse linked resource, maybe something like that is already possible... as noted above the target-platform does actually never *requires* a file (it already supports URIs...) the file nature is just of interest if one likes to edit a target. > +10 Being able to reference other targets to form a tree of targets is > something I would also find very useful for PDE and I also had plans to work > on this. So we could join our efforts on this. Is there already a bug for > this? Because I have some points I want to mention and think should be > considered. I can also offer to work on that. I already have created a basic gerrit and its working, just adding some features like editing the entry and so on: https://bugs.eclipse.org/bugs/show_bug.cgi?id=577184 > I think the train for new features for the up-comming release has left the > station on Monday, hasn't it? I never fully understand this, but I think no new API is allowed from now on but new features are if they do not have the risk to break existing ones and PMC can vote to include it in any case... So it is a bit a question how important PDE committers and PMC find this feature in any case it could be delayed to the next year release. (In reply to Lars Vogel from comment #7) > So the suggestion is support reference to other (potentially remote) target > platform definitions inside a local target platform definition via Bug > 577184? Yes that sounds like a solid solution of the request to re-use > target platform definitions. I suggest to mark this bug as duplicate of Bug > 577184. Exactly. Yes I think marking this as a duplicate is reasonable. Thanks for the hint. (In reply to Christoph Laeubrich from comment #8) > I already have created a basic gerrit and its working, just adding some > features like editing the entry and so on: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=577184 Great. Thanks for the pointer. > > I think the train for new features for the up-comming release has left the > > station on Monday, hasn't it? > > I never fully understand this, but I think no new API is allowed from now on > but new features are if they do not have the risk to break existing ones and > PMC can vote to include it in any case... > > So it is a bit a question how important PDE committers and PMC find this > feature in any case it could be delayed to the next year release. Understand. Looks like there is no rule without an exception. :D *** This bug has been marked as a duplicate of bug 577184 *** |